13% des sites audités bloquent un robot IA — Corriger notre propre 40.8%

Mis à jour August 31, 2026. La version de cet article publiée le 20 août mettait en avant « 20 des 49 sites que nous avons audités — 40.8%. « Ce chiffre était erroné deux fois. 40.8% était la part des exécutions d'audit individuelles qui échouaient le contrôle, pas la part des sites distincts, et le multiplier sur un nombre de sites produisait un « 20 sites » que personne n'avait jamais compté. Pire, lorsque nous sommes retournés et avons relu chaque robots. txt dans l'échantillon contre la spécification, 2 défauts dans notre propre analyseur se sont avérés être la cause de la moitié des échecs. Les chiffres corrigés sont ci‑dessous, et la correction est maintenant la partie la plus utile de cet article. Chaque audit que nous effectuons récupère robots.txt et le lit comme le ferait un robot IA. Sur August 31, 2026 nous avons refait le téléchargement du fichier depuis tous les 48 domaines distincts audités dans notre fenêtre moteur actuelle, et 45 d'entre eux ont servi un. Parmi ces 45, 6 sites — 13.3% — ont fermé au moins 1 robot IA majeur hors du site entier. À l'opposé, 8 sites n'ont aucune règle qui s'applique aux robots IA — même pas une directive générique pour qu'ils obéissent. C'est 17.8% de l'échantillon. Cela laisse 31 sites — 68.9% de l'échantillon — avec un robots.txt qui indique une politique qu'un robot IA lira réellement et ne bloque aucun d'entre eux sur tout le site. En une année où ChatGPT recherche, Perplexity et Claude citent des sources en les récupérant, le fichier que la plupart des propriétaires n'ont pas ouvert depuis le lancement est devenu discrètement un interrupteur de visibilité. Moins de gens l'ont désactivé que ce que nous avons d'abord rapporté. Plus d'entre eux ne l'ont jamais touché.

Méthodologie. La population est constituée de chaque domaine distinct ayant un audit complet dans notre fenêtre d'analyse actuelle, qui s'étend de mai 23 à August 31, 2026. Il s'agit de 48 domaines sur 228 exécutions de rapport. Les verdicts stockés portent la réponse du parseur défectueux, donc le tableau ci-dessus n'est pas le total enregistré. C'est une re-récupération le même jour des robots en direct de ces domaines. Fichiers txt, lus en août 31 et évalués avec le parseur corrigé. 3 des 48 ne servent plus de robots. txt du tout, c'est pourquoi le dénominateur est 45. L'échantillon est auto-sélectionné — ce sont des sites que quelqu'un a choisi de faire auditer — et il penche vers les petites à moyennes tailles. Considérez les taux comme indicatifs pour la longue traîne du web plutôt que pour le web en général. Les domaines ne sont pas nommés.

Ce que notre parseur a mal compris, et comment nous l'avons trouvé

