13% des sites audités bloquent un crawler IA — Correction de notre propre 40.8%

Mise à jour August 31, 2026. La version de cet article publiée en août 20 commençait par «20 des 49 sites que nous avons audités — 40.8%». Ce nombre était erroné deux fois. 40.8% était la part des exécutions d’audit individuelles qui ont échoué le contrôle, pas la part des sites distincts, et le multiplier à nouveau sur un compte de sites a produit un «20 sites» que personne n’avait jamais compté. Pire encore, lorsque nous sommes retournés et avons relu chaque robots.txt de l’échantillon par rapport à 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.

Le August 31, 2026 nous avons refait le 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 crawler IA majeur de l’ensemble du site. À l’autre extrême, 8 sites n’ont aucune règle qui s’applique aux crawlers IA du tout — même pas une directive générique pour qu’ils obéissent. Cela représente 17.8% de l’échantillon.

Cela laisse 31 sites — 68.9% de l’échantillon — avec un robots.txt qui indique une politique qu’un crawler IA lira réellement et ne bloque aucun d’eux sur l’ensemble du site. Le compte ne révèle pas combien de propriétaires ont délibérément examiné ces politiques, et une restriction sur un crawler de formation seul ne constitue pas une perte de visibilité de recherche.

Méthodologie. La population est chaque domaine distinct avec un audit complété dans notre fenêtre moteur 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 stocké. C'est une re-récupération le même jour des fichiers robots.txt en direct de ces domaines, lue en août 31 et évaluée avec le parseur corrigé. 3 des 48 ne servent plus du tout de robots.txt, c'est pourquoi le dénominateur est 45. L'échantillon est auto-sélectionné — ce sont des sites que quelqu'un a choisi d'auditer — et il penche vers les petites à moyennes tailles. Considérez les taux comme directionnels pour la longue traîne du web plutôt que pour le web en général. Les domaines ne sont pas nommés.

La correction fait partie des preuves

La relecture des fichiers a révélé une gestion incorrecte des valeurs d'interdiction vides et la relation entre les groupes de crawler nommés et les règles génériques. RFC 9309 fournit l'interprétation publique : un chemin vide est ignoré, et les groupes nommés applicables priment sur le groupe générique. Les groupes pour le même crawler peuvent devoir être combinés ; l'ordre des fichiers seul n'est pas une politique fiable.

Les défauts ont été corrigés et les tests de régression conservent les cas qui les ont exposés. Dans cet échantillon, 5 sites précédemment étiquetés bloqués ne l'étaient pas, tandis que 1 précédemment étiquetés clairs étaient bloqués. Le résultat corrigé est une observation datée des fichiers récupérés. Il n'établit pas l'accès d'aujourd'hui ni un taux de prévalence à l'échelle du web.

robots.txt n'est qu'une surface d'accès. Un défi CDN, mur de connexion ou refus réseau peut empêcher la récupération même lorsque le fichier le permet. À l'inverse, une restriction d'entraînement délibérée n'est pas la preuve qu'un site est invisible dans la recherche IA. Le chiffre 13.3% combine les buts du crawler et ne peut pas être présenté comme un taux d'exclusion de recherche IA.

L'accès à la recherche et la permission d'entraînement sont des décisions différentes

la documentation du bot de OpenAI distingue OAI-SearchBot, utilisé pour la découverte de recherche, de GPTBot, utilisé pour un entraînement potentiel de modèle. Leurs contrôles sont indépendants. ChatGPT-User représente les visites dirigées par l'utilisateur et a un rôle différent encore. Une révision de politique doit nommer le but qu'elle entend autoriser ou restreindre.

Les documents Anthropic séparent les crawlers pour l'entraînement, la recherche et la récupération utilisateur aussi. Ne transformez pas l'expression large « AI bot » en un seul interrupteur d'autorisation à moins que ce ne soit vraiment l'intention du propriétaire.

Google possède ses propres surfaces de contrôle. Notre guide de recherche générative couvre son paramètre d'inclusion dans Search Console ainsi que la crawl, l'indexation et l'éligibilité aux extraits. Google-Extended est un contrôle séparé ; sa présence dans robots.txt ne remplace pas l'examen du paramètre Search.

Ces distinctions sont commercialement utiles. Une entreprise peut vouloir que sa documentation publique soit découverte par des clients potentiels tout en prenant une décision distincte concernant l'entraînement. Ni une règle d'autorisation ni un paramètre d'inclusion ne garantissent qu'une réponse citera la page. Elles établissent une partie des conditions sous lesquelles la découverte peut se produire.

Examinez un important URL par rapport à la politique que vous aviez l'intention

Choisissez une page qu'un client potentiel devrait pouvoir trouver : un guide utile, une explication de produit ou un exemple de développeur. Enregistrez le fournisseur et le but du crawler, la politique applicable, et la réponse réellement délivrée. Conservez une horodatation et distinguez une demande de fournisseur réellement vérifiée d'un test qui n'utilise que son nom d'user-agent.

Si le propriétaire veut la découverte par recherche et que le crawler de recherche pertinent est involontairement interdit, réparez ce conflit spécifique. Si un bloc d'entraînement est délibéré, enregistrez-le comme délibéré. Ne le supprimez pas uniquement pour rendre le score global du bot plus vert.

Une règle nommée manquante n'est pas automatiquement un défaut. Une règle générique peut gouverner le crawler ; si aucun groupe ne s'applique, la norme robots ne considère pas cette absence comme une interdiction. Les règles explicites peuvent documenter l'intention, mais plus de lignes ne signifient pas intrinsèquement une meilleure politique d'accès.

Après avoir modifié le fichier, inspectez la réponse en direct. Un fichier ou un cache géré par le fournisseur peut différer de la copie du dépôt. Ensuite vérifiez la page importante elle-même, y compris la destination finale après tout redirection. L'article sur les conflits d'indexabilité explique pourquoi l'autorisation de crawler et l'autorisation d'indexer sont des observations distinctes.

Mesurez si l'accès devient une visibilité utile.

Conservez la politique et les preuves de réponse avant de chercher des résultats. Google impressions d'IA générative, citations de fournisseurs, visites de référence et actions de produit utiles répondent chacune à une question différente. Enregistrez leur source et leur fenêtre de reporting au lieu de les intégrer dans un total d'IA de visibilité inventé.

Pour SEOReport, la preuve publique la plus forte est une page affectée, le comportement prévu par le propriétaire, une réparation concrète et un résultat de vérification reproductible. Les lecteurs peuvent évaluer ces faits sans avoir besoin de la recette de détection privée. Le guide de préparation à la recherche IA relie ces observations à une revue pratique.

Cette correction change la leçon du titre original. Notre échantillon soutient un petit nombre, daté, de restrictions de crawler. Le travail utile consiste à décider quelles restrictions correspondent à l'intention du propriétaire, à vérifier la page livrée et à mesurer les résultats que la surface de recherche choisie rapporte réellement.