Le crawl à l'ère des robots IA

—Dix points si vous ne lisez que ça

1. Le crawl n'est plus un sujet Search, et Google l'a acté par sa documentation. En novembre 2025, toutes les pages sur le crawl ont quitté Search Central pour un site autonome, developers.google.com/crawling, qui liste côte à côte Search, Gemini, Vertex AI, Shopping, AdSense et NotebookLM.¹¹ Le guide du crawl budget ne parle plus de Google mais du « produit Google que vous ciblez ».¹
2. Gary Illyes l'écrit noir sur blanc. « Googlebot n'est qu'un utilisateur de quelque chose qui ressemble à une plateforme de crawl centralisée », et « quand vous voyez Googlebot dans vos logs, vous regardez simplement Google Search ».²⁴ A · Confirmé
3. Le crawl n'est pas un facteur de classement. Google le déclare explicitement dans sa page « Mythes et faits sur le crawl », publiée le 18 décembre 2025 — qui tranche aussi que les 4xx (sauf 429) ne gaspillent aucun budget, que crawl-delay est ignoré, et que compresser ses sitemaps n'apporte rien.²
4. Le web est devenu non-cacheable, et c'est le vrai levier. La part des requêtes servies depuis un cache est passée de 0,026 % à 0,017 % en dix ans.²⁰ Sur un web dont la page mobile médiane pèse 2,3 Mo, le 304 Not Modified est le levier de crawl le plus efficace et le moins déployé.
5. Le user-agent ne prouve rien, et les fichiers censés le corriger sont mal entretenus. Google régénère quotidiennement ses plages IP ; le fichier de Bing porte un horodatage de janvier 2024 et celui de Perplexity de février 2025. Une vérification stricte produit donc des faux négatifs mécaniques. Et le fichier googlebot.json, encore présent dans des centaines de scripts publiés, renvoie un 404.
6. Les robots IA gaspillent massivement. Mesure Vercel × MERJ sur un mois : 34,82 % des requêtes de ChatGPT et 34,16 % de celles de Claude tombent sur des 404, contre 8,22 % pour Googlebot. Aucun des grands crawlers IA n'exécute JavaScript — Claude télécharge du JS dans 23,84 % de ses requêtes sans jamais l'exécuter.⁴⁵ C · Mesuré
7. Bloquer Google-Extended ne vous sort pas des AI Overviews. Google le documente : ce token « n'a pas de chaîne user-agent HTTP distincte » et ne pilote que l'entraînement de Gemini. Les AI Overviews sont une surface de Search, alimentée par Googlebot et gouvernée par l'éligibilité au snippet.¹⁷ C'est pourtant l'un des conseils les plus recopiés du web.
8. Bloquer GPTBot ne vous sort pas de ChatGPT. OpenAI sépare explicitement l'entraînement (GPTBot) de la citation dans ChatGPT Search (OAI-SearchBot) : « chaque réglage est indépendant des autres ».³¹ Les presets WAF « bloquer les bots IA » font exactement l'erreur inverse de celle que leurs utilisateurs croient corriger.
9. Le coût du blocage est réel, mais bien plus faible qu'on ne le dit — et il dépend de votre taille. La seule étude causale disponible (différences-en-différences échelonnées, Rutgers × Wharton) mesure −7 % de visites hebdomadaires pour les éditeurs du top 50, un effet non significatif pour les petits.⁴⁷ Le chiffre de −23 % encore massivement cité provient d'une version antérieure du même papier, révisée depuis. C · Mesuré
10. Trois régulateurs constatent simultanément le même couplage. L'Arcep en janvier 2026 : « il n'existe pas de mécanisme permettant de filtrer spécifiquement les crawlers d'IA sans entraîner des effets négatifs […] sur le référencement ».⁶⁰ La CMA a imposé à Google une clause anti-représailles le 3 juin 2026⁶², et la Commission européenne a ouvert une procédure article 102 le 9 décembre 2025 visant précisément l'impossibilité de refuser « sans perdre l'accès à Google Search ».⁶³

—Comment nous avons travaillé

Cette étude ne repose sur aucune donnée client. Tout ce qu'elle avance est soit une source primaire publique, soit une mesure tierce dont la méthodologie est publiée, soit un protocole que vous pouvez exécuter vous-même sur votre propre serveur.

Quatre niveaux de preuve sont affichés au fil du texte :

Trois règles que nous nous sommes imposées

1. Aucun chiffre sans date ni périmètre. Les ratios « crawl-to-refer » qui circulent en 2026 sont spectaculaires, massivement recopiés — et se contredisent entre eux d'un facteur dix selon la source et la fenêtre. Nous n'en citons que ceux publiés directement par Cloudflare, avec leur période exacte.

2. Signaler quand la source primaire manque. Plusieurs affirmations très répandues n'ont aucune source primaire : le respect de Retry-After par Googlebot n'est documenté nulle part, la position de Google sur IndexNow n'a jamais été publiée, et ByteDance ne documente rien sur Bytespider. Nous le disons plutôt que de combler.

3. Distinguer le déclaratif du contraignant. C'est la distinction structurante de tout le domaine, et elle est presque toujours escamotée. Un Disallow est une préférence que le robot honore s'il le veut. Un blocage par plage IP est une contrainte. Cloudflare l'écrit dans son propre billet : les signaux de contenu « expriment des préférences ; ce ne sont pas des contre-mesures techniques contre le scraping ».³⁷

Le fil rouge

01Novembre 2025 : Google sort le crawl du périmètre Search

Le changement le plus important de ces deux ans n'est pas un algorithme. C'est une réorganisation de documentation — et elle dit exactement ce qui a changé dans l'infrastructure.

Jusqu'en 2025, tout ce que Google publiait sur le crawl vivait dans Search Central, sous developers.google.com/search/docs/crawling-indexing/. Le crawl y était un chapitre du référencement, au même titre que les données structurées ou les sitemaps.

En novembre 2025, l'ensemble a été déplacé vers un site autonome : developers.google.com/crawling, intitulé « Google crawling infrastructure ».¹¹ A · Confirmé La page d'accueil de ce nouveau site ne liste pas « Google Search ». Elle liste, côte à côte : Search, Gemini, Vertex AI, Shopping, AdSense, NotebookLM.

Le vocabulaire de la documentation a suivi. Le guide du crawl budget ne dit plus « pour que Google explore mieux votre site » ; il parle désormais du « produit Google que vous ciblez » — the Google product you're targeting.¹ C'est une phrase de plateforme, pas une phrase de moteur de recherche.

Ce que la migration a cassé au passage

La plupart des anciennes URL redirigent correctement. Une exception notable : /search/docs/crawling-indexing/http-caching, la page qui documentait le cache conditionnel, renvoie aujourd'hui un 404 sans redirection. Son contenu ne survit que dans le billet de blog de décembre 2024 qui l'accompagnait.²⁰ Comme nous le verrons en section 20, c'est précisément le levier le plus efficace du domaine qui a perdu sa page de référence.

Conséquence pratique immédiate : toute documentation interne, tout audit, tout article de blog antérieur à novembre 2025 pointe vers des URL au mieux redirigées, au pire mortes. Si vous maintenez une base de connaissances, c'est le moment de la reprendre.

