Budget de crawl d'un site neuf : 1 722 requêtes de robots passées au crible

En bref — Du 20 au 27 juillet 2026, nous avons journalisé chaque requête de robot reçue par crawl-lab.com, un site mis en ligne treize jours plus tôt : 1 916 hits bruts, 1 722 après retrait d'un scanner et de notre propre trafic d'outillage. Trois résultats ressortent. Google pèse 63,4 % de l'exploration, mais Googlebot n'en représente que 23,1 % : les trois quarts viennent de GoogleOther, dont 86,2 % des requêtes ne sont pas des pages mais des charges utiles internes au framework. Le site n'a servi aucun 304 et aucun 429 sur 1 722 réponses, ce qui rend la recommandation de cache HTTP publiée par Google en juillet 2026 inapplicable en l'état sur une pile Next.js hébergée sur Cloudflare. Enfin, pendant les trois jours où nous avons servi des erreurs 500, le crawl de GoogleOther a chuté de 81 % quand celui de Googlebot n'a perdu que 16 % : la capacité partagée n'est pas partagée à parts égales.

Le 22 juillet 2026, Google a réécrit sa documentation sur le budget de crawl et y a inscrit trois mécanismes jusque-là non publiés. Nous les avons détaillés dans ce que la nouvelle documentation Google change vraiment. Restait la question qui intéresse un praticien : ces affirmations tiennent-elles quand on les confronte à des logs réels ?

Cet article y répond avec nos propres données. Nous avons capturé l'intégralité du trafic de robots reçu par notre site pendant ses deux premières semaines d'existence, puis rejoué ces logs dans notre propre analyseur. Aucun chiffre cité ici ne vient d'un outil tiers, d'un panel ou d'une estimation : ce sont 1 722 lignes de log que nous possédons, sur un site dont nous contrôlons chaque déploiement — y compris les deux pannes qui ont servi d'expérience naturelle.

Le dispositif : chaque passage de robot capturé à la source, sans échantillonnage

Le site tourne sur un Worker Cloudflare. Le plan gratuit ne donne pas accès aux logs d'accès bruts, nous les produisons donc nous-mêmes : un point d'entrée maison enveloppe le gestionnaire de requêtes, détecte les user-agents de robots et écrit une ligne au format Combined Log dans un bucket de stockage objet, un fichier par hit. Le trafic humain n'est jamais journalisé, ce qui règle la question des données personnelles à la source.

La fenêtre d'observation court du 20 juillet 2026 à 17 h 23 UTC — création du bucket — au 27 juillet 2026, soit huit jours calendaires. Le domaine a été mis en service le 14 juillet 2026 : au dernier jour de la mesure, le site a treize jours. Il compte alors une soixantaine d'URL indexables, deux versions linguistiques, cinq articles de blogue et vingt-quatre fiches de référence sur les crawlers. C'est un site neuf au sens strict : aucun backlink acquis, aucun historique d'exploration, aucune notoriété de marque.

Cette méthode a un avantage décisif sur Search Console : elle ne connaît ni échantillonnage, ni agrégation, ni fenêtre de quatre-vingt-dix jours, et elle voit les robots non-Google. Elle a aussi une limite que nous assumons plus bas : elle enregistre la réponse une fois celle-ci produite, donc elle ne peut pas enregistrer ses propres défaillances.

Ce que nous avons retiré du jeu de données, et pourquoi

Sur 1 916 hits bruts, 194 n'appartiennent pas à l'objet d'étude et ont été écartés avant tout calcul. Publier une étude de cas sans cette étape reviendrait à publier des chiffres faux d'environ 10 %.

132 hits proviennent d'un scanner de vulnérabilités, émis depuis une seule adresse IP en vingt-trois secondes, sous treize identités de robots différentes — Googlebot, Bingbot, GPTBot, ChatGPT-User, OAI-SearchBot, PerplexityBot, ClaudeBot, CCBot, YandexBot, Baiduspider, DeepSeekBot, xAI-SearchBot et Google-CloudVertexBot. Ses cibles ne laissent aucun doute : /.env, /.git/config, /terraform.tfstate, /firebase-adminsdk.json, une requête POST sur /graphql. À lui seul, il représente 6,9 % du log brut et 89 % de tous les hits usurpés de la période.

