Budget de crawl : ce que la nouvelle documentation Google change vraiment

En bref — Le 22 juillet 2026, Google a réécrit sa page consacrée au budget de crawl et y a ajouté trois affirmations qu'il n'avait jamais publiées : tout site démarre avec la même limite de capacité d'exploration par défaut, volontairement basse ; cette capacité est partagée entre tous les robots de Google ; et répondre en 304 (Not Modified) est désormais une recommandation explicite pour économiser du budget. La documentation a aussi changé d'adresse : elle ne dépend plus de Search Central mais d'un site dédié, developers.google.com/crawling, ce qui acte que l'exploration est une infrastructure commune à Search, Shopping, News, AdSense et Gemini. Au 26 juillet 2026, la version française de cette page est encore celle du 5 mars 2026 et ne contient aucune de ces nouveautés. Aucun de ces mécanismes n'est directement mesurable dans Search Console : seuls les logs serveur permettent de voir quel robot de Google consomme réellement la capacité, et à quel coût.

Une mise à jour de documentation n'est presque jamais un événement. Celle-ci en est un, pour une raison simple : Google n'a pas seulement reformulé sa page sur le budget de crawl, il y a écrit noir sur blanc trois mécanismes que la communauté SEO déduisait des logs depuis des années sans jamais pouvoir les citer. Le changement a été repéré le 22 juillet 2026 par Barry Schwartz et Glenn Gabe. Il s'inscrit dans une série de modifications entamée en novembre 2025, toutes orientées dans la même direction : Google veut explorer le web moins cher, et il commence à expliquer comment il rationne.

Cet article ne paraphrase pas la documentation. Il compare l'ancienne version à la nouvelle, isole ce qui est réellement inédit, et traduit chaque nouveauté en vérification concrète à mener dans vos fichiers de logs.

La documentation a quitté Search pour une section « infrastructure d'exploration »

Le guide sur le budget de crawl ne vit plus sous developers.google.com/search/. Depuis décembre 2025, il est hébergé sur un site distinct, developers.google.com/crawling/, aux côtés de la spécification robots.txt, de la liste des user-agents, des codes de statut HTTP et du diagnostic des erreurs DNS. Google justifie ce déménagement par le fait que son infrastructure d'exploration sert bien d'autres produits que la recherche : Shopping, News, Gemini, AdSense.

Ce n'est pas une réorganisation cosmétique, c'est un changement de périmètre. Le budget de crawl cesse d'être un concept SEO pour devenir un concept d'infrastructure. La conséquence pratique est visible dans la dernière section de la page, qui parle d'optimiser la qualité de son contenu « pour le produit Google que l'on vise » : un site e-commerce et un média n'ont plus le même levier, parce qu'ils ne sont pas explorés par les mêmes robots ni pour les mêmes raisons.

Tous les sites démarrent avec la même limite, volontairement basse

C'est la phrase la plus neuve de la mise à jour : chaque site débute avec la même limite de capacité d'exploration par défaut, décrite comme conservatrice, et Google l'ajuste ensuite automatiquement dans le temps si la demande augmente et si le site reste en bonne santé. Ce point n'avait jamais été documenté.

L'implication est directe pour trois situations. Un nouveau site n'est pas bridé parce qu'il est nouveau : il est bridé parce que tout le monde l'est au départ, et il monte en fonction de son comportement serveur. Une migration vers un nouveau nom d'hôte repart du même plancher, puisque le budget est calculé par nom d'hôte. Et une remise en cause de la capacité après un incident serveur ne se corrige pas d'un coup : l'ajustement est décrit comme progressif, sans qu'aucun délai ne soit donné.

La capacité d'exploration est partagée entre tous les robots de Google

Deuxième nouveauté, et probablement la plus lourde de conséquences : chaque robot de Google a sa propre demande d'exploration, mais la limite de capacité, elle, est commune. Une forte demande d'un robot réduit donc ce qui reste disponible pour les autres.

Concrètement, AdsBot qui explore vos cibles d'annonces dynamiques, Storebot-Google qui parcourt votre catalogue via vos flux marchands et Googlebot-Image qui recharge vos visuels puisent dans la même enveloppe de temps serveur que Googlebot. Un site e-commerce qui lance une grosse campagne Shopping peut ainsi voir l'exploration de ses pages éditoriales ralentir, sans qu'aucun changement n'ait été fait côté SEO. Jusqu'ici, ce phénomène relevait de l'observation empirique dans les logs ; il est maintenant documenté.