02« Googlebot n'est qu'un utilisateur d'une plateforme centralisée »

Si la migration de documentation était le signe, la confirmation explicite est venue de Gary Illyes, analyste chez Google, le 31 mars 2026 :

Ces deux phrases se lisent ensemble. La première dit que l'infrastructure de crawl est mutualisée entre les produits Google. La seconde dit que le user-agent Googlebot ne représente qu'un de ces consommateurs — celui de Search.

La conséquence qui gêne : vous ne pouvez pas mesurer le crawl IA de Google

Google publie un token robots.txt nommé Google-Extended, destiné à refuser l'usage du contenu pour l'entraînement de Gemini. Mais sa documentation précise qu'il « n'a pas de chaîne user-agent HTTP distincte » — doesn't have a separate HTTP request user agent string.⁶ A · Confirmé

Autrement dit : Google-Extended est un token de préférence, pas un robot. Le trafic correspondant arrive dans vos logs sous les user-agents Googlebot habituels, indistinguable du crawl de Search.

Le même problème existe chez les autres, sous une forme atténuée. Anthropic publie une liste d'IP unique pour ses trois agents (ClaudeBot, Claude-User, Claude-SearchBot) : l'IP prouve que la requête vient d'Anthropic, jamais qu'elle relève de l'entraînement plutôt que de la recherche.³² Seul le user-agent le dit — et le user-agent ne prouve rien (section 12).

03Capacité et demande : les deux moitiés du crawl budget

Le terme « crawl budget » n'a jamais désigné une allocation. Il désigne l'intersection de deux grandeurs indépendantes, dont une seule dépend de vous.

La documentation Google en donne la définition en deux temps.¹ A · Confirmé

Deux précisions structurelles, rarement citées et lourdes de conséquences :

1. Le périmètre est le nom d'hôte, pas le domaine. « L'infrastructure de crawl de Google définit un site comme un nom d'hôte unique » : blog.example.com et www.example.com ont des demandes séparées. Mais — et c'est la nuance — « la limite de capacité de crawl est partagée entre tous les crawlers ». Un sous-domaine saturé pénalise donc les autres.

2. Le rendu compte autant que la requête. « Le temps passé à rendre la page compte autant que le temps passé à la demander ».² Une page légère à télécharger mais lourde à rendre consomme autant de capacité qu'une page lourde. C'est le seul endroit de la documentation où le JavaScript entre explicitement dans l'équation du crawl.

04Trois seuils officiels, et ils ne disent pas la même chose

« Suis-je concerné par le crawl budget ? » est la première question à trancher, et Google y a répondu trois fois, de trois manières incompatibles.

Google désamorce partiellement la contradiction dans le guide actuel : « Les chiffres donnés ici sont une estimation grossière destinée à vous aider à classer votre site. Ce ne sont pas des seuils exacts. » Et il ajoute la phrase que la moitié des lecteurs devrait prendre au mot :

Le critère qui vaut mieux que les trois seuils

Les seuils en volume sont des raccourcis. Le critère opérationnel est un délai : combien de temps s'écoule entre la publication d'une page qui compte et son premier crawl ? Si la réponse est « quelques heures », le crawl n'est pas votre problème, quel que soit le nombre de vos URL. Si la réponse est « je ne sais pas », votre premier chantier n'est pas d'optimiser le crawl mais de le mesurer — c'est l'objet de la partie III.

Le troisième critère de Google mérite d'être souligné parce qu'il est le seul qui ne soit pas volumétrique : une proportion importante d'URL en « Découverte, actuellement non indexée ». Ce statut signifie que Google connaît l'URL et a choisi de ne pas aller la chercher. C'est le symptôme le plus direct d'une demande d'exploration insuffisante, et il est lisible gratuitement dans Search Console.

05Le crawl n'est pas un signal de classement

C'est la phrase la plus importante du domaine, et elle vient de Google. Elle invalide à elle seule une bonne partie de ce qui se vend comme « optimisation du crawl budget ».

La formulation n'est pas nouvelle. Gary Illyes écrivait déjà le 16 janvier 2017 : « Un rythme d'exploration accru n'aboutira pas nécessairement à de meilleures positions dans les résultats. »¹¹⁰ Neuf ans plus tard, Google a jugé nécessaire de créer une page entière de démenti — ce qui en dit long sur la persistance du mythe.

Ce que le crawl conditionne réellement

Le crawl est une condition nécessaire et non suffisante. Il conditionne trois choses, et seulement trois :

• L'éligibilité. Une page jamais crawlée ne peut pas être indexée, donc ne peut pas être classée, donc ne peut pas être citée dans un AI Overview. La chaîne est stricte.
• La fraîcheur. Le délai entre une modification et sa prise en compte est exactement le délai de recrawl. C'est le seul endroit où le crawl a un effet business directement mesurable, et il est décisif pour la presse, l'e-commerce à stocks variables et les sites d'annonces.
• La persistance. Une page non indexée et non recrawlée finit par sortir du champ de vision de Google. La meilleure mesure publiée sur ce point vient d'Indexing Insight : sur 1,4 million de pages réparties sur 18 sites, au-delà de 190 jours sans recrawl, une page non indexée a environ 90 % de probabilité de basculer en « URL inconnue de Google ».¹⁰⁸ C · Mesuré

Un ordre de grandeur pour finir de relativiser

Lors du procès antitrust USA v. Google, en octobre 2023, Pandu Nayak, vice-président Search, a indiqué sous serment que l'index web de Google contenait de l'ordre de 400 milliards de documents, tandis que le volume crawlé se compte en milliers de milliards de pages — le chiffre exact ayant été caviardé.¹¹⁴ A · Confirmé

Le rapport entre les deux est le meilleur argument sourcé sur un point simple : crawler n'est pas indexer, et l'essentiel de la sélection se joue après le crawl, pas pendant.

06Qui crawle réellement, en 2026

Avant de décider quoi bloquer, il faut savoir ce qui frappe. Le paysage s'est densifié en trois ans, et il n'est plus lisible sans une taxonomie.

Deux mesures de volumétrie, de sources indépendantes, donnent l'ordre de grandeur.

Vercel × MERJ, décembre 2024 — sur un mois, sur le réseau Vercel (dont nextjs.org et deux sites d'annonces d'emploi) : Googlebot 4,5 milliards de récupérations, GPTBot 569 millions, Claude 370 millions, AppleBot 314 millions, PerplexityBot 24,4 millions. Cumul des crawlers IA ≈ 1,3 milliard, soit environ 28 % du volume de Googlebot.⁴⁵ C · Mesuré

Botify, avril 2026 — sur 7 milliards d'événements de log collectés de novembre 2024 à mars 2026, sur une fenêtre glissante de 30 jours : Google 18,2 milliards d'événements, Bing 5,49 milliards, OpenAI tous bots confondus 887 millions, soit environ un vingtième de Google.¹⁰⁷ C · Mesuré

La liste des agents à connaître

Deux entrées méritent un avertissement. anthropic-ai et Claude-Web ne figurent plus dans la documentation d'Anthropic, mais restent massivement présents dans les robots.txt du web : ce sont des directives héritées, sans effet documenté. Et Bytespider est le point noir du tableau : aucune source primaire ByteDance n'existe, la seule marque d'authenticité couramment citée étant une adresse e-mail dans la chaîne user-agent. Tous les constats de non-respect le concernant sont tiers. D · Hypothèse