38 hits viennent de notre propre poste de travail : un crawl Screaming Frog de vérification, quelques récupérations d'un agent de développement, et des aperçus de partage social. 24 hits supplémentaires sont des passages de Claude-User depuis les serveurs d'Anthropic : comme le détaille notre fiche Claude-User, ce ne sont pas des crawlers mais des récupérations déclenchées par un humain qui pose une question à un assistant — et il est raisonnable de penser que cet humain, c'était nous, en train de travailler sur le site. Nous les avons donc tous retirés.

Ce tri livre déjà une leçon qui ne figure dans aucune documentation : sur un site à faible trafic, votre propre outillage et un unique scanner peuvent représenter le dixième de votre volume d'exploration apparent. Toute conclusion tirée avant nettoyage est une conclusion sur votre propre bruit.

Les affirmations de Google confrontées à nos logs

Le tableau ci-dessous résume nos verdicts. Chaque ligne est détaillée dans la section correspondante.

Confirmé : la capacité est bien partagée, et Googlebot n'en consomme qu'un quart

Sur les 1 722 hits retenus, Google en représente 1 091, soit 63,4 % de l'exploration totale du site. Mais la répartition interne est l'inverse de ce que suggère l'habitude : GoogleOther pèse 835 requêtes, soit 76,5 % du crawl de Google, contre 252 pour Googlebot, soit 23,1 %, et 4 pour Googlebot-Image. Trois requêtes de Google sur quatre ne sont pas des requêtes de Googlebot.

La preuve la plus directe du partage de capacité ne tient pas dans les volumes mais dans les adresses. Les 1 091 hits de Google proviennent de douze adresses IP seulement, toutes situées dans les plages officielles de l'opérateur, et les mêmes adresses servent indifféremment Googlebot et GoogleOther. Une seule d'entre elles a émis 284 requêtes GoogleOther, 77 requêtes Googlebot et une requête Googlebot-Image. Deux adresses concentrent 66 % de tout le crawl de Google. Le « hostload » décrit par la documentation n'est donc pas une abstraction comptable : c'est une file d'attente commune, matérialisée par un pool de machines partagé.

La conséquence opérationnelle est immédiate. Un rapport d'exploration qui ne compte que les lignes contenant « Googlebot » sous-estime la charge réelle imposée par Google d'un facteur quatre sur ce site. Toute mesure de budget de crawl doit segmenter par user-agent complet, pas par marque.

Inédit : 86 % des requêtes de GoogleOther ne sont pas des pages, mais des charges utiles de framework

C'est le résultat le plus surprenant de l'étude, et il ne figure dans aucune documentation. Sur les 835 requêtes de GoogleOther, 720 portent un paramètre `?_rsc=`, soit 86,2 %. Ce paramètre n'est pas le nôtre : il est généré par Next.js pour récupérer la charge utile React Server Components d'une route. Un robot qui exécute le JavaScript de la page déclenche le préchargement des liens visibles, et chacun de ces préchargements devient une requête HTTP distincte dans nos logs.

Rapporté à l'ensemble du site, 42,9 % de tout le trafic de robots reçu en huit jours est constitué de ces requêtes internes au framework. Elles ne pointent vers aucune URL nouvelle : ce sont les mêmes pages, demandées une seconde fois dans un format différent. La documentation de Google mentionne bien que les ressources embarquées — CSS, JavaScript, appels XHR — consomment du budget d'exploration ; nos logs montrent que dans une application moderne à rendu serveur, ce poste peut devenir majoritaire devant les pages elles-mêmes.

Ce n'est pas du gaspillage au sens d'une erreur de configuration : ces requêtes sont le fonctionnement normal du framework et n'ont pas à être bloquées. Mais dans une unité de compte exprimée en temps de connexion serveur, c'est du budget consommé, et il est invisible pour qui ne regarde que ses URL canoniques. C'est aussi un piège pour les outils d'analyse de logs : nous avons dû corriger le nôtre, qui classait initialement ces requêtes comme des « URL à paramètres à corriger » et faisait apparaître un site sain comme massivement gaspilleur.

