Nous avons passé l'audit standard des crawlers à 66 fournisseurs de visibilité IA. Les 66 l'ont réussi.

Tous les outils de ce marché vendent une vérification d’accès des crawlers, et ils font tous les trois mêmes : lire robots.txt, demander la page, chercher les chemins cachés. Nous les avons passées aux soixante-six fournisseurs de notre catalogue, nous compris. Les soixante-six les ont réussies toutes les trois.

Ce n’est pas un compliment à la catégorie. C’est un résultat sur les vérifications, et nous pouvons le dire avec une certaine autorité, parce que notre propre domaine les a toutes réussies un jour où un crawler se faisait refouler par notre CDN.

Transparence : EchoWi est l’un des soixante-six et vend de la mesure de visibilité IA, donc une étude concluant que la vérification gratuite n’apprend rien est une étude intéressée. Les trois méthodes sont décrites entièrement plus bas, la date est le 11 août 2026, les onze noms de crawler recherchés sont listés, et les décomptes sont dans notre registre de mesures. Rien ici n’usurpe un user-agent, pour une raison que la section méthode explique.

La version courte

1. Zéro sur soixante-six bloque un crawler IA dans robots.txt. Onze agents ont été cherchés, de GPTBot à Applebot-Extended.
2. Soixante-six sur soixante-six servent un client HTTP simple, ce que sont la plupart des crawlers.
3. Zéro cache ses prix, ses comparatifs ou sa documentation aux crawlers. Les seuls chemins interdits qui existent sont des flux, des routes d’administration et des doublons à paramètres.
4. Seize nomment explicitement des crawlers IA, et les seize les autorisent, ce qui ne change rien, puisqu’un crawler que personne ne mentionne est déjà autorisé.
5. Un sans-faute sur les trois est exactement ce qu’affichait notre propre site pendant qu’il bloquait un crawler, et c’est tout le propos de cet article.
6. Aucun user-agent n’a été usurpé dans tout cela, parce qu’envoyer le nom d’un crawler depuis sa propre machine ne prouve rien et c’est ainsi que se font presque tous ces audits.

Les trois vérifications, et ce que chacune demande vraiment

Lire robots.txt. Cela demande ce que le site a déclaré. C’est une instruction publiée aux crawlers bien élevés et c’est la seule des trois qu’on ne peut pas usurper, parce que le fichier appartient au site.

Demander la page. Cela demande si un serveur renvoie du contenu à un client qui n’est pas un navigateur. Nous avons envoyé un user-agent qui dit ce qu’il est, echowi-accessibility-check, plutôt que de nous faire passer pour GPTBot. Cette distinction fait toute la différence entre une mesure et une supposition : une fausse chaîne de crawler envoyée depuis notre machine n’est pas ce crawler, et un CDN qui décide sur le statut de bot vérifié et l’IP d’origine la laissera passer à chaque fois. Tout audit qui teste l’accès en envoyant le nom d’un autre ne teste rien.

Chercher les chemins cachés. Cela demande si les pages commercialement utiles, les prix, les comparatifs et la documentation, sont exclues du crawl.

Ce sont les trois que lance un audit gratuit de visibilité IA. Elles sont toutes raisonnables et toutes bon marché, ce qui explique que chaque outil les inclue.

Les résultats

Les onze agents cherchés étaient GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, anthropic-ai, PerplexityBot, Perplexity-User, Google-Extended, Bytespider, CCBot et Applebot-Extended.

Personne ne refuse rien dans l’autre sens non plus : à la question de ce qu’ils déclarent plutôt que de ce qu’ils bloquent, cinq des soixante-six ont une directive Content Signals et les cinq autorisent. Remesuré trois jours plus tard sur un catalogue plus large, et en lisant toutes les lignes de directive au lieu de la première, sept déclarent des Content Signals et un refuse l’entraînement, ce qui est aussi là où l’erreur d’instrument derrière le comptage précédent est écrite. Les chemins interdits qui existent relèvent de l’entretien. Surfer exclut un paramètre de pagination du blog, Semrush exclut des variantes à paramètres de suivi et la recherche de son blog, MaxAEO exclut des flux de commentaires, Rankability exclut des répertoires d’administration WordPress, Ahrefs exclut des requêtes d’archive, Alhena exclut des pages d’étiquettes, SE Ranking exclut un répertoire statique d’outils et Ceyo exclut de la documentation d’intégration de certains partenaires. Pas un seul des soixante-six n’exclut une page qu’un acheteur voudrait voir.

