Exploration de décembre : CDN et exploration

Mardi 24 décembre 2024

Les réseaux de diffusion de contenu (CDN) sont particulièrement bien adaptés pour réduire la latence de votre site Web et, en général, éviter les maux de tête liés au trafic Web. C’est après tout leur objectif principal : la livraison rapide de votre contenu même si votre site reçoit beaucoup de trafic. Le “D”
dans CDN sert à diffuser ou à distribuer le contenu dans le monde entier, de sorte que les temps de transfert vers vos utilisateurs sont également inférieurs à un simple hébergement dans un centre de données quelque part. Dans cet article, nous allons explorer comment utiliser les CDN d’une manière qui améliore l’exploration et l’expérience des utilisateurs sur votre site, et nous examinons également certaines nuances de l’exploration des sites pris en charge par CDN.

Récapitulatif : Qu’est-ce qu’un CDN ?

Les CDN sont fondamentalement un intermédiaire entre votre serveur d’origine (où vit votre site Web) et l’utilisateur final, et servent (certains) fichiers pour eux. Historiquement,
L’objectif principal des CDN est la mise en cache, ce qui signifie qu’une fois qu’un utilisateur a demandé une URL de votre site, les CDN stockent le contenu de cette URL dans leurs caches pendant un certain temps afin que votre serveur n’ait plus à servir ce fichier pendant un certain temps.

Les CDN peuvent accélérer considérablement votre site en servant les utilisateurs à partir d’un emplacement proche d’eux. Disons qu’un utilisateur en Australie accède à un site hébergé en Allemagne, un CDN servira cet utilisateur à partir de ses caches en Australie, réduisant ainsi le trajet aller-retour à travers le monde. Vitesse de la lumière ou pas,
la distance est encore assez grande.

Et enfin,
Les CDN sont un outil fantastique pour protéger votre site contre la surcharge et certaines menaces de sécurité. Avec la quantité de trafic mondial que gèrent les CDN, ils peuvent construire des modèles de trafic fiables pour détecter les anomalies de trafic et bloquer les accès qui semblent excessifs ou malveillants. Par exemple, le 21 octobre 2024,
Les systèmes de Cloudflare
ont détecté et atténué de manière autonome un 4.2
Tbps
(ed : c’est beaucoup) Attaque DDoS qui a duré environ une minute.

Comment les CDN peuvent aider votre site

Vous avez peut-être les serveurs les plus rapides et la meilleure liaison montante que l’argent puisse acheter et vous pensez peut-être que vous n’avez rien à accélérer, mais les CDN peuvent vous faire économiser de l’argent à long terme, surtout si votre site est grand :

• Mise en cache sur le CDN: si des ressources telles que les médias, JavaScript et CSS, ou même votre HTML sont servies à partir des caches d’un CDN, vos serveurs n’ont pas à dépenser de calcul et de bande passante pour servir ces ressources, réduisant ainsi la charge du serveur. Cela signifie généralement aussi que les pages se chargent plus rapidement dans les navigateurs des utilisateurs, ce qui
  corrèle avec de meilleures conversions.
• Protection contre les inondations de trafic: les CDN sont particulièrement doués pour identifier et bloquer le trafic excessif ou malveillant, permettant à vos utilisateurs de visiter votre site même lorsque des robots mal comportés ou des fauteurs de troubles surchargeraient vos serveurs.
  Outre la protection contre les inondations, les mêmes contrôles utilisés pour bloquer le mauvais trafic peuvent également être utilisés pour bloquer le trafic dont vous ne voulez tout simplement pas, qu’il s’agisse de certains robots d’indexation, de clients qui correspondent à un certain modèle, ou simplement de trolls qui continuent d’utiliser la même adresse IP. Bien que vous puissiez également le faire sur votre serveur ou votre pare-feu, il est généralement beaucoup plus facile d’utiliser l’interface utilisateur d’un CDN.
• Fiabilité: certains CDN peuvent servir votre site aux utilisateurs même si votre site est en panne. Cela ne peut bien sûr fonctionner que pour du contenu statique, mais cela peut déjà suffire à garantir qu’ils ne portent pas leurs affaires ailleurs.

En bref, les CDN sont vos amis et si votre site est grand ou si vous attendez (ou recevez déjà !) de grandes quantités de trafic, vous voudrez peut-être en trouver un qui correspond à vos besoins en fonction de facteurs tels que le prix, les performances, la fiabilité, la sécurité, le support client, l’évolutivité, l’expansion future. Vérifiez auprès de votre fournisseur d’hébergement ou de CMS pour connaître vos options (et si vous en utilisez déjà une).