Confirmé, avec un ordre de priorité que la documentation ne décrit pas

Du 23 juillet à 19 h 57 UTC au 26 juillet à 20 h 43 UTC, notre site a servi 69 erreurs 500 à des robots, à cause de deux défauts d'infrastructure distincts et indépendants du contenu. Nous ne les avons pas provoquées, mais elles constituent l'expérience naturelle que la documentation de Google ne permet pas de mener volontairement : que se passe-t-il quand un site jeune sert des erreurs serveur à Google pendant trois jours ?

La lecture honnête de ce tableau demande une précaution : le pic du 23 juillet s'explique par la publication de vingt-quatre pages ce jour-là, donc par une hausse de la demande d'exploration, pas seulement par la capacité. La comparaison pertinente est celle du 24 au 25 juillet, à contenu constant. GoogleOther passe alors de 206 à 39 requêtes, soit une chute de 81 %, tandis que Googlebot passe de 51 à 43, soit 16 %. Le lendemain de la correction, GoogleOther remonte à 86 quand Googlebot continue de descendre à 29.

Ce que nous en retirons, en le présentant pour ce que c'est — une observation sur un seul site, pas une preuve de causalité : Googlebot maintient un socle d'exploration remarquablement stable, entre 29 et 51 requêtes par jour sur toute la période, quel que soit le taux d'erreur servi, alors que GoogleOther varie d'un facteur vingt et un. Si la capacité est effectivement partagée, elle ne l'est pas symétriquement : la part variable est absorbée par le robot secondaire, et l'indexation de recherche est protégée en dernier. La documentation dit que les robots se partagent une enveloppe ; nos logs suggèrent qu'il existe un ordre de service à l'intérieur de cette enveloppe.

Un détail aggrave le diagnostic et mérite d'être connu : nos erreurs 500 survenaient à l'expiration du cache, pas en continu. Douze URL ont donc servi à la fois des réponses 200 et des réponses 500 dans la même fenêtre, ce qui est le cas le plus difficile à repérer — le site paraît debout à toute vérification manuelle. Seul le croisement URL × code de réponse dans les logs le révèle, comme nous le détaillons dans notre guide sur les erreurs 404 et 5xx vues par les crawlers.

Réfuté en pratique : zéro réponse 304 sur 1 722, et ce n'est pas de la négligence

La nouveauté la plus concrète de la documentation de juillet 2026 est la recommandation de prendre en charge le cache HTTP et le code 304 (Not Modified), afin qu'une réexploration ne coûte pas le prix d'une réponse complète. Sur nos 1 722 réponses, le nombre de `304` servis est exactement zéro.

Nous avons vérifié pourquoi, en interrogeant le site en direct plutôt qu'en supposant. Aucune page HTML du site n'émet d'en-tête ETag ni Last-Modified : ni les pages rendues à la demande, ni les pages entièrement statiques, qui ne portent qu'un Cache-Control avec s-maxage. Une requête accompagnée d'un If-Modified-Since reçoit un 200 complet. Le seul fichier du site qui expose un ETag est robots.txt, et cet ETag est renvoyé sans guillemets — une forme non conforme à la RFC 9110 — si bien qu'un client qui le renvoie en If-None-Match obtient malgré tout un 200.

La conclusion n'est pas que nous avons mal configuré le site, mais que la recommandation de Google est aujourd'hui inapplicable par défaut à une classe entière de piles techniques modernes. Un site Next.js déployé en périphérie ne fournit pas de validateur de cache pour son HTML, et rien dans la configuration standard ne permet de l'ajouter sans écrire du code. Pour les millions de sites construits sur ce type de socle, la recommandation de juillet 2026 restera lettre morte tant que les frameworks ne l'implémenteront pas en amont. Un serveur Apache ou Nginx servant des fichiers statiques, lui, la respecte depuis toujours sans le savoir.

Le corollaire pour l'audit est simple : une part de 304 nulle dans vos logs n'est pas nécessairement un défaut à corriger, c'est d'abord une information sur votre hébergement. Vérifiez si votre serveur peut seulement émettre un validateur avant de conclure à une négligence.

