Migration CDN et Googlebot: éviter le piège du cache froid
Google Search Central publie un guide détaillé sur les effets inattendus d'une migration vers un CDN, notamment la surge de trafic crawler sur le serveur d'origine pendant la phase de cache froid. L'article explique pourquoi Googlebot accélère son exploration juste après la bascule DNS et comment éviter de bloquer accidentellement les crawlers avec des protections anti-bots trop larges. Ces informations sont directement actionnables pour tout responsable technique ou SEO qui planifie ou vient d'effectuer une telle migration.
Points clés
- Dès la bascule DNS vers un CDN, les temps de réponse chutent brutalement, ce que les systèmes automatisés de Google interprètent comme un signal de capacité serveur accrue, déclenchant une accélération immédiate du crawl.
- Un CDN en cache froid ne protège pas encore le serveur d'origine: chaque première requête sur une URL non encore mise en cache génère un cache miss qui remonte directement jusqu'au serveur source.
- Les crawlers explorent méthodiquement l'intégralité de l'inventaire d'URL d'un site, à l'opposé des utilisateurs humains qui se concentrent sur un petit nombre de pages populaires, ce qui rend le préchauffage du cache particulièrement long et exigeant.
- Activer une protection anti-bots généralisée (WAF, CAPTCHA) sans exemption pour les crawlers vérifiés bloque Googlebot, qui ne peut résoudre les défis de type CAPTCHA, et provoque une désindexation progressive des contenus.
- Les codes HTTP 429 (Trop de requêtes) et 503 (Service indisponible) constituent la méthode officiellement recommandée par Google pour ralentir temporairement le crawl sans bloquer définitivement les crawlers pendant la phase de stabilisation.
- Le préchauffage proactif du cache avant la bascule de trafic, en fetchant les URLs à forte audience et les pages prioritaires à un rythme contrôlé, permet de réduire significativement la fenêtre de vulnérabilité du serveur d'origine.
Analyse
Le mécanisme central à comprendre est celui du crawl capacity limit, appelé hostload dans l'infrastructure Google. Ce seuil est ajusté en continu en fonction des temps de réponse du serveur hébergeant le site. Lorsque les réponses sont lentes, Googlebot ralentit pour préserver la stabilité du site. Lorsqu'elles redeviennent rapides et stables, le système augmente progressivement le débit de crawl. Une bascule CDN, en faisant chuter les latences de connexion de façon spectaculaire, envoie un signal fort indiquant que le serveur dispose d'une capacité bien supérieure à ce qui était observé jusqu'alors, ce qui enclenche une montée en charge rapide du crawl.
Le paradoxe de la migration CDN tient précisément dans ce décalage temporel entre le signal de performance envoyé aux crawlers et la réalité opérationnelle du réseau de distribution. Les serveurs edge du CDN reçoivent des requêtes en masse mais ne disposent d'aucun contenu en cache pour y répondre. Chaque cache miss oblige le serveur edge à effectuer une requête vers le serveur d'origine, qui se retrouve donc à absorber autant de charge qu'avant la migration, voire davantage du fait de l'accélération du crawl. Le CDN ne joue son rôle de bouclier qu'à partir de la deuxième requête sur une URL donnée depuis un point de présence donné.
La réaction instinctive des administrateurs système face à cette surcharge inattendue est d'activer les protections anti-bots disponibles dans le tableau de bord du CDN ou du pare-feu applicatif. Or, les règles génériques bloquent indifféremment tous les clients automatisés, y compris Googlebot. Ce dernier étant incapable de résoudre des défis CAPTCHA ou de simuler un comportement humain, il est renvoyé sur des pages d'erreur ou des réponses 403 qui ne lui permettent pas d'indexer le contenu. Si cette situation persiste, Google interprète le site comme délibérément restreint et commence à déprioriser puis à supprimer ses pages des résultats de recherche.
La distinction entre bots vérifiés et bots non vérifiés est ici fondamentale. Google publie ses plages d'adresses IP de crawl, ce qui permet aux CDN et aux WAF d'identifier Googlebot avec fiabilité et de lui accorder des exemptions ciblées, tout en continuant à filtrer le trafic malveillant ou non souhaité. Certains CDN majeurs proposent des règles préconfigurées pour les crawlers vérifiés des moteurs de recherche, ce qui simplifie considérablement cette configuration. Recourir à des règles robots.txt ou à des directives ciblant des user-agents spécifiques non désirés constitue également une approche plus chirurgicale que le blocage global.
Sur le plan stratégique, cette publication de Google Search Central rappelle que la performance technique et le SEO sont indissociables lors d'opérations d'infrastructure. Une migration CDN mal planifiée peut durablement affecter la visibilité organique d'un site, même si elle est techniquement réussie du point de vue de la livraison de contenu aux utilisateurs. Les équipes SEO doivent être impliquées en amont de tels projets pour anticiper les effets sur le crawl budget, monitorer les logs de crawl pendant la transition et coordonner les mesures correctives avec les équipes technique et infrastructure.
Que faire
- Avant toute bascule DNS vers un CDN, identifier les URLs les plus crawlées et les pages à fort trafic, puis les préchauffer manuellement en les fetant de façon contrôlée à travers le CDN afin de réduire au maximum le nombre de cache miss lors de l'ouverture au trafic réel.
- Configurer dès le départ des exemptions explicites pour les crawlers vérifiés des moteurs de recherche dans les règles du CDN et du pare-feu applicatif, en s'appuyant sur les plages IP publiées par Google, afin d'éviter tout blocage involontaire de Googlebot pendant et après la migration.
- En cas de surcharge persistante du serveur d'origine pendant la phase de préchauffage, configurer temporairement des réponses HTTP 429 ou 503 pour les requêtes excédentaires, en limitant cette mesure à quelques heures ou deux jours au maximum, conformément aux recommandations officielles de Google.
- Surveiller activement les logs de crawl côté serveur d'origine pendant les 48 à 72 heures suivant la migration pour détecter toute anomalie (pics de cache miss, erreurs 4xx/5xx inattendues, ralentissement du crawl Googlebot) et agir rapidement avant que l'impact sur l'indexation ne devienne significatif.
- Éviter d'activer des règles anti-bots généralisées ou des challenges CAPTCHA sans avoir préalablement défini des exceptions pour les bots vérifiés. Privilégier des règles ciblées sur des user-agents ou des comportements spécifiques plutôt que des blocages globaux portant sur toute forme de trafic automatisé.
- Associer les équipes SEO et les équipes infrastructure dès la phase de planification d'une migration CDN pour s'assurer que les enjeux de crawl budget, d'indexation et de réponses HTTP sont pris en compte dans le plan de déploiement et les procédures de rollback.
Une mauvaise gestion de la transition CDN peut provoquer une surcharge du serveur d'origine, entraîner des erreurs visibles par Googlebot et conduire à une perte d'indexation des pages, des fiches produits et des contenus récemment publiés. À l'inverse, une migration bien préparée améliore la vitesse perçue par les crawlers et peut accroître le crawl budget effectivement utilisé.