Le budget se mesure en temps de connexion, pas en nombre d'URL

L'ancienne version définissait la limite de capacité comme un nombre maximal de connexions parallèles, assorti d'un délai d'attente entre deux explorations. La nouvelle la définit comme le temps total pendant lequel votre serveur maintient des connexions ouvertes pour Google, en tenant compte à la fois du nombre de connexions simultanées et de leur durée. Google donne au passage le nom interne de cette limite : le hostload, celui-là même qui apparaît dans le message « Charge de l'hôte dépassée » de l'outil d'inspection d'URL.

La différence n'est pas sémantique. Dans l'ancien modèle, on raisonnait en nombre de requêtes ; dans le nouveau, l'unité est la seconde de connexion. Une page lente à générer coûte donc structurellement plus cher qu'une page rapide, à volume d'URL identique. C'est la formalisation d'un arbitrage que les analyses de logs montrent depuis longtemps : réduire le temps de réponse moyen servi aux robots élargit mécaniquement la couverture d'exploration, alors que supprimer quelques URL ne la change qu'à la marge.

Les 429 et la latence font baisser votre capacité

L'ancienne rédaction se contentait d'indiquer que la limite montait si le site répondait rapidement pendant un certain temps, et descendait en cas de lenteur ou d'erreurs serveur. La nouvelle est nettement plus précise : elle nomme la latence et le Time-to-First-Byte comme indicateurs de santé, et ajoute les codes 429 (Too Many Requests) à la liste des signaux qui font baisser la limite, aux côtés des 5xx.

Ce détail mérite un audit à lui seul. Beaucoup de sites servent des 429 à Googlebot sans le savoir, parce qu'un pare-feu applicatif, une règle de rate limiting sur le CDN ou un module anti-scraping considère un pic de crawl comme une attaque. Le site se bride alors lui-même, et l'effet est durable puisque la remontée de la limite est progressive. Ces réponses n'apparaissent nulle part ailleurs que dans les logs serveur, filtrés sur les IP vérifiées de Google.

Google recommande désormais explicitement le cache HTTP et les réponses 304

La section sur l'efficacité de chargement s'est enrichie de deux recommandations qui n'y figuraient pas. La première tient de l'évidence : optimiser les temps de réponse serveur. La seconde est plus intéressante : utiliser le cache HTTP et prendre en charge le code 304 (Not Modified). Si une page n'a pas changé depuis la dernière exploration, un 304 indique à Google de réutiliser sa version en cache, ce qui économise la bande passante et les ressources du serveur.

La documentation technique des robots précise le fonctionnement attendu : Google prend en charge le couple ETag / If-None-Match et le couple Last-Modified / If-Modified-Since, et recommande ETag en priorité, parce qu'il évite les problèmes de format de date. Autrement dit, Google ne demande plus seulement de réduire le nombre d'URL à explorer, il demande de rendre chaque réexploration moins coûteuse. C'est cohérent avec le passage à une unité de mesure en temps de connexion.

Les mythes ont désormais leur propre page, et une contradiction apparente

La section « mythes et réalités » qui concluait l'ancien guide a été détachée en décembre 2025 pour devenir une page autonome. Elle conserve ses réponses de référence : la règle non standard crawl-delay n'est pas prise en compte par Google, compresser ses sitemaps n'augmente pas le budget, l'exploration n'est pas un facteur de positionnement, et les URL alternatives comme AMP ou hreflang ainsi que les ressources embarquées (CSS, JavaScript, appels XHR) consomment bien du budget.

Un point de cette page mérite d'être lu attentivement, parce qu'il est régulièrement mal cité : Google y affirme que les pages répondant en 4xx, à l'exception des 429, ne gaspillent pas de budget de crawl, au motif que la requête n'a rapporté qu'un code et aucun contenu. Cela semble contredire le guide sur le budget, qui demande d'éliminer les soft 404. Il n'y a pas de contradiction : une vraie 404 coûte une requête sèche et sort l'URL de la file d'attente, tandis qu'une soft 404 renvoie un 200 avec une page complète, donc du temps de connexion réel, et reste explorée indéfiniment. La leçon est que le coût d'une erreur dépend du code servi, pas de l'apparence de la page.

Ce que la documentation ne dit toujours pas