07Entraînement, recherche, action : la taxonomie qui manquait

Le mot « robot IA » ne désigne rien d'utile. Il recouvre trois comportements dont les conséquences, les coûts et les leviers de contrôle sont entièrement différents.

Cloudflare a formalisé cette taxonomie le 1^er juillet 2026, et c'est la meilleure disponible :³⁹

La répartition mesurée est très déséquilibrée. Sur la semaine du 1^er au 7 août 2025, Cloudflare mesure que le Training représente près de 80 % du crawl des robots IA, tandis que les catégories « action utilisateur » et « non déclaré » cumulent moins de 5 %.⁴¹ C · Mesuré Une mesure du mois précédent donnait 79 % d'entraînement, 17 % de recherche, 3,2 % d'actions utilisateur.¹⁰⁵

Les régulateurs ont repris cette taxonomie à leur compte. L'Arcep recommande en janvier 2026 « que des crawlers distincts et identifiables soient utilisés pour les visées spécifiques de la collecte (entraînement, recherche en ligne classique, fonctionnalité agentique) ».⁶⁰ Cloudflare formule la même demande à l'adresse des éditeurs d'IA : « si une entreprise fait tourner de l'automatisation qui construit des index de recherche, agit comme agent, et collecte des données pour entraîner ses modèles, nous l'encourageons vivement à séparer cette automatisation en trois crawlers distincts ».³⁹

08Les fetchers déclenchés par l'utilisateur : la catégorie que personne ne gère

C'est le trou dans la raquette, et il est documenté par tous les éditeurs — dans des termes presque identiques.

Google va plus loin en l'inscrivant dans sa spécification du protocole lui-même : « Le REP ne s'applique pas aux crawlers de Google qui sont contrôlés par des utilisateurs (par exemple les abonnements à des flux), ni aux crawlers utilisés pour accroître la sécurité des utilisateurs (par exemple l'analyse de logiciels malveillants) ».³

Sont concernés : ChatGPT-User, Claude-User, Perplexity-User, Google-Agent (mobile et desktop), Google-GeminiNotebook (anciennement Google-NotebookLM), Google-Read-Aloud, Google-Pinpoint, FeedFetcher-Google.

Pourquoi c'est un arbitrage produit, pas un arbitrage SEO

Cette catégorie n'est adressable que par des leviers contraignants — pare-feu, blocage IP, authentification (section 36). Mais la bloquer revient à refuser un visiteur humain au motif qu'il utilise un outil. Un lecteur qui colle votre URL dans ChatGPT pour se la faire résumer déclenche ChatGPT-User ; le bloquer, c'est lui afficher une erreur.

C'est aussi la catégorie qui va croître le plus vite, à mesure que les agents de navigation se généralisent. Elle représente aujourd'hui moins de 5 % du crawl IA mesuré par Cloudflare — elle sera la question centrale de la prochaine étude sur ce sujet. D · Hypothèse

09Ce que les robots IA font vraiment de votre serveur

La meilleure mesure comportementale publiée sur les crawlers IA est l'étude Vercel × MERJ du 17 décembre 2024. Ses résultats devraient changer la façon dont on conçoit un site.

Résultat n°1 : aucun grand crawler IA n'exécute JavaScript

C'est le résultat le plus lourd de conséquences. ChatGPT récupère des fichiers JavaScript dans 11,50 % de ses requêtes, Claude dans 23,84 % — sans jamais les exécuter. Seuls Gemini (qui tourne sur l'infrastructure Google) et AppleBot effectuent un rendu.⁴⁵ C · Mesuré

Résultat n°2 : le gaspillage est massif

Un tiers des requêtes des deux principaux crawlers IA porte sur des URL qui n'existent pas, contre un douzième pour Googlebot. Deux lectures possibles, non exclusives : ces robots travaillent à partir de corpus d'URL périmés, et ils fabriquent des URL par inférence plutôt que par découverte de liens. D · Hypothèse

La conséquence opérationnelle est directe : sur un site frappé par les robots IA, une part importante de la charge est consommée à produire des pages d'erreur. Si votre 404 est une page lourde générée par le CMS avec appels en base, c'est là que part votre CPU. Servir un 404 statique et léger est, dans ce contexte, une optimisation d'infrastructure réelle.

Résultat n°3 : ils ne cherchent pas la même chose

Ces chiffres portent sur un panel restreint et datent de fin 2024. Ils ne sont pas une norme — ils sont un point de comparaison daté, et à ce titre ils valent surtout par leurs écarts : Claude consacre plus d'un tiers de ses récupérations aux images là où ChatGPT se concentre sur le HTML.

10Le coût, mesuré

Le crawl IA n'est pas une nuisance abstraite. C'est une facture, et deux organisations l'ont chiffrée publiquement avec assez de précision pour qu'on puisse raisonner.

Wikimedia : le chiffre le plus cité, et le plus mal cité

Le 1^er avril 2025, la Fondation Wikimedia publie une analyse de l'impact des crawlers sur son infrastructure. La phrase clé, verbatim :⁴⁶

Le mécanisme économique décrit par Wikimedia est le vrai enseignement, et il est généralisable : les crawlers font de la lecture en masse. Ils visitent les pages impopulaires autant que les populaires, et échappent donc structurellement au cache, qui est dimensionné pour les pics d'attention humaine. Leur coût marginal est très supérieur à leur part de volume. Wikimedia mesure aussi +50 % de bande passante multimédia depuis janvier 2024, et résume : « notre contenu est gratuit, notre infrastructure ne l'est pas ».

L'écosystème open source : des témoignages, pas des mesures

Plusieurs projets ont documenté publiquement des dégradations sérieuses en 2025 :⁵⁴⁵⁵⁵⁶

• SourceHut — Drew DeVault : « de 20 à 100 % de mon temps, une semaine donnée, à atténuer des crawlers LLM hyper-agressifs à grande échelle », avec « des dizaines de brèves interruptions par semaine ».
• KDE — GitLab rendu temporairement inaccessible aux développeurs par un crawler opérant depuis des plages IP Alibaba.
• Fedora — blocage de tout le trafic en provenance du Brésil, après échec des mitigations plus fines.
• GNOME — déploiement d'Anubis, un dispositif de preuve de travail imposé avant tout accès.

Certains mainteneurs rapportent jusqu'à 97 % de leur trafic issu de robots d'entreprises d'IA. C'est un chiffre de mainteneur, non audité : nous le citons comme témoignage, pas comme mesure. D · Hypothèse

Le patrimoine culturel connaît le même phénomène : le GLAM-E Lab a enquêté en 2025 sur la mise hors ligne d'institutions patrimoniales par la seule charge de crawl.⁵³

11L'asymétrie entre ce qu'on prend et ce qu'on rend

Le ratio « crawl-to-refer » est devenu l'argument central du débat public. C'est aussi le chiffre le plus maltraité du domaine.

