Pourquoi robots.txt ne suffit pas pour ChatGPT

robots.txt n’est pas une couche de contrôle d’accès fiable pour les récupérations déclenchées par les utilisateurs dans ChatGPT. OpenAI indique désormais que son agent ChatGPT-User peut ne pas suivre robots.txt lorsqu’une personne demande à ChatGPT de visiter une page. C’est important, car beaucoup d’équipes ont traité un seul fichier texte comme s’il remplissait deux fonctions différentes à la fois : contrôler la visibilité auprès des IA et empêcher l’accès des IA. Ce n’est pas le cas. Si une page doit réellement rester hors de portée, le contrôle doit se situer au niveau du serveur, du CDN, du pare-feu ou de l’authentification. Si l’objectif est la visibilité dans ChatGPT Search, le bot qui compte est OAI-SearchBot, et c’est une décision totalement différente.

C’est un changement plus profond qu’il n’y paraît. Il oblige les équipes SEO, contenu et infrastructure à séparer les règles de courtoisie des règles opposables, et rend l’analyse des logs plus importante que les suppositions. Il confirme aussi quelque chose que les marques présentes dans la recherche IA apprennent souvent à leurs dépens : la visibilité et l’accès ne relèvent plus du même problème.

Que dit réellement OpenAI ?

La position d’OpenAI est simple. ChatGPT-User est utilisé lorsqu’un utilisateur de ChatGPT ou un GPT personnalisé demande une page, et comme cette action est initiée par l’utilisateur, les règles robots.txt peuvent ne pas s’appliquer. OpenAI précise aussi que cet agent n’est pas utilisé pour le crawl automatique et qu’il ne s’agit pas du bot qui détermine si votre contenu peut apparaître dans ChatGPT Search.

Cette distinction compte davantage que le titre accrocheur. Beaucoup de propriétaires de sites voient un user-agent OpenAI dans leurs logs et pensent qu’il s’agit d’un seul système avec un seul ensemble de règles. En pratique, OpenAI répartit ces rôles entre plusieurs agents. L’un est lié à l’inclusion dans la recherche, un autre à l’entraînement, et un autre peut récupérer des pages en réponse à la demande d’un utilisateur.

Un exemple simple montre pourquoi c’est crucial. Imaginez qu’une entreprise logicielle bloque ChatGPT-User dans robots.txt parce qu’elle veut mieux maîtriser son trafic IA. Cette mesure peut ne pas empêcher une récupération déclenchée par l’utilisateur. Si la même entreprise bloque aussi OAI-SearchBot, elle risque de perdre de la visibilité dans les réponses de ChatGPT Search tout en échouant malgré tout à créer une vraie barrière contre les récupérations. C’est ce genre d’arbitrage que les équipes doivent comprendre avant de toucher au fichier.

Si vous travaillez sur la recherche IA, cela recoupe aussi ce que nous avons expliqué dans notre analyse du fait que ChatGPT Search cite moins de domaines. Les chemins de récupération deviennent plus sélectifs, et la couche de récupération des pages fait désormais partie de la conversation sur la visibilité, pas seulement d’un détail de backend.

Quel bot contrôle la visibilité dans ChatGPT Search ?

La réponse courte est OAI-SearchBot, pas ChatGPT-User. OpenAI indique que OAI-SearchBot est le crawler utilisé pour faire remonter les sites dans les fonctionnalités de recherche de ChatGPT. Si un site refuse OAI-SearchBot, OpenAI précise qu’il n’apparaîtra pas dans les réponses de ChatGPT Search, même s’il peut encore apparaître sous forme de lien de navigation.

C’est précisément là que beaucoup d’équipes se tromperont si elles ne regardent que les noms de user-agent isolément. Bloquer tous les bots OpenAI peut sembler propre, mais cela mélange trois questions distinctes :

• Voulez-vous que votre contenu soit éligible aux réponses de ChatGPT Search ?
• Voulez-vous que votre contenu soit utilisé pour l’entraînement ?
• Voulez-vous que les récupérations déclenchées par l’utilisateur atteignent la page ?

