ActualitéSEO

Un CDN tout neuf peut d’abord surcharger le serveur qu’il doit protéger, prévient Google

Selon Google, un CDN tout neuf peut d'abord surcharger le serveur d'origine, et bloquer tous les robots peut faire sortir des pages de Google.

Quand un site passe sur un CDN, les robots de Google peuvent d’abord surcharger le serveur qui l’héberge, dit serveur d’origine. Google l’explique dans un billet consacré au passage d’un site sur un CDN, publié le 11 novembre 2026 sur son blog Search Central. Il déconseille aussi de bloquer tous les robots : si ce blocage dure, des pages commencent à sortir de la recherche Google.

Un CDN est un réseau de serveurs qui gardent des copies des pages au plus près des internautes. Les robots d’exploration, comme Googlebot chez Google, sont des programmes qui parcourent les sites. Le billet est signé Cherry Prommawin et Gary Illyes, analystes de l’équipe du moteur de recherche de Google. Selon eux, des propriétaires de sites leur signalent parfois une hausse des requêtes de robots sur le serveur d’origine, presque aussitôt après la bascule.

Deux mécanismes l’expliquent. Un CDN répond plus vite, ce qui pousse Google à explorer davantage. Son cache, sa réserve de copies, est pourtant vide au départ et renvoie les premières demandes au serveur d’origine.

Un serveur plus rapide attire plus de visites de Googlebot

Google fixe pour chaque site une « limite de la capacité d’exploration », aussi appelée « charge de l’hôte » (hostload). Elle plafonne le temps que le serveur passe à garder des connexions ouvertes pour Google, selon leur nombre et leur durée. Tous les sites partent du même plafond prudent.

Google relève ce plafond si le site répond vite et de façon stable. Il l’abaisse si les réponses ralentissent ou si le serveur renvoie des erreurs 5xx ou 429. Dans ces codes de réponse HTTP, la série 5xx signale une erreur du serveur, le 429 un excès de requêtes.

Dès que le site passe par le CDN, les temps de connexion et de réponse chutent. « Pour nos systèmes d’exploration, c’est comme si votre serveur venait de recevoir une énorme mise à niveau matérielle », écrivent les auteurs (citation traduite de l’anglais, comme celles du billet et de PPC Land plus bas). Les robots accélèrent alors peu à peu. Encore faut-il que Google veuille explorer davantage le site, ce que sa documentation appelle le besoin d’exploration.

Chaque robot de Google a ses propres besoins, mais tous partagent cette limite. Selon la documentation, le robot de Google Shopping, son comparateur de produits, a davantage besoin d’explorer les produits des flux marchands, ces catalogues qu’un site envoie à Google. Une forte demande de l’un réduit la capacité laissée aux autres.

Un cache vide renvoie chaque première demande au serveur d’origine

Au lancement, le cache vide d’un CDN est dit « froid ». À la première demande d’une page, le serveur du CDN n’en a aucune copie : c’est un défaut de cache. Il va chercher la page sur le serveur d’origine, en garde une copie, puis répond. Les demandes suivantes sont servies par le CDN.

Les visiteurs se concentrent en général sur quelques pages : l’accueil, les articles phares, les promotions en cours. Ces pages entrent vite en cache. Les robots, eux, parcourent méthodiquement toutes les pages du site, et chaque page jamais demandée est cherchée sur le serveur d’origine. « Le vrai goulot d’étranglement lors du lancement d’un CDN reste le serveur d’origine », résument les auteurs.

Google nuance ce tableau. Ses robots n’accélèrent pas d’un coup, et beaucoup de CDN étalent eux-mêmes les connexions pour lisser les pics. Tant que le cache n’est pas rempli, le serveur d’origine reste pourtant exposé.

La protection anti-robots qui fait sortir les pages de Google

Après la bascule, une avalanche de requêtes automatiques dans le journal du serveur peut inquiéter un administrateur qui en ignore la cause. Le billet décrit alors la tentation d’activer une protection générale contre les robots dans le tableau de bord du CDN. Faute d’exception prévue, cette protection s’applique aussi aux robots que le site veut laisser passer.

Le CDN peut alors imposer un CAPTCHA, ce test censé distinguer les humains des robots. Un pare-feu applicatif web (WAF), filtre qui écarte les requêtes suspectes, peut faire de même. Selon le billet, « les robots d’exploration de Google échouent au test ».

Ces robots restent alors bloqués sur une page d’erreur, et le site paraît à Google volontairement restreint ou cassé. Si la règle reste en place, prévient le billet, Google ralentit son exploration et les pages, fiches produits comprises, commencent à disparaître de la recherche.

Le billet vise aussi les « murs » d’erreur 403, le code qui refuse l’accès. Selon la documentation de Google sur les codes HTTP, une page déjà indexée qui renvoie une erreur 4xx, comme 403, sort de l’index, donc des résultats. Ces codes « n’ont aucun effet sur la vitesse d’exploration », à l’exception du 429.