Sa définition, publiée par Cloudflare : le nombre de requêtes d'un user-agent avec un Content-type: text/html, divisé par le nombre de requêtes HTML dont l'en-tête Referer contient un nom d'hôte de la plateforme.¹⁰⁶

Les séries publiées par Cloudflare, sur une cohorte de clients fixe, de janvier à juillet 2025 :¹⁰⁵

Et par verticale, sur la semaine du 1^er au 7 août 2025 : Anthropic affiche 50 000:1 en global mais 2 500:1 sur le secteur « News & Publications » ; OpenAI 887:1 en global, 152:1 sur le même secteur.⁴¹ C · Mesuré

Un dernier indicateur, plus parlant que les ratios parce qu'il porte sur l'aval : TollBit mesure sur ses éditeurs clients un taux de clic depuis les plateformes IA passant de 0,8 % à 0,48 % puis 0,27 % sur les deuxième, troisième et quatrième trimestres 2025.⁴⁸ À prendre avec la réserve qui s'impose : l'échantillon n'est pas publié et les éditeurs concernés sont clients d'un vendeur de solutions de péage pour robots. C · Mesuré

12Le user-agent ne prouve rien

C'est le point de départ obligatoire, et celui que la plupart des analyses sautent. Tant qu'on ne l'a pas traité, on ne mesure pas le crawl : on mesure des déclarations.

Le champ User-Agent est une chaîne de caractères librement choisie par le client HTTP. N'importe quel script peut envoyer Googlebot/2.1 ou ClaudeBot/1.0. Toute métrique construite sur ce seul champ est donc, littéralement, une métrique de ce que les robots disent être.

Google impose pour cette raison une vérification, et la documente en quatre étapes.⁸ A · Confirmé

Cette méthode est le forward-confirmed reverse DNS. Les motifs d'hôtes valides documentés par Google sont crawl-***-***-***-***.googlebot.com, geo-crawl-***-***-***-***.geo.googlebot.com, ***-***-***-***.gae.googleusercontent.com et google-proxy-***-***-***-***.google.com.

En pratique, sur un volume de logs réel, la résolution DNS par requête est trop lente. La méthode opérationnelle est la correspondance d'IP contre les fichiers de plages publiés — que nous traitons en section suivante — avec le DNS en repli pour les opérateurs qui ne publient rien.

13Les fichiers de plages IP, et leurs trois pièges

Les opérateurs sérieux publient leurs plages en CIDR, dans des fichiers JSON. Voici les URL exactes, vérifiées.

Piège n°1 — le fichier que vos scripts référencent n'existe pas

Piège n°2 — la fraîcheur est très inégale, et produit des faux négatifs

Google régénère ses fichiers tous les jours. Le fichier de Bing porte un creationTime de janvier 2024, celui de Perplexity de février 2025. Une correspondance stricte IP↔JSON sur ces deux opérateurs produit donc mécaniquement des « bot non vérifié » sur des requêtes parfaitement légitimes.

Pour Bing, le repli documenté est le reverse DNS vers search.msn.com, plus l'outil public de vérification.⁹⁵ Pour Perplexity, il n'existe pas de repli officiel.

Règle à implémenter : votre pipeline doit lire le champ creationTime de chaque fichier et lever une alerte si un fichier n'a pas bougé depuis un délai que vous fixez. Sans ce contrôle, votre vérification se dégrade silencieusement au fil des mois.

Piège n°3 — ces plages sont du cloud loué

Les préfixes d'Anthropic et de Perplexity résolvent vers GCP, Azure ou AWS, pas vers un système autonome opéré par l'éditeur. La liste est donc une déclaration d'appartenance, pas une preuve réseau indépendante.

Anthropic déconseille d'ailleurs explicitement le blocage par IP, au motif qu'il empêche le robot de lire le robots.txt et donc de respecter vos préférences.³² L'argument est recevable et mérite d'être pesé : bloquer au niveau réseau, c'est renoncer au canal déclaratif.

L'horizon : la vérification cryptographique

Google documente depuis le 4 mai 2026 Web Bot Auth, décrit comme « un protocole cryptographique expérimental utilisé pour authentifier les requêtes envoyées par des bots », permettant aux agents de « signer cryptographiquement leurs requêtes » plutôt que de s'appuyer sur « des en-têtes auto-déclarés et des adresses IP ».⁹ Le mécanisme repose sur HTTP Message Signatures (RFC 9421)²⁶, avec des clés publiques exposées sur agent.bot.goog/.well-known/http-message-signatures-directory et un en-tête Signature-Agent.

Google assortit sa propre documentation de trois réserves : « tous les user-agents Google n'utilisent pas Web Bot Auth », « Google ne signe pas encore chaque requête des agents utilisant le protocole », et la spécification IETF « peut évoluer ». Il faut donc conserver un repli par IP. Cloudflare utilise le même socle pour ses signed agents.⁴³ B · Par proxy

14Ce qu'il faut journaliser

Le Combined Log Format standard, celui que vous avez par défaut, est insuffisant. Il lui manque précisément les deux champs qui permettent d'interpréter le comportement d'un crawler.

Ce qui manque : le temps de réponse — or c'est la grandeur qui pilote la capacité de crawl (section 03) — et le statut de cache, sans lequel un temps de réponse n'est pas interprétable.

Configuration nginx

log_format seo '$remote_addr $time_iso8601 "$request" $status $body_bytes_sent '
               '"$http_referer" "$http_user_agent" '
               'rt=$request_time urt=$upstream_response_time '
               'cache=$upstream_cache_status host=$host scheme=$scheme';

• $request_time — temps total de traitement, résolution milliseconde
• $upstream_response_time — temps applicatif seul, ce qui permet de distinguer une lenteur PHP d'une lenteur réseau
• $upstream_cache_status — HIT / MISS / BYPASS, indispensable pour savoir si le temps de réponse que voit le robot est celui de votre application ou celui de votre cache
• $host — obligatoire dès qu'il y a plusieurs noms d'hôtes, puisque le crawl budget se calcule par nom d'hôte

Une technique Apache qui divise la volumétrie

Isoler le trafic robot dans un fichier dédié dès l'écriture, plutôt que de filtrer après coup :⁸⁹

SetEnvIf User-Agent ".*bot*" seobot
CustomLog "|/usr/sbin/rotatelogs /path/seo.log.%Y-%m-%d 604800" variables env=seobot

Les axes d'agrégation

Croisez systématiquement : jour × bot vérifié × code HTTP × type de fichier × segment d'URL.

La segmentation par gabarit ou par répertoire est ce qui transforme un log en diagnostic. Sans elle, vous comptez ; avec elle, vous localisez. Segmentation minimale recommandée : par structure (produits, catégories, pagination, pages filtrées), par paramètre d'URL, par famille thématique.

15Le piège du CDN : vous ne voyez que ce qu'on vous a laissé voir

C'est le biais le plus grave de l'analyse de logs contemporaine, parce qu'il est invisible et qu'il produit des conclusions inversées.

Un site derrière Cloudflare, Akamai ou Fastly voit ses logs d'origine sous-compter massivement le crawl : le cache de bordure sert une partie des requêtes robot sans jamais toucher l'origine. Pire, les requêtes bloquées ou soumises à un challenge par le pare-feu applicatif n'apparaissent nulle part côté origine.