Ce ne sont pas les mêmes décisions de politique. Un éditeur qui veut de la visibilité en recommandation peut choisir d’autoriser OAI-SearchBot tout en interdisant GPTBot. Un site par abonnement peut toujours avoir besoin de contrôles stricts autour de ses pages premium, même s’il veut rendre une partie de son contenu public découvrable. Une marque qui gère des documents sensibles peut autoriser la visibilité des pages d’atterrissage publiques tout en imposant une authentification pour les actifs internes. Une seule règle ne peut pas couvrir tout cela de manière cohérente.

C’est aussi pour cela que la mesure de la visibilité doit aller au-delà du suivi classique des classements. Dans la recherche IA, être indexé n’est qu’une couche. Une marque doit aussi savoir si ses pages ressortent réellement dans les réponses, quelles sources sont citées autour d’elle et comment les concurrents apparaissent dans les mêmes prompts. C’est exactement le type de flux de travail pour lequel la fonctionnalité Analyse de visibilité multi-LLM de BotRank a été conçue.

Que nous apprend la donnée TollBit sur le comportement réel ?

Le signal le plus important du rapport State of the Bots de TollBit pour le premier semestre 2026 est qu’il ne s’agit pas d’un cas limite théorique. Sur les sites européens couverts par le rapport, environ 15 % des récupérateurs de pages IA identifiés ont atteint des URL marquées comme interdites. ChatGPT-User, Bytespider et Youbot ont chacun accédé à des pages interdites sur près de la moitié des sites européens qui les avaient explicitement listés, et ChatGPT-User a atteint le plus grand nombre de sites dans ce groupe.

Cette donnée transforme une note de documentation en problème opérationnel. Si un bot peut encore atteindre des URL interdites dans certaines conditions, robots.txt cesse d’être une porte d’entrée fiable et redevient ce qu’il a toujours été techniquement : une demande adressée à des crawlers coopératifs, pas un mécanisme d’application.

Le reste du rapport apporte un contexte utile. Certains agents de récupération plus récents étaient à peine bloqués, avec des taux de refus à un seul chiffre sur de nombreux sites. ChatGPT-User faisait figure d’exception. TollBit a aussi mis en évidence des différences régionales, comme des taux de refus plus faibles en Europe qu’en Amérique du Nord pour des agents comme Claude-User et Perplexity-User. Cela suggère que la politique des éditeurs reste incohérente, et que beaucoup d’équipes définissent probablement leurs règles de crawl sans modèle clair de ce que fait réellement chaque bot.

Exemple concret : un site média peut penser avoir adopté une position ferme en interdisant plusieurs récupérateurs IA dans robots.txt. En réalité, il a peut-être créé une règle symbolique pour certains agents, un vrai refus pour d’autres, et aucune barrière solide du tout pour les pages qui comptent le plus. Sans logs, codes de réponse et cartographie de la politique par bot, cette équipe navigue à l’aveugle.

Pour un contexte plus large, notre article sur ce que 68,9 millions de visites de robots d’indexation IA nous apprennent sur la visibilité dans la recherche IA montre à quel point le trafic IA d’aujourd’hui est lié à la récupération en temps réel, et non à l’ancien modèle du simple index.

Pourquoi robots.txt est-il le mauvais outil pour un vrai contrôle d’accès ?

Parce que robots.txt est une déclaration, pas un verrou. Il indique aux bots coopératifs où vous préférez qu’ils n’aillent pas. Il n’authentifie pas les visiteurs, ne bloque pas les requêtes à la périphérie et n’empêche pas un système conçu pour traiter certaines visites comme des actions d’utilisateur plutôt que comme des actions de crawler.

Ce n’est pas une limite nouvelle, mais l’ère de l’IA la rend plus douloureuse. Un chemin refusé dans robots.txt peut encore être accessible si le serveur renvoie lui-même la page. Si le contenu est sensible, limité par abonnement, sous licence ou juridiquement restreint, la seule approche sûre consiste à appliquer le contrôle d’accès avec les mécanismes qui se trouvent réellement devant le contenu : connexion obligatoire, URL signées, règles WAF, restrictions géographiques, vérification de jetons, limitations de débit ou logique de paywall.