Nuancé : une limite « volontairement basse » ne se voit pas à la découverte

La documentation affirme que chaque site démarre avec la même limite de capacité par défaut, décrite comme conservatrice, puis ajustée dans le temps. Notre site est le cas d'école : treize jours d'existence, aucun backlink, aucun historique. Nous nous attendions à une exploration parcimonieuse.

L'observation la plus nette dit autre chose. Nous avons publié un article le 26 juillet 2026 à 21 h 49 min 36 s UTC — l'horodatage de création dans notre CMS. Le premier passage de Googlebot sur cette URL est daté du même jour à 21 h 55 min 38 s, depuis une adresse IP vérifiée de Google : six minutes et deux secondes après la publication. La version anglaise a été atteinte deux minutes plus tard. Aucune soumission manuelle à Search Console n'a été faite dans cet intervalle.

Il n'y a pas de contradiction formelle avec la documentation : la capacité plafonne le débit, elle ne règle pas la latence de découverte, et Google explorait le site de façon soutenue à cet instant précis. Mais pour un praticien, la nuance est importante : sur un site neuf, techniquement sain et correctement relié par ses sitemaps, la vitesse de découverte n'est pas le facteur limitant. Le plafond de capacité, s'il existe, ne s'est jamais manifesté chez nous sous forme de lenteur à explorer les nouveautés. Il s'est manifesté sous forme de volume total, et surtout de réactivité aux erreurs.

Autre observation cohérente avec cette lecture : le jour où nous avons publié vingt-quatre pages d'un coup, Google est passé de 118 à 363 requêtes quotidiennes, soit un triplement en vingt-quatre heures. La demande d'exploration suit la publication de très près, sans période d'observation apparente.

Confirmé : les 4xx ne coûtent presque rien, mais ils ruinent le diagnostic

La page « mythes » de Google affirme que les réponses en 4xx, hors 429, ne gaspillent pas de budget d'exploration. Nos chiffres vont dans ce sens : après nettoyage, le site n'a servi que 19 réponses `404`, soit 1,1 % du crawl, réparties sur 13 URL distinctes. Huit d'entre elles sont des fichiers JavaScript périmés, réclamés par des robots qui avaient encore en mémoire le HTML d'un déploiement antérieur. Sept correspondent à deux anciennes URL de blogue restées sans redirection. Le reste relève du bruit.

Le vrai enseignement est ailleurs. Avant nettoyage, le même site affichait 101 réponses `404` sur 80 URL, dont l'immense majorité pointait vers `/.env`, `/.git/config` ou `/firebase-adminsdk.json` — et ces requêtes portaient les user-agents de Googlebot, Bingbot, GPTBot ou PerplexityBot. Un analyste pressé aurait conclu que les robots d'IA gaspillent le budget de crawl sur des chemins techniques inexistants. La conclusion aurait été entièrement fausse : ces 132 requêtes venaient d'une seule adresse IP en vingt-trois secondes.

C'est la raison pour laquelle la vérification d'authenticité par plages d'adresses IP n'est pas un raffinement mais un prérequis. Sur nos données, 1 296 hits étaient vérifiables ; 7 seulement ont été identifiés comme usurpés après nettoyage, contre 64 avant, soit 89 % des usurpations imputables au seul scanner. Un audit qui saute cette étape ne mesure pas le comportement de Google, il mesure celui de ses imitateurs.

Près d'un quart du budget part dans robots.txt et les sitemaps

Sur un site de soixante-dix pages, la surprise vient de la répartition. 417 requêtes sur 1 722, soit 24,2 % de tout le trafic de robots, portent sur `robots.txt` ou sur les sitemaps — des fichiers qui ne contiennent aucun contenu éditorial. C'est le deuxième poste de dépense du site après la page d'accueil.

Le détail par robot est plus parlant encore. Googlebot a consacré 122 de ses 252 requêtes à `robots.txt`, soit 48,4 % de son activité sur notre site ; GoogleOther, lui, n'a jamais demandé ce fichier une seule fois — nouvelle confirmation que les deux robots partagent une infrastructure, l'un récupérant les directives dont l'autre bénéficie. Du côté des robots d'IA, ClaudeBot a consacré 36 % de ses requêtes à robots.txt et 38 % aux sitemaps, soit près des trois quarts de son activité sur l'infrastructure de crawl plutôt que sur les pages. Bingbot, lui, a passé 84 % de son temps dans les sitemaps.