Sont invisibles côté origine : les requêtes robot bloquées, les challenges JavaScript ou CAPTCHA échoués, les requêtes servies depuis le cache de bordure, et les requêtes soumises à limitation de débit.

La contrainte commerciale qu'il faut connaître avant de promettre une analyse

Les logs bruts de Cloudflare — Logpush, Logpull, Log Explorer — sont réservés aux offres payantes de haut de gamme. Les offres Free et Pro n'exposent pas les logs de requêtes bruts. Le repli praticable sur les petits plans est le tableau Security Events, pour vérifier qu'aucun robot légitime n'est bloqué, croisé avec les analytics GraphQL et les logs d'origine.

16Rotation, rétention, RGPD

Trois contraintes matérielles qui déterminent ce que vous pourrez mesurer — et qu'il faut traiter avant de commencer.

La rotation. Les logs sont compressés et archivés. Toute analyse historique doit donc lire les archives : zcat access.log.*.gz | …. C'est trivial, mais c'est la première chose qu'on oublie, et l'oubli produit une fenêtre d'analyse silencieusement tronquée.

La rétention. La valeur par défaut de beaucoup d'hébergements mutualisés se compte en jours ou en quelques semaines. C'est insuffisant pour mesurer une fréquence de recrawl mensuelle, et très insuffisant pour mesurer un délai publication → crawl sur des pages peu visitées. Le premier acte du protocole n'est donc pas d'analyser : c'est d'allonger la rétention et de commencer à archiver. Une analyse de crawl sérieuse se prépare plusieurs semaines à l'avance.

Le cadre légal. Les logs contiennent des adresses IP : ce sont des données personnelles au sens du RGPD. La CNIL recommande pour les journaux techniques une conservation de l'ordre de six mois à un an, glissante, sauf justification particulière.⁹¹ Un archivage à des fins d'analyse SEO doit être inscrit au registre des traitements, avec une durée justifiée.

17Le rapport d'exploration de Search Console : complément, jamais substitut

Gratuit, sans accès serveur, et porteur d'une information que vos logs ne contiendront jamais. Mais avec cinq limites dures qu'il faut énoncer avant de s'en servir.

Ce qu'il apporte

Trois métriques agrégées — total des requêtes d'exploration, taille totale de téléchargement, temps de réponse moyen — et quatre ventilations : par code de réponse, par type de fichier, par objectif (Discovery vs Refresh) et par type de Googlebot.¹⁸ S'y ajoute l'état de l'hôte : récupérabilité du robots.txt, résolution DNS, connectivité serveur, avec un code couleur vert / jaune (problèmes il y a plus d'une semaine) / rouge (problèmes dans les sept derniers jours).

Ses cinq limites

Une lacune que nous signalons plutôt que de la combler

Nous n'avons trouvé aucune étude publique, chiffrée et méthodologiquement sérieuse comparant les statistiques d'exploration de Search Console aux logs réels d'un même site sur une même fenêtre. Ce qui existe est qualitatif : Botify publie un diagramme de recouvrement crawlé-par-l'outil / par-les-deux / par-Google-seul, et documente que l'analyse de logs révèle des listes d'erreurs dépassant très largement le plafond d'affichage de GSC.⁸²

C'est une lacune de la littérature, et c'est aussi une opportunité : produire cette comparaison sur un site réel, en publiant le protocole, serait un apport net. Nous l'inscrivons au journal des versions comme chantier pour une révision ultérieure de cette étude.

18Les outils, honnêtement

Panorama sans complaisance, avec les limites de chacun. Les comparatifs qui remontent en tête des résultats de recherche sont, pour l'essentiel, des pages d'affiliation : leurs tarifs et leurs statuts produits ne doivent pas être repris sans vérification chez l'éditeur.

19Les métriques qui comptent

Compter les requêtes ne sert à rien. Voici les grandeurs qui permettent de conclure, et la critique de la plus intéressante d'entre elles.

La crawl efficacy de Jes Scholz, et ses limites

Jes Scholz défend une thèse forte : le crawl budget est une métrique de vanité. Une hausse ou une baisse du volume total de crawl ne corrèle pas en soi avec la performance, et augmenter le crawl total est sans intérêt s'il porte sur des URL sans valeur ou des pages inchangées.⁷⁴

Elle propose à la place la crawl efficacy : le délai entre la création ou la mise à jour d'une page pertinente et son crawl suivant par Googlebot. L'objectif est de minimiser cette fenêtre.

Deux méthodes de mesure : la primaire, différence entre l'horodatage created ou updated en base de données et l'horodatage du crawl suivant dans les logs ; et un proxy, comparaison du lastmod du sitemap avec la date de crawl remontée par l'API URL Inspection de Search Console — plafonnée à 2 000 requêtes par jour.

Une grille de décision

20Le cache conditionnel : le levier le plus efficace et le moins déployé

Un seul chiffre résume l'état du web sur ce point, et il est publié par Google.

Moins de deux requêtes sur dix mille peuvent être servies sans régénérer la page. C'est le constat le plus accablant du domaine, et il désigne directement le levier.

Ce que Google supporte, exactement

« L'infrastructure de crawl de Google supporte le cache HTTP heuristique tel que défini par le standard de cache HTTP, spécifiquement à travers l'en-tête de réponse ETag et l'en-tête de requête If-None-Match, ainsi que l'en-tête de réponse Last-Modified et l'en-tête de requête If-Modified-Since. »²⁰

Et la recommandation d'arbitrage, verbatim : « Nous recommandons vivement d'utiliser ETag parce qu'il est moins sujet aux erreurs (sa valeur n'est pas structurée, contrairement à celle de Last-Modified). Et, si vous en avez la possibilité, définissez les deux. »

Pourquoi le 304 est le meilleur rapport effort/gain du domaine

Une réponse 304 Not Modified est sans corps HTTP. Google l'explicite : votre serveur « n'a pas à dépenser de ressources de calcul pour générer réellement le contenu » et « n'a pas à transférer le corps HTTP ». Vous économisez donc deux fois : la génération et le transfert.

Côté crawl, la documentation ajoute : « Si une page n'a pas changé depuis la dernière exploration de Google, renvoyer un code 304 dit à Google de réutiliser la version en cache, économisant la bande passante et les ressources de votre serveur », et « les crawlers de Google signalent au système de traitement suivant que le contenu est le même que lors du dernier crawl ».⁵

Dernière précision, sur la granularité de l'invalidation : « Notre recommandation est d'exiger un rafraîchissement du cache lors de changements significatifs de votre contenu ; si vous n'avez mis à jour que la date de copyright en bas de page, ce n'est probablement pas significatif. » Autrement dit, un ETag calculé sur un hash de la page entière — date du jour comprise — n'invalide jamais rien d'utile et vous ramène au point de départ.

21Ralentir Googlebot : des codes HTTP, pas un fichier

La méthode officielle tient en une phrase : « renvoyez un code de statut HTTP 500, 503 ou 429 au lieu de 200 aux requêtes d'exploration ».⁴ A · Confirmé

Assortie d'un avertissement que personne ne cite :

C'est donc un frein d'urgence, pas un réglage. Pour une réduction durable, la seule voie est le formulaire de signalement Googlebot, dont Google indique que l'évaluation « peut prendre plusieurs jours ».