Trois zones d'ombre subsistent, et il est plus honnête de les nommer que de les combler par des estimations. Google ne donne aucun chiffre : ni la valeur de la limite par défaut, ni le seuil au-delà duquel un temps de réponse est jugé problématique, ni le délai de remontée après un incident, décrit uniquement comme progressif. Google ne dit pas non plus précisément quels robots entrent dans la capacité partagée : la formulation englobe l'ensemble des robots, mais le statut d'un agent comme Google-Extended, qui régit l'usage du contenu pour l'entraînement des modèles Gemini, n'est pas explicité. Enfin, la documentation reste muette sur les robots non-Google, alors qu'ils consomment les mêmes ressources serveur.

Ce dernier point est le plus structurant en 2026. GPTBot, ClaudeBot, PerplexityBot ou Bytespider ne consomment pas le budget de crawl de Google au sens strict, puisque cette enveloppe est calculée par Google pour Google. Mais ils allongent vos temps de réponse et peuvent provoquer les erreurs et les 429 qui, eux, font baisser la limite accordée par Google. La charge des robots IA agit donc indirectement sur votre exploration par Googlebot, par le canal de la santé serveur.

La version française est en retard d'une version

Au 26 juillet 2026, la page française porte la date du 5 mars 2026, contre le 22 juillet pour la version anglaise. Elle décrit encore la limite de capacité comme un nombre de connexions parallèles assorti d'un délai d'attente, ne mentionne ni le plancher par défaut commun à tous les sites, ni le partage de la capacité entre robots, ni les 429, ni la recommandation sur le cache HTTP et les 304.

C'est un réflexe à prendre pour toute veille sur la documentation Google : les traductions sont publiées avec un décalage variable, et un article rédigé de bonne foi à partir de la version localisée peut être obsolète le jour de sa parution. La date de dernière mise à jour figure en bas de chaque page, dans les deux langues, et la comparaison prend dix secondes. Le changelog officiel de la documentation d'exploration propose par ailleurs un flux RSS, qui reste le moyen le plus fiable de ne pas rater ce type de réécriture silencieuse.

Ce que ça change concrètement dans votre analyse de logs

Aucune des nouveautés de juillet 2026 n'est vérifiable dans Search Console. Le rapport Statistiques d'exploration segmente bien par type de Googlebot, mais il agrège, échantillonne, se limite à quatre-vingt-dix jours et ne montre évidemment aucun robot extérieur à Google. Les affirmations de la nouvelle documentation ne deviennent actionnables que confrontées à vos logs. Quatre vérifications découlent directement du texte.

Répartir le crawl par user-agent Google, et pas seulement « Googlebot ». Puisque la capacité est partagée, il faut mesurer la part de chaque robot : Googlebot, Googlebot-Image, Googlebot-News, AdsBot-Google, Storebot-Google, Google-Extended. Si un seul d'entre eux capte une fraction inattendue des requêtes, vous tenez l'explication d'une baisse d'exploration ailleurs.

Chercher les 429 servis aux IP vérifiées de Google. Leur simple présence signale que votre infrastructure bride Google, et la documentation indique désormais que cela fait baisser votre limite. C'est la correction au meilleur rapport effort/impact de toute la liste.

Mesurer le temps de réponse servi aux robots, pas celui mesuré par vos outils de performance. Les robots visitent massivement des URL peu ou pas mises en cache : pagination profonde, facettes, archives. Leur TTFB réel y est souvent bien pire que celui des pages vues par vos visiteurs. Le champ $request_time sur Nginx ou %D sur Apache doit être présent dans votre format de log pour que cette mesure soit possible ; sans lui, l'unité de compte de Google vous reste invisible.

Surveiller la part de 304 dans les réponses servies aux robots. Une part nulle indique que votre serveur ne renvoie ni ETag ni Last-Modified exploitable, et que chaque réexploration coûte une réponse complète. C'est le levier que Google a explicitement ajouté en juillet, et il se vérifie en une seule agrégation des codes de statut par robot.

→ L'analyseur de logs Crawl Lab segmente automatiquement le crawl par robot et par code de réponse : repérez en quelques secondes la part de chaque agent Google dans votre capacité, les 429 servis par erreur et votre taux de 304. Tout se passe dans votre navigateur, sans upload.

À lire aussi

• Analyse de log serveur pour le SEO : le guide complet (2026)
• Erreurs 404 et 5xx des crawlers : les voir dans les log SEO
• Analyse de logs SEO : quels KPI suivre et comment les interpréter