Les seize qui ont écrit des règles sans effet

Seize fournisseurs nomment explicitement des crawlers IA dans robots.txt : Airefs, Cloudflare AEO, EchoWi, KIME, MaxAEO, Omnibound, Qwairy, Rank Prompt, Rankability, Rankscale, SE Ranking, ScalePost, Siftly, Superlines, Surfeo et Wellows.

Les seize les autorisent. Et une autorisation explicite pour un crawler que personne ne bloquait ne change aucun comportement, parce que l’état par défaut d’un crawler non mentionné est déjà « autorisé ». Écrire User-agent: GPTBot suivi d’Allow: / produit exactement le même accès que ne rien écrire.

La seule différence mesurable entre ces seize et les cinquante autres est donc que seize ont pris la peine d’énoncer une intention. C’est raisonnable, puisqu’une future règle générique ne balaierait alors pas les crawlers nommés avec le reste. Ce n’est pas de l’accès, et une liste de contrôle qui compte cela comme un point compte un commentaire.

Nous sommes dans les seize. Ce paragraphe nous concerne.

Pourquoi un sans-faute est le mauvais genre de réconfort

Voici le cas qui rend les trois vérifications minces, et c’est le nôtre.

Notre robots.txt autorise chaque crawler IA par son nom. Nos pages sont statiques et servies à tout client qui les demande. Rien n’est caché. Sur les trois vérifications ci-dessus notre domaine obtient un score parfait, et il l’obtenait le jour où nous avons découvert qu’un crawler IA majeur était défié sur presque chacune de ses requêtes vers nous.

La cause n’était pas dans robots.txt et ne pouvait pas y être. Le Bot Fight Mode de Cloudflare défie tout bot absent de sa liste de vérifiés, il tourne hors du Ruleset Engine, donc aucune règle WAF ne peut en exempter quoi que ce soit, et il décide sur le statut de bot vérifié et l’IP d’origine plutôt que sur la chaîne envoyée par un client. Aucune des trois vérifications ne voit rien de tout cela. La seule chose qui pouvait le voir, ce sont les journaux du CDN lui-même, qui ne sont pas publics, et c’est pourquoi un tiers nous passant l’audit standard aurait produit un vert et se serait trompé.

Cela se généralise de façon inconfortable. Soixante-six fournisseurs réussissant trois vérifications vous dit que soixante-six fournisseurs n’ont pas publié d’instruction de rester à l’écart. Cela ne vous dit rien de ce que font leurs CDN, et la configuration du CDN est là où vivait la panne que nous avons réellement subie.

Que demander à la place

Demandez le journal, pas la vérification. La question qui a une réponse est : quels crawlers ont atteint votre origine, à quelle fréquence, et avec quels codes de statut. Cette donnée existe dans les journaux de votre CDN ou de votre serveur et nulle part ailleurs. Si un outil vous dit que votre site est accessible aux crawlers IA sans les avoir lus, il vous a dit ce qu’il pouvait voir plutôt que ce que vous demandiez.

Croisez le user-agent avec le chemin demandé. L’attribution par user-agent ne vaut rien dans les deux sens. Quand nous avons regardé ce que le nom d’un crawler avait demandé chez nous, les chemins comprenaient des fichiers de clé privée et des noms de fichiers de identifiants, ce qui est un scanner de vulnérabilités portant le nom d’un crawler et non un crawler. Un crawler légitime demande des articles.

Coupez la fenêtre au moment du changement. Si vous corrigez quelque chose, ne mesurez pas à travers la correction. Un agrégat qui couvre l’avant et l’après décrit la moyenne de deux régimes et aucun des deux, et c’est ainsi qu’une correction qui a marché se rapporte comme une correction à moitié réussie.

Et traitez un vert comme l’absence d’un seul type de problème. Réussir ces trois-là signifie que vous n’avez pas dit aux crawlers de partir. Cela vaut la peine d’être confirmé, cela prend une minute, et c’est là que cette classe d’audit s’arrête, pas là où elle cesse d’être utile.

Ce que cela ne démontre pas

Personne n’a été testé pour un accès réel. Pas une mesure ici n’établit qu’un crawler atteint l’un de ces soixante-six sites, le nôtre compris. Cela demanderait les journaux de chaque fournisseur.