Google a déjà fait une exception que sa documentation ne prévoit pas. Le 5 novembre, Gary Illyes a expliqué que Google avait protégé un temps de la sortie de l’index la page d’accueil de VLC malgré une erreur 418, un autre code 4xx. Google jugeait très importante cette page du lecteur multimédia.

Google conseille d’exempter ses robots et de préchauffer le cache

Le billet formule trois recommandations. La première vise les sites qui doivent filtrer les robots : autoriser les robots vérifiés dans les réglages du CDN et du pare-feu. Selon Google, la plupart des grands CDN et pare-feu applicatifs proposent une option à activer ou une règle toute prête.

Les robots de Google se reconnaissent à leurs plages d’adresses IP publiées, l’adresse IP identifiant une machine en ligne. L’autre méthode passe par le DNS, l’annuaire d’internet qui relie adresses et noms de domaine. L’adresse doit renvoyer à un nom en googlebot.com ou google.com, et ce nom à la même adresse.

Google juge préférable de cibler précisément les robots indésirables, par le fichier robots.txt ou des règles dédiées. Ce fichier indique aux robots ce qu’ils peuvent explorer, mais tous ne le respectent pas, comme le détaille notre article sur les robots IA et le robots.txt.

La deuxième recommandation consiste à « préchauffer » le cache avant de faire passer tout le trafic par le CDN. On lui fait charger, à un rythme contrôlé, les pages les plus visitées, les plus explorées et celles d’un pic à venir (promotion, lancement saisonnier).

Le frein d’urgence ralentit l’exploration de tout le site

La troisième recommandation sert de frein d’urgence quand le serveur d’origine reste surchargé pendant le remplissage du cache. Le serveur ou les règles de limitation du CDN peuvent alors renvoyer un code 429 ou 503 (service indisponible). Google limite ce recours à « une courte période (quelques heures, ou un à deux jours au plus) ».

La documentation sur la réduction de la vitesse d’exploration détaille le prix de ce frein. Le ralentissement touche tout le nom d’hôte, par exemple www.exemple.fr, y compris les pages saines. Googlebot découvre alors moins de nouvelles pages. En temps normal, il met déjà environ 20 heures à découvrir une nouvelle page, selon des estimations internes présentées par Gary Illyes le 2 octobre.

Googlebot rafraîchit aussi moins souvent les pages connues : les changements de prix ou de stock des produits peuvent tarder à apparaître dans la recherche. Sur Google Ads, la régie publicitaire de Google, des campagnes peuvent être annulées ou suspendues.

Au-delà d’un ou deux jours, le remède devient risqué : si Googlebot voit ces codes plusieurs jours de suite sur la même page, elle peut sortir de l’index.

Les limites du billet

Le billet ne chiffre pas le phénomène. Google ne dit pas de combien l’exploration augmente après une bascule, ni combien de temps dure la phase de cache froid. Il ne nomme aucun des CDN qui permettent d’exempter les robots vérifiés.

Le billet décrit un fonctionnement existant, sans nouvelle règle. Search Engine Roundtable, un site d’actualité sur les moteurs de recherche, l’a relayé le 11 novembre. Il note que l’essentiel, sinon la totalité, du billet figure déjà dans la documentation d’aide de Google.

Le billet accompagne une vidéo publiée le même jour, dernier épisode de la première saison de « The Non-Canonical Cabinet », la série vidéo de Google Search Central.

Notre analyse

Le billet met par écrit un enchaînement que des propriétaires de sites signalent à Google, selon ses auteurs. Le risque le plus coûteux vient de la réaction : une protection générale qui bloque Googlebot fait sortir des pages de la recherche.

Les plus exposés sont les sites qui ont beaucoup de pages par rapport à leur trafic humain : catalogues de boutiques en ligne, médias aux longues archives, annuaires. Parmi les causes les plus fréquentes d’un pic d’exploration, la documentation de Google cite les calendriers et la navigation à facettes, c’est-à-dire les filtres et tris d’un catalogue.

Un petit site a moins de pages à aller chercher sur le serveur d’origine. Google destine surtout son guide sur le budget d’exploration aux sites de plus d’un million de pages qui changent chaque semaine, ou de plus de 10 000 pages qui changent chaque jour, des seuils qu’il dit approximatifs.

La vérification des robots reste un point faible. PPC Land, site spécialisé dans la publicité en ligne, rapporte un propos tenu par Gary Illyes dans un podcast du 28 octobre. Écrire un script qui se fait passer pour Googlebot lui prendrait « probablement 30 secondes ».

Selon ce site, Google signe déjà, à titre expérimental, une partie des requêtes de son agent d’IA Google-Agent, une signature numérique qui permet de vérifier leur origine. Les requêtes de Googlebot ne sont pas signées : seules ses adresses IP et le DNS permettent pour l’instant de le reconnaître.

Le calendrier donne du poids au billet : le Black Friday, journée de promotions, tombe le 27 novembre 2026, et Google range les pages de promotion parmi celles à préchauffer.

Sources

Image d’en-tête : schéma MACCUS, d’après le blog Google Search Central (11 novembre 2026)

Laisser un commentaire