Pour les équipes SEO, le piège opérationnel est facile à repérer. robots.txt paraît familier, modifiable et visible. Les contrôles d’infrastructure exigent souvent un travail transversal entre plusieurs équipes. Mais le coût de la solution la plus simple augmente. Une marque peut bloquer par erreur le bot qui influence sa visibilité, ne pas empêcher l’agent qui l’intéresse le plus, et ne jamais vérifier ce que ces systèmes reçoivent réellement en HTML brut ou en réponse serveur.

C’est pourquoi les audits SEO techniques ont désormais besoin d’une couche de préparation à l’IA. La question n’est plus seulement de savoir si une page peut se positionner. Il faut aussi savoir si les bons bots peuvent accéder aux bonnes pages, si les mauvais bots sont vraiment bloqués là où c’est nécessaire et si la page est lisible par machine lorsqu’elle est récupérée.

Il existe aussi un signal de marché. Cloudflare s’est déjà orienté vers des contrôles au niveau du réseau qui classent le trafic IA par fonction, avec de nouvelles règles par défaut pour les crawlers de Training et d’Agent sur les pages financées par la publicité. Cette direction est logique. Une fois que les récupérateurs déclenchés par l’utilisateur entrent dans l’équation, la politique ne peut plus dépendre de la simple courtoisie des crawlers.

Le point de vue BotRank

L’erreur pratique ici consiste à traiter chaque visite OpenAI comme un seul problème de visibilité. Ce n’est pas le cas. Certaines visites influencent l’inclusion dans la recherche, d’autres influencent l’entraînement, et d’autres encore se produisent parce qu’un utilisateur a demandé une page. Si votre équipe répond par une règle robots.txt globale, vous risquez de faire le mauvais compromis pour les trois.

La fonctionnalité BotRank la plus adaptée à ce moment est l’Analyse de pages GEO. Elle donne aux équipes une vue technique récurrente des pages qui comptent vraiment pour elles, avec des signaux de préparation au crawl comme la gestion de robots.txt et de llms.txt, ainsi que des problèmes plus larges de machine accessibility qui peuvent rendre une page inutile même lorsqu’elle est techniquement atteignable. C’est important, parce que la vraie question n’est pas seulement : « Un bot est-il passé ? » La vraie question est : « La page a-t-elle été correctement exposée, correctement protégée et structurellement prête à être réutilisée dans une réponse IA ? » Un simple score technique ne résoudra pas la politique. En revanche, il transforme une inquiétude floue sur la recherche IA en quelque chose que les équipes peuvent examiner, prioriser et améliorer dans le temps.

Que doivent faire ensuite les équipes SEO, contenu et infrastructure ?

Elles doivent cesser de considérer robots.txt comme l’intégralité de la politique. La meilleure approche consiste à séparer le travail en trois volets : visibilité, protection et vérification.

1. Séparer les règles de visibilité des règles de protection

Définissez clairement quelles pages publiques vous voulez rendre éligibles à ChatGPT Search, quelles pages ne doivent pas être utilisées pour l’entraînement et quelles pages ne doivent pas être récupérables sans contrôles plus stricts. Ces décisions relèvent généralement de parties prenantes différentes. Le marketing peut se soucier de la visibilité dans la recherche, le juridique de la licence, et l’ingénierie de l’application concrète.

Un exemple pratique est celui d’une entreprise SaaS avec des pages produit publiques, des ressources comparatives protégées et une documentation interne. Les pages publiques peuvent bénéficier de l’accès d’OAI-SearchBot. Les ressources protégées peuvent nécessiter une connexion ou des liens signés. La documentation interne ne devrait pas être laissée à robots.txt seul.

2. Inspecter les logs, pas les suppositions

Si vous voulez savoir ce qui s’est passé, regardez les logs serveur, les logs CDN ou les tableaux de bord de bot management. Vérifiez les user-agent, les chemins demandés, les codes de statut, les horodatages et le fait que la page ait bien renvoyé une vraie réponse. Une ligne de refus montre ce que vous avez demandé. Les logs montrent ce qui est réellement arrivé.

