Google : passer à un CDN peut faire monter le crawl et saturer l’origine

Le 11 novembre 2026, Gary Illyes et Cherry Prommawin (Google) publient sur Search Central un billet consacré au passage à un CDN. Google y explique pourquoi Googlebot crawle davantage une fois le CDN en place, comment l’origine peut saturer, et pourquoi un blocage trop large des robots peut faire sortir des pages de la recherche.

L’essentiel

• Google confirme que des réponses plus rapides font monter son rythme de crawl (la limite de capacité, ou hostload).
• Un cache CDN vide renvoie chaque première requête vers le serveur d’origine, qui encaisse alors l’essentiel de la charge.
• Les défis anti-bots généralisés (CAPTCHA, murs 403) peuvent bloquer Googlebot, et les pages risquent alors de quitter la recherche.
• Google recommande d’autoriser les robots vérifiés, de préchauffer le cache et, si besoin, de répondre temporairement 429 ou 503.

Pourquoi le crawl augmente après la bascule

Le billet, intitulé Moving to a CDN without overwhelming your origin (or blocking Googlebot), part d’un mécanisme simple. Quand les temps de réponse baissent, la capacité de crawl que Google s’autorise sur l’hôte monte. Un CDN rend le site plus rapide aux yeux des robots, qui augmentent donc leur cadence. Cette montée est progressive, et beaucoup de CDN limitent aussi le rythme des connexions.

Le problème vient du cache. Un CDN neuf démarre vide : chaque première demande d’URL est un échec de cache, transmis à l’origine. Comme les robots parcourent un très grand nombre d’URL, le serveur d’origine travaille beaucoup tant que le cache n’est pas rempli. Selon Search Engine Roundtable, qui relaie l’épisode vidéo associé, l’exemple donné est celui de 100 000 URL uniques non mises en cache, qui arrivent toutes à l’origine.

Bloquer les robots : le risque que Google met en avant

Face au pic de trafic, une équipe technique peut croire à une attaque et activer une protection agressive. Google avertit que des défis généralisés, comme les CAPTCHA ou les murs 403, peuvent bloquer ses robots d’exploration. Dans ce cas, écrit-il, les pages peuvent disparaître de la recherche. La formule du billet est « BOTS SHALL NOT PASS » (traduction : « les robots ne passeront pas »), employée sur le ton de l’humour pour décrire l’erreur à éviter.

Les trois mesures recommandées

1. Autoriser les robots vérifiés. Les principaux CDN et pare-feu applicatifs proposent une option ou une règle gérée pour cela. Google renvoie vers sa documentation pour vérifier les requêtes de ses robots à partir de ses plages d’adresses IP publiées. Pour écarter des robots indésirables, il préconise le robots.txt ou des règles ciblées plutôt qu’un blocage de tous les clients automatisés.
2. Préchauffer le cache avant de basculer tout le trafic : pages les plus visitées, pages attendues lors d’un pic (promotions) et URL souvent crawlées, à un rythme maîtrisé.
3. Si le crawl pèse encore sur l’origine pendant le remplissage du cache, renvoyer temporairement des codes 429 (Too Many Requests) ou 503 (Service Unavailable) par des règles de limitation. Google précise de garder ces règles quelques heures, un à deux jours au maximum. Voir aussi sa page sur la réduction du rythme de crawl.

Le billet est le dernier épisode de la saison 1 de la série vidéo The Non-Canonical Cabinet, de moins de 10 minutes. Une précédente actu du site a déjà abordé un autre épisode de cette série.

Ce que j’en retiens

Le conseil est classique, mais le point de vigilance est réel : une migration vers un CDN se prépare côté SEO autant que côté infrastructure. Le mauvais réflexe, celui que Google décrit, consiste à traiter la hausse de crawl comme une attaque et à fermer la porte à Googlebot. Je retiens que la règle d’autorisation des robots vérifiés doit être en place avant la bascule, pas après le premier pic.

Ce que je vérifierais sur un site concerné : les erreurs de crawl dans les statistiques d’exploration de la Search Console, les codes 403, 429 et 503 renvoyés à Googlebot, et le temps de réponse de l’origine pendant les premiers jours. Les journaux serveur donnent la vue la plus fiable, c’est le cas typique où l’analyse de logs montre ce que les robots reçoivent vraiment. Le billet ne chiffre ni la durée ni l’ampleur du pic de crawl en dehors de l’exemple cité : ces points restent à mesurer site par site.