Ce qui ne marche pas

La sémantique complète des codes, côté crawl

22Les 2 Mo, et le web qui grossit

Il existe une limite dure, chiffrée, et elle est plus basse que la page médiane du web.

Gary Illyes, mars 2026 : « Googlebot récupère actuellement jusqu'à 2 Mo pour chaque URL individuelle (hors PDF)… Pour les fichiers PDF, la limite est de 64 Mo… Pour tout autre crawler qui ne spécifie pas de limite, la valeur par défaut est de 15 Mo. »¹⁰³ A · Confirmé

Au-delà de la limite, les octets ne sont pas tronqués « approximativement » : ils n'existent pas. Chaque ressource liée dispose de son propre compteur de 2 Mo.

À rapprocher de l'évolution du poids des pages : la page mobile médiane est passée d'environ 816 Ko à 2,3 Mo, répartis sur plus de 60 fichiers, en dix ans.⁵² C · Mesuré La médiane du web se rapproche donc de la limite de récupération de Googlebot, alors que la part cacheable s'effondre.

Une mise en perspective utile. Semrush, sur un tirage aléatoire de 150 000 sites, mesure que 1 % seulement des pages dépassent 2 Mo, et que 7 % seulement des sites présentent des chaînes ou des boucles de redirection.¹¹² C · Mesuré Ces deux sujets occupent une place éditoriale sans commune mesure avec leur prévalence réelle. À garder en tête avant d'en faire des priorités d'audit.

23Sitemaps, lastmod, IndexNow

Le ping des sitemaps est mort, et Google a expliqué pourquoi

L'endpoint a cessé de fonctionner six mois plus tard et renvoie désormais un 404. La soumission reste possible par robots.txt et par Search Console. Resoumettre manuellement son sitemap tous les jours n'a jamais été documenté comme produisant un gain de crawl, et le canal automatisé qui le permettait n'existe plus.

Ce que Google dit utile : lastmod, et seulement lui

Trois citations du même billet, qui définissent exactement le contrat :

• « Aujourd'hui lastmod est effectivement utile dans de nombreux cas et nous l'utilisons comme signal pour planifier les crawls des URL que nous avons déjà découvertes. »
• « Il doit correspondre à la réalité de façon constante : si votre page a changé il y a sept ans mais que vous nous dites dans l'élément lastmod qu'elle a changé hier, à un moment nous ne vous croirons plus. »
• « Quand nous disons "dernière modification", nous voulons dire "dernière modification significative". »

Et, sans ambiguïté : « Google n'utilise toujours pas du tout les éléments changefreq ou priority. »

IndexNow : ce qu'on peut dire, et ce qu'on ne peut pas

Google n'a jamais publié de position officielle sur IndexNow. Ni support, ni refus. Cette absence est en soi l'information : toute affirmation sur « ce que Google fait des pings IndexNow » est une spéculation.

Bing, en revanche, publie des chiffres traçables sur la part des nouvelles URL cliquées provenant d'IndexNow : 7 % en août 2022, 12 % en septembre 2023, 18 % en décembre 2024.⁹⁶ C · Mesuré Le chiffre de « 22 % en décembre 2025 » qui circule n'a pas été retrouvé sur le blog officiel de Bing ; nous ne le reprenons pas.

24Facettes et paramètres : là où se joue réellement le sujet

Si le crawl est un problème sur votre site, il y a trois chances sur quatre que ce soit ici. Le chiffre vient de Google.

Google explique pourquoi : « explorer des URL à facettes tend à coûter aux sites de grandes quantités de ressources de calcul, du fait du volume considérable d'URL et d'opérations nécessaires pour rendre ces pages », et souvent « il n'y a aucune bonne raison d'autoriser l'exploration des éléments filtrés ».¹⁰

Les cinq stratégies, avec leurs contreparties

Les règles d'hygiène quand on laisse explorer

• Utilisez & comme séparateur. La virgule, le point-virgule et les crochets sont « difficiles à détecter comme séparateurs de paramètres par les crawlers ».
• Renvoyez un 404 quand une combinaison de filtres ne donne aucun résultat, plutôt que de rediriger vers une page d'erreur générique.
• Ordre de filtres logique et constant, sans doublon de filtre dans l'URL. Deux ordres différents pour le même jeu de filtres, c'est deux URL pour une page.

L'outil de paramètres d'URL est mort depuis avril 2022

Annonce du 28 mars 2022, avec sa justification chiffrée : « Au fil des ans, Google est devenu bien meilleur pour deviner quels paramètres sont utiles sur un site et lesquels sont — pour le dire simplement — inutiles. De fait, seulement 1 % environ des configurations de paramètres actuellement spécifiées dans l'outil sont utiles pour l'exploration. »²²

Le remplacement officiel : « désormais vous n'avez rien à faire pour spécifier la fonction des paramètres d'URL sur votre site, les crawlers de Google apprendront automatiquement comment les traiter. » Toute méthodologie qui recommande encore de « configurer les paramètres dans la Search Console » est périmée depuis plus de quatre ans.

25Vitesse et protocoles : ce qui est documenté, et ce qui ne l'est pas

Ce que Google documente réellement sur la vitesse tient en une phrase, déjà citée en section 03 : « si le site répond de façon constante et que ses temps de réponse (latence et TTFB compris) restent stables ou s'améliorent, la limite monte ».

Ce que Google ne documente pas, et qu'il faut cesser d'affirmer :

26Les mythes que Google a lui-même corrigés

Le 18 décembre 2025, Google a publié une page intitulée Myths and facts about crawling. C'est la source la plus dense du domaine, et elle est très peu citée en français. Voici son contenu, mythe par mythe.² A · Confirmé

Deux enseignements de méthode. D'abord, Google a jugé nécessaire de créer une page entière de démenti : c'est le signe d'un domaine où la doctrine du marché a durablement divergé de la documentation. Ensuite, la catégorie « en partie vrai » est la plus intéressante — c'est là que se logent les demi-vérités qui se transmettent le mieux, parce qu'elles reposent sur un fond exact.

27Crawl-delay : le levier fantôme

Aucune norme n'a jamais défini Crawl-delay. Le RFC 9309, qui standardise enfin le protocole d'exclusion des robots en septembre 2022 — vingt-huit ans après sa création par Martijn Koster — ne le mentionne pas.²⁵ Il se contente d'autoriser les champs hors protocole sans les définir : « les crawlers PEUVENT interpréter d'autres enregistrements qui ne font pas partie du protocole robots.txt — par exemple, "Sitemaps" ».

Il n'existe donc aucune norme du délai entre requêtes. Ce que chacun en fait :

28Disallow + noindex : une contradiction, pas une ceinture-bretelles

C'est l'erreur de conception la plus fréquente, et elle vient d'une intuition parfaitement raisonnable : « je bloque, et en plus je désindexe, comme ça je suis sûr ». C'est l'inverse qui se produit.

Le mécanisme est trivial une fois énoncé : noindex est une instruction dans la page. Pour la lire, il faut télécharger la page. Si vous interdisez le téléchargement, l'instruction n'est jamais lue.