C’est aussi là que la visibilité au niveau des sources compte. Si ChatGPT mentionne votre marque mais cite une page tierce au lieu de la vôtre, le schéma de trafic et le schéma de réponse peuvent raconter deux histoires différentes. L’Analyse des sources de BotRank aide les équipes à voir quelles pages sont réellement citées et si ces pages citent réellement la marque de manière utile.

3. Vérifier la lisibilité machine des pages publiques

Même lorsqu’une page est autorisée, elle doit encore être exploitable. Une structure HTML claire, des titres accessibles, un contenu principal visible dans le HTML brut et une livraison technique stable augmentent les chances qu’un système de récupération comprenne la page. Si le texte important n’existe qu’après rendu côté client, autoriser le bot peut ne rien changer.

C’est là que beaucoup d’équipes découvrent que la visibilité dans l’IA est à la fois un problème de contenu et un problème technique. Une page faible peut être accessible et malgré tout échouer. Une page solide peut être bloquée au mauvais endroit et ne jamais avoir de vraie chance.

4. Transformer la politique en workflow suivi

Une fois la politique clarifiée, attribuez les actions. Mettez à jour robots.txt lorsqu’il s’applique réellement. Ajoutez des contrôles côté serveur lorsqu’il ne s’applique pas. Validez les changements dans les logs. Vérifiez à nouveau si la visibilité a réellement évolué dans les réponses IA. Puis documentez les écarts qui subsistent.

C’est un bon cas d’usage pour le workflow Recommandations de BotRank. Il aide à transformer les constats techniques et de visibilité en véritable backlog, au lieu de les laisser dispersés dans des notes séparées entre SEO, contenu et ingénierie.

FAQ

Bloquer ChatGPT-User dans robots.txt fait-il disparaître mon site de ChatGPT Search ?

Non. OpenAI indique que ChatGPT-User n’est pas utilisé pour décider si un contenu apparaît dans Search. Pour les refus liés à Search et la gestion du crawl automatique, OpenAI renvoie les propriétaires de sites vers OAI-SearchBot.

robots.txt peut-il protéger du contenu privé, payant ou sensible contre les récupérations IA ?

Non. robots.txt n’est pas un système de contrôle d’accès sécurisé. Si une page doit vraiment rester protégée, appliquez ce contrôle au niveau du serveur, de l’authentification, du CDN ou du pare-feu.

Les marques devraient-elles bloquer tous les bots OpenAI pour rester en sécurité ?

En général, non. Un blocage global mélange visibilité dans la recherche, politique d’entraînement et récupération déclenchée par l’utilisateur. Une meilleure politique est spécifique au bot et à la page, en fonction de l’usage du contenu et du niveau de risque.

Que faut-il surveiller après avoir modifié les règles de crawl ?

Surveillez les logs, les codes de réponse, l’activité de crawl et la visibilité réelle dans les réponses. Si l’objectif est la performance GEO, surveillez aussi si votre marque est mentionnée, comment elle est décrite et quelles pages ou sources tierces soutiennent ces réponses via un outil comme Analyse de visibilité multi-LLM.

Quel est le vrai enseignement pour les marques ?

L’enseignement réel est simple : robots.txt est désormais un signal de visibilité, un signal d’entraînement et parfois seulement une suggestion polie. Il n’est plus prudent de le traiter comme votre contrôle principal pour le trafic IA. Si vous voulez de la visibilité dans ChatGPT Search, gérez le bon bot de recherche. Si vous voulez une protection stricte, appliquez-la à la périphérie ou derrière l’authentification. Si vous voulez savoir si tout cela fonctionne, mesurez ensemble les réponses, les sources et les logs.

C’est là que le GEO devient opérationnel. Les marques qui réussiront dans la recherche IA ne seront pas celles qui ont la politique de crawl la plus bruyante. Ce seront celles qui savent quels agents comptent, quelles pages méritent un accès, quelles pages nécessitent une vraie protection et comment ces choix modifient ce que les utilisateurs voient réellement dans les résultats générés par l’IA.