La vérification elle-même est simple. Notre moteur analyse chaque groupe robots.txt et évalue 6 agents utilisateurs contre celui-ci : GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Claude-SearchBot, et CCBot. Un crawler est compté comme bloqué uniquement lorsque le groupe qui le gouverne porte un Disallow: / global. Les interdictions partielles comme Disallow: /admin s'enregistrent comme une politique déclarée, ce qui est sain, et ils passent. Appliquer correctement cette définition est là où nous avons échoué. Relire tous les fichiers 45 a révélé 2 défauts distincts, tirant dans des directions opposées. Un Disallow: vide n'est pas un blocage. RFC 9309 indique explicitement qu'une règle sans chemin est ignorée, ce qui rend Disallow: la façon canonique de dire autoriser tout. Yoast émet exactement ce fichier par défaut, et ainsi plusieurs hébergeurs partagés. Notre analyseur a traité la valeur vide comme équivalente à / et a signalé les 6 crawlers comme bloqués. 5 des sites 10 que le moteur avait signalés fonctionnaient avec un fichier autorisant tout : 3 d'entre eux le blocage par défaut de Yoast, 1 d'entre eux un fichier à ligne 2 simple. Un groupe nommé remplace le joker. RFC 9309 indique également qu'un crawler obéit au groupe le plus spécifique qui le nomme et ignore User-agent: * entièrement lorsqu'un tel groupe existe. Notre analyseur a lu chaque groupe correspondant dans l'ordre du fichier et a laissé le dernier l'emporter. Cela fonctionne dans les deux sens. Une grande plateforme sociale dans l'exemple nomme GPTBot, ClaudeBot, et PerplexityBot avec des règles de chemin étroites puis ferme le fichier avec un joker global User-agent: * / Disallow: / — notre analyseur a donné à ces 3 crawlers nommés le joker global dont ils étaient exemptés. Et le site 1 a été mal compté dans l'autre sens : il interdit 3 crawlers IA par nom près du haut de son fichier, puis indique des règles joker plus souples plus bas, et notre analyseur a laissé le joker effacer un blocage réel et délibéré. Ce site avait été en train de passer. Les deux défauts sont maintenant corrigés, avec des tests unitaires construits à partir des fichiers exacts qui les ont exposés. L'effet net sur cet exemple : 5 sites que l'ancien analyseur appelait bloqués ne le sont pas, et 1 site qu'il appelait propre est. Les 3 chiffres côte à côte, tous issus de la même fenêtre : les verdicts stockés du moteur lisent 42.9% de 226 exécutions d'audit individuelles et 21.3% de 47 sites ; relecture des fichiers en direct avec l'analyseur corrigé donne 13.3% de 45 sites. Seul le dernier est une affirmation sur les sites, mesurée avec un analyseur qui lit correctement la spécification. Une propriété du contrôle survit à tout cela : il reste toujours conservateur. Un défi WAF, une règle bot CDN, ou un blocage de pare-feu n'apparaît jamais dans robots.txt, donc 13,3 % reste un plancher sur le nombre de sites qui repoussent réellement ces crawlers. Et un site peut toujours bloquer un crawler sans jamais taper son nom — un joker global disallow écrit pour un environnement de prévisualisation s'applique à GPTBot exactement comme il s'applique à tout le reste. 2 des 6 bloqueurs confirmés atteignent au moins 1 crawler de cette façon : un hôte de prévisualisation dont tout robots.txt est un blocage global à ligne 3, et une grande plateforme dont le joker global final balaie les 3 crawlers qu'il n'a pas nommés.

Une règle écrite en 2023 répond à la mauvaise question dans 2026

Notre taux corrigé se situe désormais en dessous de ce que rapportent les plus grands échantillons externes. Une analyse de mars 2026 de 10 000 sites par SEO Score Tools a trouvé que 18,7 % bloquent activement GPTBot et que 41,3 % ne disposent d'aucune règle robots spécifique à l'IA. Les deux de leurs chiffres dépassent les nôtres — les définitions diffèrent entre les échantillons, notre échantillon est une fraction de la taille, et notre contrôle compte un groupe joker comme une politique appliquée alors que le leur cherche des groupes nommés. Nous ne prétendons pas que notre 13.3% renverse leur 18.7% ; un échantillon de site 45 ne peut pas. Ce que les deux ensembles de données confirment est la forme : une minorité du web a pris une décision d'accès IA, une tranche supplémentaire en a pris une sans le savoir, et le reste n'a pas été interrogé. La partie non considérée est l'histoire, et nos données corrigées sont prudentes quant à la partie concernée. Les blocs 6 que nous avons confirmés sont majoritairement délibérés — 4 nomment le crawler, et 2 d'entre eux exécutent la liste des signaux de contenu gérés de Cloudflare, qui est une politique écrite cette année et non un vestige. Ce que nous ne pouvons pas montrer depuis les sites 45 est la part du web plus large qui conserve encore une règle obsolète ; c’est ce que les échantillons externes ci‑dessus illustrent. Le mécanisme vaut la peine d’être énoncé de toute façon, car c’est ce qui rend une règle obsolète coûteuse. Dans 2023, lorsque GPTBot est apparu pour la première fois dans les journaux serveur et que CCBot est devenu nouvellement notoire comme source d’entraînement, la seule conséquence connue de l’accès était l’entraînement du modèle — ainsi les listes de blocage de bots circulaient, les plugins livraient des bascules 1-click, et les fichiers robots.txt héritaient des interdictions que personne n’a re‑lues depuis. La question que ces règles répondaient était « veux‑je que mon contenu figure dans un corpus d’entraînement ? » La question qui compte dans 2026 est différente : « veux‑je être trouvable et citée lorsqu’un assistant répond sur mon sujet ? » Une règle écrite pour la première question répond maintenant silencieusement à la seconde.

Les crawlers d’entraînement et les crawlers de recherche méritent des réponses différentes

Les crawlers 6 que nous sondons se divisent proprement en tâches 2, selon la documentation bot publiée de chaque opérateur :