Ce phénomène est une caractéristique des petits sites : le coût fixe de vérification des directives ne diminue pas avec le nombre de pages, il devient donc proportionnellement énorme. Il ne se corrige pas — un robot doit relire robots.txt — mais il doit être exclu du calcul de gaspillage, sous peine de faire apparaître un site parfaitement sain comme dilapidant les trois quarts de son budget. Nous détaillons le raisonnement dans notre guide sur les KPI de l'analyse de logs.

Ce que nos logs ne permettent pas de mesurer

L'unité de compte décrite par Google en juillet 2026 est le temps de connexion : le total du temps pendant lequel votre serveur maintient des connexions ouvertes pour ses robots. Nos logs ne contiennent pas cette information. Le format que nous générons ne porte ni durée de traitement, ni taille de réponse — le champ d'octets vaut - sur les 1 722 lignes, parce que les réponses sont diffusées en flux et n'ont pas de longueur connue au moment de l'écriture. Nous ne pouvons donc ni mesurer notre consommation dans l'unité de Google, ni la comparer d'une page à l'autre.

Il y a plus gênant, et c'est une limite intrinsèque à toute journalisation faite par l'application elle-même : nos logs ne peuvent pas enregistrer leurs propres pannes. Avant le 23 juillet, notre Worker dépassait régulièrement son quota de temps processeur au passage d'un robot enchaînant les pages, ce qui produisait des erreurs d'infrastructure servies avant que notre code n'ait la main. Ces erreurs n'apparaissent nulle part dans les 1 722 lignes analysées : le site tombait sous la charge de crawl sans laisser de trace dans son propre journal.

Nous le signalons parce que c'est exactement le scénario que la documentation de Google décrit — la latence et les erreurs font baisser la capacité — et que nous sommes incapables de le quantifier avec nos propres données. Pour qui contrôle un serveur Apache ou Nginx, la réponse tient en un champ de configuration : %D ou $request_time dans le format de log, et l'unité de compte de Google devient mesurable. C'est le premier réglage que nous recommandons avant toute analyse sérieuse, et il est expliqué dans notre guide pour récupérer ses logs serveurs.

Le bilan à deux semaines, en dix chiffres

Si nous devions ramener ces deux semaines à trois enseignements pour un site qui démarre, les voici. Premièrement, votre budget de crawl n'est pas dépensé là où vous le croyez : chez nous, 24,2 % est parti dans des fichiers de directives et 42,9 % dans des requêtes générées par le framework, avant même qu'une page d'article ne soit servie. Deuxièmement, la santé serveur produit un effet mesurable en quarante-huit heures : trois jours d'erreurs 500 ont coûté 81 % du volume d'exploration de GoogleOther, avec un retour à la normale amorcé dès le lendemain de la correction. Troisièmement, aucun de ces chiffres n'était visible dans Search Console : ni la part de GoogleOther, ni les requêtes de framework, ni les identités usurpées, ni l'absence totale de 304.

Nous republierons cette étude à trois mois, avec le même protocole et sur la même propriété, pour observer si la capacité accordée évolue une fois l'historique d'exploration constitué. C'est la seule manière honnête de tester l'affirmation la plus intrigante de la documentation de juillet 2026 : celle d'un ajustement progressif dans le temps, dont Google ne donne ni le délai ni l'amplitude.

→ Rejouez vos propres logs dans l'analyseur Crawl Lab : segmentation par robot et par code de réponse, vérification d'authenticité par plages d'IP, détection des requêtes de framework. Tout se passe dans votre navigateur, aucun fichier n'est envoyé sur un serveur.

À lire aussi

• Budget de crawl : ce que la nouvelle documentation Google change vraiment
• Analyse de log serveur pour le SEO : le guide complet (2026)
• Erreurs 404 et 5xx vues par les crawlers : les repérer dans les logs SEO
• Analyse de log SEO : quels KPI suivre et comment les interpréter