Comment l’exploration affecte les sites avec CDN

Sur le plan de l’exploration, les CDN peuvent également être utiles, mais ils peuvent causer des problèmes d’exploration (bien que rarement). Restez avec nous.

Effet des CDN sur le taux d’exploration

Notre infrastructure d’exploration est conçue pour permettre des taux d’exploration plus élevés sur les sites pris en charge par un CDN, qui est déduit de l’adresse IP du service qui dessert les URL auxquelles nos robots d’indexation accédent. Cela fonctionne bien, du moins la plupart du temps.

Disons que vous lancez un site de photos de stock aujourd’hui et que vous avez par hasard 1 000 007 photos en… stock. Vous lancez votre site Web avec une page de destination, des pages de catégorie et des pages de détails pour toutes vos affaires – vous vous retrouvez donc avec beaucoup de pages. Nous expliquons dans notre documentation sur
limite de capacité d’exploration
que bien que la Recherche Google souhaite explorer toutes ces pages aussi rapidement que possible, l’exploration ne doit pas non plus surcharger vos serveurs. Si votre serveur commence à répondre lentement face à un nombre accru de demandes d’exploration, la limitation est appliquée du côté de Google pour empêcher votre serveur d’être surchargé. Le seuil de cette limitation est beaucoup plus élevé lorsque notre infrastructure d’exploration détecte que votre site est pris en charge par un CDN, et suppose qu’il est acceptable d’envoyer plus de requêtes simultanées car votre serveur peut très probablement le gérer, explorant ainsi votre boutique en ligne plus rapidement.

Cependant, lors du premier accès à une URL, le cache du CDN est “froid”, ce qui signifie que comme personne n’a encore demandé cette URL, son contenu n’a pas encore été mis en cache par le CDN, de sorte que votre serveur d’origine devra toujours servir cette URL au moins une fois pour “réchauffer” le cache du CDN. C’est très similaire à
comment fonctionne la mise en cache HTTP, aussi.

En bref, même si votre boutique en ligne est soutenue par un CDN, votre serveur devra diffuser ces 1 000 007 URL au moins une fois. Ce n’est qu’après cette première diffusion que votre CDN pourra vous aider avec ses caches. Cela représente une charge importante pour votre « budget de crawl » et le taux de crawl sera probablement élevé pendant quelques jours ; gardez cela à l’esprit si vous prévoyez de lancer de nombreuses URL en même temps.

L’effet des CDN sur le rendu

Comme nous l’avons expliqué dans notre premier
article de blog de décembre sur le crawl des ressources, séparer les ressources sur leur propre nom d’hôte ou sur un nom d’hôte CDN (cdn.example.com) peut permettre à notre service de rendu Web (WRS) de rendre vos pages plus efficacement. Cela comporte toutefois une réserve : cette pratique peut nuire aux performances des pages en raison de la surcharge d’une connexion à un nom d’hôte différent, vous devez donc examiner attentivement
l’expérience de page par rapport aux performances de rendu.

Si vous protégez votre hôte principal avec un CDN, vous évitez ce problème : un seul nom d’hôte à interroger, et les ressources de rendu critiques sont probablement servies à partir du cache du CDN, de sorte que votre serveur n’a pas besoin de les servir (et aucun impact sur l’expérience de page).

En fin de compte, choisissez la solution qui fonctionne le mieux pour votre entreprise : ayez un nom d’hôte distinct (cdn.example.com) pour les ressources statiques, protégez votre nom d’hôte principal avec un CDN, ou faites les deux. L’infrastructure de crawl de Google prend en charge les deux options sans problème.

Quand les CDN sont trop protecteurs

En raison de la protection contre les flux massifs des CDN et de la manière dont les robots d’exploration explorent, il arrive parfois que les robots que vous souhaitez réellement sur votre site se retrouvent dans la liste de blocage de votre CDN, généralement dans son pare-feu d’application Web (WAF). Cela empêche les robots d’accéder à votre site, ce qui peut finalement empêcher votre site d’apparaître dans les résultats de recherche. Le blocage peut se produire de différentes manières, certaines étant plus préjudiciables à la présence d’un site dans les résultats de recherche de Google que d’autres, et il peut être délicat (voire impossible) pour vous de le contrôler puisqu’ils se produisent du côté du CDN. Pour les besoins de cet article de blog, nous les avons regroupés en deux catégories : les blocages durs et les blocages souples.

Blocages durs

