Budget de crawl : Google révise sa documentation et recommande le code 304

Google a mis en ligne le 22 juillet 2026 une version révisée de « Optimize your crawl budget » (optimiser son budget d’exploration), son guide pour les sites très volumineux ou mis à jour très souvent. Le journal des modifications parle d’un texte « peaufiné et clarifié », pour gagner en « clarté, cohérence terminologique et fluidité » (traduction). Sur Search Engine Roundtable, Barry Schwartz y voit surtout des retouches de formulation, sans effet sur la façon dont Googlebot explore les sites. Trois ajouts apportent pourtant des informations nouvelles.

L’essentiel

• Tous les sites démarrent avec la même limite de capacité d’exploration par défaut, que Google qualifie de prudente.
• Cette limite est commune à tous les crawlers de Google, même si chacun a sa propre demande.
• Deux bonnes pratiques entrent dans le guide : accélérer les réponses du serveur et prendre en charge le code 304.
• Le public visé ne change pas : plus d’un million de pages, ou plus de 10 000 pages modifiées chaque jour.

Limite de capacité : un point de départ commun, relevé ensuite

Dans sa version actuelle, la page présente la limite de capacité d’exploration comme un plafond sur le temps total pendant lequel le serveur garde des connexions ouvertes pour Google, compte tenu du nombre de connexions parallèles et de leur durée. Elle lui donne désormais un second nom, « hostload », celui qu’on retrouve dans le message « Hostload exceeded » de l’outil d’inspection d’URL. Une phrase fait aussi son apparition : « Chaque site démarre avec la même limite de capacité d’exploration par défaut, prudente » (traduction). Si la demande augmente et que le site reste en bonne santé, les systèmes de Google relèvent ensuite cette limite d’eux-mêmes, avec le temps.

Le passage sur la santé du crawl gagne en précision. L’ancienne version se contentait d’un site qui répond vite « pendant un moment ». La nouvelle parle de temps de réponse, latence et Time to First Byte compris, qui restent stables ou s’améliorent. À l’inverse, la limite baisse quand le site ralentit, renvoie des erreurs serveur 5xx ou des signaux de limitation comme le code HTTP 429. La formule « Google a beaucoup de machines, mais pas une infinité » disparaît, elle aussi : les ressources de Google sont désormais « étendues, mais finies », et il faut les répartir sur tout le web (traduction).

Une capacité partagée entre Googlebot, AdsBot et Google Shopping

La page rappelle que chaque robot a sa propre demande d’exploration. AdsBot passe plus souvent sur un site qui diffuse des annonces dynamiques, Google Shopping s’intéresse aux produits des flux marchands, et la demande de Googlebot dépend de la taille du site, de sa fréquence de mise à jour, de la qualité et de la pertinence de ses pages. Nouveauté du 22 juillet : la limite de capacité, elle, est commune à tous les crawlers. Une forte demande de l’un peut donc réduire la marge laissée aux autres. Google pose le principe sans donner d’ordre de grandeur ni de règle de priorité entre robots.

Avant et après : les changements relevés

La comparaison s’appuie sur la capture de la page du 15 juillet 2026 dans la Wayback Machine, que Search Engine Roundtable met en regard de la version actuelle.

Passage	Avant (15/07/2026)	Après (22/07/2026)
Rapport cité	« Index Coverage »	« Page Indexing » (Indexation des pages)
Limite de capacité	Pas d’autre nom, pas de valeur de départ	« hostload », même limite par défaut pour tous les sites
Santé du crawl	Réponse rapide « pendant un moment »	Latence et TTFB stables, 5xx et 429 cités
Partage entre robots	Non mentionné	Limite commune à tous les crawlers
Bonnes pratiques	Ni cache HTTP ni vitesse du serveur	Vitesse du serveur et code 304 ajoutés

Dans le paragraphe consacré au robots.txt, « serving limit » devient « crawl capacity limit », conformément à l’harmonisation des termes annoncée. Le conseil, lui, ne change pas : bloquer des URL dans le robots.txt ne reporte pas le budget libéré sur d’autres pages, sauf si Google bute déjà sur la limite de capacité du site.

Code 304 et ETag : ce que le serveur doit renvoyer

La recommandation tient en une ligne : prendre en charge le code 304 Not Modified. Quand une page n’a pas changé depuis le dernier passage, le serveur répond 304 sans renvoyer le contenu, et Google réutilise sa copie en cache, ce qui économise de la bande passante. La page ne détaille pas les en-têtes. Pour cela, il faut remonter au billet de Gary Illyes du 9 décembre 2024, « Crawling December: HTTP caching » : les crawlers de Google gèrent la paire ETag / If-None-Match et la paire Last-Modified / If-Modified-Since. Google y recommande « fortement » l’ETag, moins sujet aux erreurs selon lui, et conseille de renseigner les deux en-têtes quand c’est possible. Le billet estimait à 0,017 % la part des récupérations pouvant être servies depuis le cache, contre 0,026 % dix ans plus tôt.

Sur WordPress, le cœur du CMS ne traite ces requêtes conditionnelles que pour les flux RSS. Pour les pages HTML, tout dépend de la pile technique. Un cache de pages servi en fichiers statiques par Nginx ou Apache renvoie en général ETag et Last-Modified ; une page générée par PHP à chaque appel, non. Le contrôle prend deux commandes : relever l’ETag d’une URL avec curl -I, puis rejouer la requête avec un en-tête If-None-Match et vérifier que la réponse est bien un 304. En e-commerce, le risque est inverse. L’ETag ou la date Last-Modified doit changer dès que le prix, le stock ou la disponibilité bougent, faute de quoi Google garde une fiche produit périmée. Et un Last-Modified recalculé à l’heure courante à chaque requête annule tout le bénéfice.

Qui est concerné : les gros sites, avant tout

Le périmètre n’a pas bougé. Le guide vise les sites de plus d’un million de pages uniques dont le contenu change environ une fois par semaine, ceux de plus de 10 000 pages qui changent chaque jour, et ceux dont une grande part des URL est classée « Détectée, actuellement non indexée » dans la Search Console. Google précise que ces chiffres sont des estimations, pas des seuils. Pour les autres sites, la page juge suffisant de tenir son sitemap à jour et de consulter régulièrement le rapport Indexation des pages.

Ce que j’en retiens

La phrase sur la limite par défaut est la plus utile du lot. Elle répond à une question qui revient à chaque lancement ou migration : aucun site ne part avec un crédit d’exploration élevé, il se gagne avec un serveur qui tient la charge. Pour un nouveau site de plusieurs dizaines de milliers d’URL, je regarderais d’abord le temps de réponse moyen dans le rapport Statistiques sur l’exploration de la Search Console, avant de chercher ailleurs l’explication d’une exploration lente.

En e-commerce, c’est le partage de capacité entre robots que je surveillerais. Un catalogue qui alimente Shopping et des annonces dynamiques fait travailler plusieurs robots sur le même hôte. Le même rapport ventile les requêtes par type de Googlebot, et c’est là qu’on verra si l’un d’eux prend le dessus. Le 304, lui, se vérifie en deux minutes avec curl. Sur un site de quelques centaines de pages, n’en attendez pas d’effet visible.