Et une page bloquée par robots.txt peut parfaitement être indexée : « Une page interdite dans robots.txt peut quand même être indexée si d'autres sites y font un lien ».¹⁴ Google indexe alors l'URL nue, sans extrait.

La séquence correcte

Les deux objectifs sont antagonistes et se traitent en séquence, jamais simultanément :

1. Pour désindexer : laisser crawler, servir un noindex, attendre la désindexation effective.
2. Ensuite seulement, si l'objectif est d'économiser du crawl : ajouter le Disallow.

Google le rappelle d'ailleurs dans la documentation du crawl budget : bloquer les URL sans intérêt « via robots.txt (pas noindex) ».¹

Et la nuance sur le coût du noindex

Deux formulations coexistent chez Google, et la seconde est plus juste que la première.

Doc crawl budget : « N'utilisez pas noindex, car Google demandera quand même la page, puis l'abandonnera en voyant la balise ou l'en-tête, gaspillant du temps d'exploration. »

Page des mythes, plus complète : « En partie vrai. Toute URL explorée affecte le crawl budget, et Google doit explorer la page pour trouver la règle noindex. Cependant… si vous retirez des URL de l'index de Google avec noindex ou autrement, les crawlers de Google peuvent se concentrer sur d'autres URL de votre site, ce qui signifie que noindex peut indirectement libérer du crawl budget à long terme. »²

29« Nettoyer ses 404 libère du budget » — et les autres réallocations imaginaires

Il existe une phrase dans la documentation de Google qui invalide, à elle seule, une famille entière de prestations vendues sous le nom d'optimisation de crawl budget.

La réallocation n'existe donc que si votre site plafonne déjà sur sa capacité. En dessous du plafond, bloquer ou supprimer ne libère rien — parce que rien n'était contraint. Or la très grande majorité des sites sont en dessous du plafond (section 04).

Un contrepoint académique que le marché ignore complètement

L'intuition la plus solide du domaine — « recrawler plus souvent ce qui change plus souvent » — est fausse, et c'est démontré depuis 2003.

Cho et Garcia-Molina, dans Effective Page Refresh Policies for Web Crawlers (ACM TODS, 2003), comparent trois politiques d'ordonnancement sur 720 000 pages issues de 270 sites populaires, crawlées quotidiennement du 17 février au 24 juin 1999 :⁹⁷ C · Mesuré

La politique intuitive est soixante-dix fois pire qu'un recrawl uniforme. L'optimum pondère fréquence de changement et importance, et pénalise les pages qui changent trop vite — parce qu'elles seront de toute façon périmées avant le crawl suivant.

30Les conseils morts, et les chiffres qu'il faut cesser de citer

Onze recommandations périmées encore en circulation

1. « Configurer les paramètres d'URL dans la Search Console » — outil hors service depuis fin avril 2022.²²
2. « Mettre un Crawl-delay pour Google » — non traité.²
3. « Utiliser le limiteur de taux de crawl de la Search Console » — retiré.
4. « Disallow + noindex pour être sûr » — mutuellement exclusifs (section 28).
5. « Ajouter noarchive dans la meta robots » — Google le documente comme no longer used, avec nocache et nositelinkssearchbox.¹⁶
6. « Bloquer Google-Extended pour sortir des AI Overviews » — voir section 32, où la question est plus intéressante qu'il n'y paraît.
7. « Bloquer GPTBot pour ne pas apparaître dans ChatGPT » — sans effet sur ChatGPT Search (section 33).
8. « Renvoyer 403 ou 401 pour ralentir Googlebot » — aucun effet.³
9. « Bloquer CCBot pour retirer son contenu des corpus » — effet strictement prospectif ; les archives Common Crawl déjà constituées restent.
10. « Pinguer ses sitemaps » — endpoint supprimé (section 23).
11. « Se référer au billet facettes de 2014 » — remplacé par la documentation de décembre 2025.

Quatorze chiffres non traçables

Nous les listons parce que les rencontrer dans un audit devrait déclencher une vérification, pas une reprise.

31Crawl, indexation, affichage : trois étages, trois leviers

La confusion la plus coûteuse du domaine tient à ce que trois questions distinctes sont traitées comme une seule.

Les règles d'affichage, et pourquoi ce sont les vrais leviers IA

Google documente une dizaine de règles applicables en balise meta robots ou en en-tête X-Robots-Tag.¹⁶ Les plus utiles ici :

• nosnippet — « Ne pas afficher d'extrait textuel ni d'aperçu vidéo dans les résultats de recherche pour cette page. »
• max-snippet:[nombre] — plafonne la longueur de l'extrait.
• data-nosnippet — attribut booléen sur span, div et section, pour exclure des portions de texte de l'extrait. C'est le levier le plus fin du lot.
• indexifembedded — autorise l'indexation d'un contenu intégré en iframe malgré un noindex.
• X-Robots-Tag — le seul moyen d'appliquer ces règles à un PDF, une image, une vidéo ou un CSV, où l'on ne peut pas insérer de balise.

Retenez ce point, il commande toute la section suivante : ces règles d'affichage sont exactement celles qui gouvernent les AI Overviews et l'AI Mode.

32Google-Extended et les AI Overviews : la contradiction

C'est le point le plus intéressant de cette étude, parce que c'est le seul où une mesure indépendante et évaluée par les pairs contredit frontalement une affirmation officielle de Google — et où le désaccord n'est pas résolu.

Ce que Google affirme

Trois affirmations officielles, cohérentes entre elles :

La lecture technique qui en découle est nette. Les AI Overviews et l'AI Mode sont des surfaces de Search, alimentées par le crawl Googlebot et gouvernées par l'éligibilité au snippet. Pour figurer comme lien de soutien dans un AI Overview, « une page doit être indexée et éligible à être affichée dans Google Search avec un extrait. Il n'y a aucune exigence technique supplémentaire. » Google-Extended, lui, ne pilote que l'entraînement de Gemini et l'usage via Vertex AI.

Conclusion attendue : bloquer Google-Extended pour sortir des AI Overviews est un non-sens technique. Les seuls leviers qui agissent sont noindex, nosnippet, max-snippet, data-nosnippet — ou Disallow sur Googlebot, ce qui revient à quitter Google entièrement.

Ce qu'une étude évaluée par les pairs a mesuré

Sauf qu'une étude acceptée à SIGIR '26, la 49^e conférence ACM SIGIR, mesure autre chose.⁹⁹ C · Mesuré

Méthode : 14 212 requêtes au total, dont 11 500 requêtes stables issues d'un benchmark publié (requêtes réelles ORCAS, Amazon Retail, sujets de débat, Reddit ELI5, requêtes localisées, Natural Questions). Collecte les 7 et 8 décembre 2025. Modèle de probabilité linéaire avec effets fixes par requête et erreurs types clusterisées, régressant « la source est-elle citée » sur les interactions moteur × caractéristiques du site, dont le blocage de Google-Extended. Données et code publiés.

Les 21 éditeurs concernés incluent le New York Times, ESPN, CNN, la BBC, NPR et Reuters, ainsi que Facebook, Instagram, TikTok, IMDb, Yelp et Tripadvisor.