Les blocages durs se produisent lorsque le CDN envoie une réponse à une demande de crawl qui constitue une erreur sous une forme ou une autre. Il peut s’agir de :

• HTTP 503/429 codes d’état: l’envoi
  de ces codes d’état est la méthode privilégiée
  pour signaler un blocage temporaire. Cela vous laissera un peu de temps pour réagir aux blocages involontaires causés par le CDN.
• Délais d’attente du réseau: les délais d’attente du réseau provenant du CDN entraîneront la suppression des URL concernées de l’index de recherche de Google, car ces
  erreurs de réseau sont considérées comme des erreurs terminales et « dures ». De plus, elles peuvent également affecter considérablement le taux de crawl de votre site car elles signalent à notre infrastructure de crawl que le site est surchargé.
• Message d’erreur aléatoire avec un 200 code d’étatHTTP : également connu sous le nom de
  fausses erreurs, c’est particulièrement grave. Si le message d’erreur est assimilé par Google à une erreur « dure » (disons un HTTP 500), Google supprimera l’URL de la recherche. Si Google n’a pas pu détecter les messages d’erreur comme des erreurs « dures », toutes les pages présentant le même message d’erreur peuvent être éliminées en tant que doublons de l’index de recherche de Google. Étant donné que l’indexation de Google n’a guère intérêt à demander un nouveau crawl des URL en double, la récupération peut prendre plus de temps.

Blocages souples

Un problème similaire peut survenir (jeu de mots tout à fait intentionnel) lorsque votre CDN affiche ces interstitiels « êtes-vous un humain ».

Nos robots sont en fait convaincus qu’ils ne SONT PAS humains et ne font pas semblant de l’être. Ils veulent juste crawler. Cependant, lorsque l’interstitiel s’affiche, c’est tout ce qu’ils voient, et non votre site génial. Dans le cas de ces interstitiels de vérification de bot, nous vous recommandons fortement d’envoyer un signal clair sous la forme d’un code d’état HTTP 503 aux clients automatisés comme les robots d’exploration indiquant que le contenu est temporairement indisponible. Cela garantira que le contenu n’est pas supprimé automatiquement de l’index de Google.

Débogage des blocages

En cas de blocages durs et souples, le moyen le plus simple de vérifier si tout fonctionne correctement est d’utiliser
l’outil d’inspection d’URL dans Search Console
et d’observer l’image rendue : si elle affiche votre page, tout va bien ; si elle affiche une page vide, une erreur ou une page avec un défi de bot, vous voudrez peut-être en parler à votre CDN.

De plus, pour aider à contrer ces blocages involontaires, Google, d’autres moteurs de recherche et d’autres opérateurs de robots d’exploration publient
nos adresses IP pour vous aider à identifier nos robots d’indexation et, si vous le jugez opportun, à supprimer les IP bloquées des règles WAF ou même à les ajouter à une liste blanche. L’endroit où vous pouvez le faire dépend du CDN que vous utilisez ; heureusement, la plupart des CDN et des WAF autonomes disposent d’une documentation fantastique. En voici quelques-uns que nous avons pu trouver avec une petite recherche (au moment de la publication de cet article) :

• Cloudflare : https://developers.cloudflare.com/bots/get-started/free/#visibility
• Akamai : https://www.akamai.com/products/bot-manager
• Fastly : https://www.fastly.com/products/bot-management
• F5: https://clouddocs.f5.com/bigip-next/20-2-0/waf_management/waf_bot_protection.html
• Google Cloud : https://cloud.google.com/armor/docs/bot-management

Si vous avez besoin que votre site apparaisse dans les moteurs de recherche, nous vous conseillons vivement de vérifier si les robots d’indexation qui vous intéressent peuvent accéder à votre site. N’oubliez pas que les adresses IP peuvent se retrouver sur une liste de blocage automatiquement, à votre insu. Il est donc judicieux de vérifier les listes de blocage de temps en temps pour assurer le succès de votre site dans la recherche et au-delà. Si la liste de blocage est très longue (un peu comme cet article de blog), essayez de chercher uniquement les premiers segments des plages d’adresses IP, par exemple, au lieu de chercher 192.168.0.101 vous pouvez simplement chercher 192.168.

C’était le dernier article de notre
série d’articles de blog Crawling December, nous espérons que vous les avez appréciés autant que nous avons aimé les écrire. Si vous avez… bla bla bla… vous connaissez la chanson.

Publié par
Martin Splitt et
Gary Illyes

Vous voulez en savoir plus sur le crawling ? Consultez toute la série Crawling December :