Une lecture, un jour. robots.txt change, et un fournisseur pourrait ajouter demain une règle de blocage. Les onze agents sont ceux qui ont été cherchés ; un agent hors de cette liste pourrait être bloqué et n’apparaîtrait pas.

Bloquer n’est pas le seul échec. Un site peut être crawlé et rester incitable, ce qui est l’essentiel de ce que mesure le reste de ce blog.

Un 403 n’est pas toujours un blocage. La page de prix d’un fournisseur a renvoyé 403 au client simple de la vérification pendant que sa page d’accueil renvoyait 200. C’est compatible avec une règle de gestion de bots et tout autant avec une limite de débit ou une règle par chemin, et nous ne les avons pas distinguées, donc ce n’est pas compté comme un échec dans le tableau ci-dessus.

Et nous sommes dans l’échantillon. EchoWi est l’un des soixante-six et obtient le même score que tout le monde sur les trois, ce qui est l’argument entier et non une réserve.

Questions fréquentes sur l’accès des crawlers IA

Un robots.txt permissif signifie-t-il que les crawlers IA peuvent lire mon site ?

Non, et c’est l’erreur la plus courante de cette catégorie. robots.txt est une instruction aux crawlers qui choisissent de l’observer. Il ne dit rien de savoir si votre CDN défie la requête avant que votre serveur ne la voie, et les produits de gestion de bots décident sur le statut de bot vérifié et l’IP d’origine plutôt que sur le fichier. Notre propre site autorise chaque crawler IA par son nom et en avait un défié sur presque chaque requête.

Puis-je tester l’accès en envoyant le user-agent du crawler ?

Non, et le faire produit un faux succès à chaque fois. Une requête depuis votre machine portant PerplexityBot en user-agent n’est pas PerplexityBot, et toute couche de gestion de bots qui vaut son prix décide sur la liste des vérifiés et l’IP d’origine. Nous avons lancé ce test une fois sur dix agents, obtenu dix 200, et déclaré la couche propre. Elle ne l’était pas. La seule chose qui a tranché, ce sont les journaux de requêtes du CDN lui-même.

Si personne ne bloque les crawlers IA, pourquoi vérifier ?

Parce qu’un blocage est bon marché à causer et cher à manquer. Une règle de refus par défaut dans un produit de bots, un modèle de pare-feu, une configuration héritée d’une agence, et le crawler disparaît sans que rien sur la page ne le montre. Vérifier vaut la minute que cela coûte. Ce qui ne vaut rien, c’est de traiter le vert comme une affirmation sur votre visibilité, qui est un autre problème avec d’autres causes.

Quelle différence entre GPTBot et ChatGPT-User dans robots.txt ?

Ils font des travaux différents et les bloquer a des conséquences différentes. GPTBot est le crawler d’entraînement et d’indexation, et ChatGPT-User est la requête faite quand la question d’un utilisateur provoque la récupération d’une page en direct. Bloquer le premier est une décision sur les données d’entraînement. Bloquer le second vous retire des réponses en train de s’écrire. Seize fournisseurs de cet échantillon les nomment séparément, ce qui suggère que la distinction est comprise dans ce marché même là où les règles n’ont aucun effet.

Faut-il écrire des règles Allow explicites pour les crawlers IA ?

Cela ne coûte rien et cela n’accorde rien. Un crawler non mentionné est déjà autorisé, donc une autorisation explicite ne change aucun comportement aujourd’hui. La raison de les écrire, c’est qu’elles gardent un crawler nommé hors de toute règle générique que vous ou une agence pourriez ajouter plus tard, ce qui est une petite couverture et non une amélioration. Nous les avons écrites, et cet article est la raison pour laquelle nous ne nous en attribuons pas le mérite.

À quoi ressemblerait un audit de crawlers vraiment utile ?

Il lirait les journaux de votre CDN ou de votre serveur plutôt que d’émettre des requêtes depuis ailleurs, rapporterait par crawler et par code de statut, croiserait le user-agent avec les chemins demandés pour séparer les scanners portant des noms de crawler, et couperait toute fenêtre au moment où une configuration a changé. Chacun de ces points exige un accès à votre infrastructure, ce qui explique que la version gratuite de cette vérification fasse les trois choses ci-dessus, et que ces trois choses renvoient soixante-six résultats propres.