Applebot-Extended présente la même architecture, sans le désaccord : « Applebot-Extended n'explore pas les pages web. Les pages web qui interdisent Applebot-Extended peuvent toujours être incluses dans les résultats de recherche » — Spotlight et Siri.³⁴ C'est un token de préférence, pas un agent.

33Bloquer GPTBot ne vous sort pas de ChatGPT

Ici, aucune ambiguïté : c'est OpenAI qui le dit.

Il faut compter environ 24 heures entre une mise à jour du robots.txt et sa prise en compte par les systèmes de recherche d'OpenAI.

Les deux erreurs symétriques

Le même découpage existe partout :

34Le piège du bloc nommé : la première cause de robots.txt cassés

Deux règles de parsing, documentées par Google, expliquent la majorité des robots.txt qui ne font pas ce que croit leur auteur.

Règle 1 — un bloc nommé n'hérite de rien

Déclarer un bloc User-agent: GPTBot fait perdre à GPTBot toutes les règles du bloc *. Si votre bloc générique interdisait /wp-admin/, /panier/ et /recherche/, GPTBot y a désormais accès — parce que vous avez voulu le restreindre.

C'est contre-intuitif et c'est la première cause de robots.txt IA défaillants. La conséquence pratique : chaque bloc nommé doit répéter intégralement les règles du bloc générique, plus les siennes.

Règle 2 — une ligne Sitemap: au milieu ne coupe pas un groupe

« Les règles autres que allow, disallow et user-agent sont ignorées par le parser robots.txt. » Google donne l'exemple :

user-agent: a
sitemap: https://example.com/sitemap.xml
user-agent: b
disallow: /

« est traité comme un seul groupe, et donc les user-agents a et b sont tous deux affectés par la règle disallow: / ». La ligne Sitemap: ne coupe pas le groupe — elle est simplement ignorée, et les deux blocs fusionnent.

Conséquence opérationnelle : placez toujours vos lignes Sitemap: en fin de fichier, jamais entre deux groupes.

Les autres règles de parsing qui comptent

Le comportement sur erreur : Google diverge du RFC

35La syntaxe exacte, pour l'objectif le plus courant

Objectif : refuser l'entraînement, rester citable. C'est ce que veulent la plupart des sites qui nous posent la question, même quand ils la formulent autrement.

# Refus d'entraînement
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

# Recherche et citation : explicitement autorisés
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# Sitemap en fin de fichier, jamais entre deux groupes
Sitemap: https://example.com/sitemap.xml

Trois rappels avant de copier ce bloc :

• Chaque bloc nommé est autonome (section 34). Si votre bloc * contient des Disallow importants, répétez-les dans chaque bloc nommé.
• Ne mettez pas Googlebot dans la liste de gauche. C'est la seule ligne qui vous ferait sortir de Search.
• La colonne de droite n'est pas décorative. Sans Allow: / explicite, ces agents retomberaient sur le bloc * — ce qui est souvent le comportement voulu, mais qu'il vaut mieux écrire que subir.

La prévalence réelle du blocage

Les trois pourcentages de la première ligne mesurent trois choses différentes — part des tokens, part des sources critiques, part sous restriction contractuelle. Leur confusion est l'erreur de citation la plus fréquente sur ce sujet.

36Les leviers contraignants, et leurs faux positifs

Le robots.txt est déclaratif par construction. Si vous voulez une contrainte, il faut descendre d'une couche — et accepter le risque associé.

Les quatre leviers, du plus sûr au plus risqué

Rappel de la section 15 : ces blocages sont invisibles dans vos logs d'origine. Si vous êtes derrière un CDN, la seule façon de vérifier que vous ne bloquez pas Googlebot est de consulter le tableau des événements de sécurité, pas vos logs serveur.

37Le réglage Cloudflare qui bloque Googlebot

Un point de configuration à vérifier avant le 15 septembre 2026 sur tout site derrière Cloudflare. Il est documenté, il est daté, et il est passé largement inaperçu.

La chronologie

Ce qui change le 15 septembre 2026

« Pour tous les nouveaux domaines qui rejoignent Cloudflare, les catégories Training et Agent seront bloquées par défaut sur les pages qui affichent de la publicité, tandis que Search restera autorisé par défaut. »

Et voici la phrase qui devrait figurer en gras dans toute documentation d'exploitation :

Le reste du dispositif, en bref

• Content Signals. Une ligne machine — Content-Signal: search=yes, ai-train=no — et un bloc de commentaires en langage naturel. Servie sur plus de 3,8 millions de domaines via le robots.txt managé. Cloudflare précise ne pas servir de signal ai-input par défaut : « nous ne connaissons pas leur préférence, et nous ne voulons pas deviner ».
• L'extension use, testée depuis juillet 2026, avec trois niveaux : use=immediate (« interagir, mais ne rien stocker ni réutiliser »), use=reference (défaut — « indexer, extraire, et faire un lien retour »), use=full (« résumer et reproduire »).
• Une sanction, cette fois. « Quand nous découvrons un bot abusant de ces signaux, il perdra son statut "Verified", ce qui aura pour conséquence qu'il ne sera plus autorisé. » Et la redéfinition qui compte : « les bots non vérifiés sont toujours bloqués par défaut, mais nous ne considérons plus que Verified signifie "autorisé par défaut" ».
• Pay Per Use, annoncé le 1^er juillet 2026 : le modèle passe d'une facturation par récupération à une rémunération sur l'usage effectif du contenu dans les réponses IA.⁴⁰

C'est le seul dispositif de tout ce panorama qui soit réellement contraignant : Cloudflare est dans le chemin réseau, son blocage s'applique que le crawler soit d'accord ou non. Et c'est aussi celui dont aucune étude d'impact n'a été publiée — nous le signalons comme une lacune, pas comme une omission.

38La seule mesure causale disponible

Une seule étude isole causalement l'effet du blocage sur le trafic. Elle est peu citée, son chiffre le plus connu est périmé, et son résultat est l'inverse de ce que suggère le discours ambiant.

Hangcheng Zhao (Rutgers Business School) et Ron Berman (Wharton), Strategic Response of News Publishers to Generative AI, arXiv:2512.24968, version 4 du 15 avril 2026.⁴⁷ C · Mesuré

La méthode

Différences-en-différences échelonnées sur la date d'adoption du blocage, avec cohortes de comparaison « pas encore bloquantes » et « jamais bloquantes ». Sources : SimilarWeb pour les visites quotidiennes, Semrush pour le canal, le panel comportemental Comscore pour le trafic humain, HTTP Archive pour les instantanés de robots.txt, l'Internet Archive pour les comptes d'URL, Revelio Labs pour les offres d'emploi. Cœur de l'échantillon : 30 éditeurs de presse à couverture complète, avec extensions sur le top 500.

Point d'identification décisif : l'analyse est restreinte à la période antérieure à mai 2024, parce que « l'adoption du blocage s'est concentrée du milieu à la fin de 2023, bien avant l'impact des AI Overviews ». C'est ce qui rend l'estimation propre — et c'est aussi sa principale limite de portée.

Prévalence mesurée : « environ 75 % des principaux éditeurs ont bloqué les crawlers LLM à différents moments à partir du milieu de 2023 », OpenAI d'abord, puis Anthropic, puis Perplexity.