• Recherche et récupération. OAI-SearchBot indexe le contenu afin que ChatGPT recherche puisse le mettre en avant et le lier — OpenAI documents que cet accès, et uniquement cet accès, détermine si les pages sont prises en compte pour les résultats de recherche ChatGPT. PerplexityBot construit l’index de recherche de Perplexity. Claude-SearchBot indexe pour améliorer les réponses soutenues par la recherche de Claude. Bloquer l’un de ces éléments vous retire des citations de cet assistant.
• Entraînement. GPTBot recueille du contenu qui peut entraîner les modèles OpenAI. ClaudeBot effectue l’équivalent de crawling pour Anthropic. CCBot alimente Common Crawl, le corpus ouvert derrière de nombreuses bases de données de recherche et d’entraînement. OpenAI précise que bloquer GPTBot n’affecte pas l’inclusion dans la recherche ChatGPT — les deux pipelines sont séparés.

Google exécute la même division sous différents noms : son IA profite de l’accès ordinaire de Googlebot, tandis que le token séparé Google-Extended contrôle l’entraînement et la contextualisation de Gemini. Nous avons couvert cette machinerie dans notre guide sur la recherche générative de Google.

La division transforme une anxiété vague en une décision à 2 parties. Bloquer les robots d’entraînement est une position légitime sur la façon dont votre contenu peut être réutilisé, et cela ne vous coûte rien en recherche IA. Bloquer les robots de récupération est une décision de visibilité — la même catégorie que l’auto‑noindexation — et elle mérite la même délibération.

Rédigez un robots.txt qui enregistre la décision

Voici une politique qui reste entièrement visible dans la recherche IA tout en retenant le consentement d’entraînement — la séparation délibérée la plus courante que nous voyons :

# Search & retrieval — open, so assistants can find and cite this site
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

# Training — withheld; this has no effect on AI search visibility
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

Si vous voulez tout ouvrir, dites-le explicitement plutôt que par omission — un groupe nommé Allow: / par robot documente qu’une personne a décidé, ce qui est exactement ce que les 17,8 % sans règles applicables manquent. 3 les étapes de vérification ferment la boucle. Récupérez https://yoursite.com/robots.txt depuis l’extérieur de votre réseau et lisez ce que la production sert réellement — les CDN et plateformes peuvent injecter ou remplacer le fichier dans votre dépôt, et certains fournisseurs de périphérie expédient un blocage de bot IA à 1‑clic qui annule entièrement vos directives. Vérifiez toute règle WAF ou de gestion de bots pour les mêmes agents utilisateurs 6, car la permission robots.txt ne signifie rien pour un robot qui obtient un 403. Puis relancez la vérification après chaque changement d’infrastructure ; une migration de fournisseur peut basculer ce commutateur sans toucher votre code. 1 remarque sur la façon dont notre audit lit la politique délibérée ci‑dessus : les interdictions globales sur GPTBot, ClaudeBot, et CCBot apparaîtront toujours comme une constatation. C’est intentionnel. Un blocage global d’IA‑crawler doit toujours être une décision affirmée, et la constatation est là où vous l’affirmez — le mode d’échec que cette vérification vise à détecter est le blocage que personne ne se souvient d’avoir écrit.

Le audit de visibilité le moins cher que vous ferez cette année

robots.txt est 1 de 2 fichiers par lesquels votre site communique avec les systèmes IA — l’autre est llms.txt, où nos données montrent 76% de fichiers échouent les agents pour lesquels ils ont été écrits. Les deux partagent la même signature d’échec que les blocages dans ce rapport : écrits une fois, syntaxiquement plausibles, jamais lus en retour. Notre analyse l’a fait, ce qui est la partie inconfortable de cette correction — une règle qui n’a pas été relue depuis le jour où elle a été écrite est exactement ce que cette vérification vise à détecter, et la nôtre n’a pas non plus été relue. Le tableau corrigé est aussi plus encourageant que le titre que nous avons d’abord exécuté. 4 des sites 6 qui bloquent un robot IA globalement nommés explicitement, et 2 de ceux 4 utilisent le blocage de signaux de contenu géré de Cloudflare — une politique 2026 que quelqu’un a choisie, pas une règle 2023 que personne n’a relue. Les blocages accidentels sont les restants, et ils sont un petit nombre. L’écart plus important dans cet exemple n’est pas que les sites bloquent les crawlers IA ; c’est les sites 8 dont le robots.txt ne contient rien que le crawler IA puisse lire du tout. Lire votre propre fichier prend 2 minutes ; le free report le fait pour vous, nomme chacun des 6 crawlers, et indique exactement quelle règle s’applique à chacun — ainsi la décision enregistrée est celle que vous avez réellement prise.