robots.txt et IA : bloquer GPTBot ne bloque pas ChatGPT
En 2023, quand OpenAI a publié le nom de son robot d'entraînement, des milliers de sites ont ajouté deux lignes à leur fichier robots.txt : User-agent: GPTBot puis Disallow: /. Beaucoup pensent depuis que ChatGPT ne peut plus lire leurs pages. C'est faux, et la confusion vient d'une réalité que les opérateurs d'IA documentent pourtant clairement : ils n'envoient pas un robot, mais plusieurs, chacun avec un rôle et un jeton distincts. Bloquer l'un ne bloque pas les autres.
Plusieurs robots, plusieurs rôles, chez chaque éditeur
Chez OpenAI, d'après sa documentation des robots :
- GPTBot collecte des pages qui peuvent servir à entraîner les modèles. C'est le seul dont le blocage protège contre l'utilisation en entraînement.
- OAI-SearchBot alimente l'index de la recherche intégrée à ChatGPT. Le bloquer retire vos pages des résultats de recherche de ChatGPT, donc des citations qui en découlent.
- ChatGPT-User va chercher une page précise quand un utilisateur en fait la demande dans une conversation, par exemple en collant une URL ou en posant une question qui déclenche une lecture. Il ne parcourt pas le web de façon autonome.
Anthropic applique la même séparation, décrite dans sa page d'aide consacrée aux robots : ClaudeBot pour l'entraînement, Claude-SearchBot pour l'index de recherche, Claude-User pour les récupérations demandées par un utilisateur. Perplexity documente PerplexityBot (index) et Perplexity-User (récupération à la demande) dans sa documentation des crawlers.
Google et Apple : un jeton de contrôle séparé du robot
Google fonctionne différemment. Googlebot reste l'unique robot qui explore les pages pour la recherche, et ce sont ces mêmes pages qui alimentent les AI Overviews. Le contrôle de l'usage en entraînement passe par un jeton distinct, Google-Extended, qui n'est pas un robot mais une directive lue par Googlebot, comme l'explique la liste des crawlers courants de Google. Google précise que ce jeton ne change rien à l'indexation des pages. Apple procède de même avec Applebot-Extended, jeton documenté dans son article d'assistance sur Applebot, qui contrôle l'usage en entraînement sans toucher à Applebot lui-même.
Il faut ajouter à cette liste CCBot, le robot de Common Crawl, dont les archives ouvertes ont servi de matière première à de nombreux modèles. Bloquer CCBot est le levier le plus large contre l'entraînement par des acteurs qui n'ont pas de robot propre.
Le tableau des jetons, et ce que chaque blocage implique
| Jeton robots.txt | Opérateur | Rôle | Si vous le bloquez |
|---|---|---|---|
| GPTBot | OpenAI | Entraînement | Aucun usage en entraînement, citation toujours possible |
| OAI-SearchBot | OpenAI | Index de recherche ChatGPT | Vos pages disparaissent des résultats et citations de ChatGPT |
| ChatGPT-User | OpenAI | Lecture à la demande d'un utilisateur | Un utilisateur ne peut plus faire lire votre page dans une conversation |
| ClaudeBot / Claude-SearchBot / Claude-User | Anthropic | Les trois mêmes rôles | Mêmes conséquences, côté Claude |
| PerplexityBot / Perplexity-User | Perplexity | Index / lecture à la demande | Disparition des réponses Perplexity / lecture impossible |
| Google-Extended | Jeton de contrôle de l'entraînement Gemini | Aucun effet sur la recherche ni sur les AI Overviews | |
| Applebot-Extended | Apple | Jeton de contrôle de l'entraînement | Aucun effet sur Applebot (Siri, Spotlight) |
| CCBot | Common Crawl | Archive ouverte | Retrait des futures archives, pas des anciennes |
Ce que robots.txt peut et ne peut pas faire
Le protocole est aujourd'hui normalisé par la RFC 9309. Trois de ses règles expliquent la plupart des surprises :
- Le fichier n'est lu qu'à la racine de l'hôte. C'est bien l'hôte et non le domaine : un robots.txt servi sur exemple.com ne gouverne pas blog.exemple.com, qui est un hôte distinct. Un robots.txt placé dans un sous-répertoire, par exemple sous un chemin /blog/ hébergé ailleurs, n'est jamais consulté. Les directives qu'il contient, y compris les déclarations de sitemap, sont invisibles pour tous les robots. Sur un média monté en sous-chemin d'un site principal, c'est le robots.txt du site principal qui fait foi.
- Le groupe le plus spécifique l'emporte, et il remplace le groupe générique. Un groupe User-agent: GPTBot qui ne contient que Disallow: / n'hérite pas des règles du groupe User-agent: *. Si le groupe générique interdisait des facettes ou des fichiers, le robot nommé y a de nouveau accès. C'est une erreur courante quand on empile des groupes par robot au fil des mois.
- Le fichier est une consigne, pas une barrière. Les éditeurs cités ici déclarent le respecter. Un acteur qui ne déclare pas son nom échappe à toute règle nommée. Pour bloquer réellement, il faut agir au niveau du serveur ou du pare-feu, avec les effets de bord que nous décrivons dans l'article sur l'angle mort des blocages en edge.
Quelle politique choisir
La décision est éditoriale avant d'être technique. Trois positions se tiennent :
- Tout ouvrir. Le site accepte l'entraînement et la citation. C'est la position par défaut d'un média qui cherche la visibilité, y compris dans les modèles eux-mêmes.
- Refuser l'entraînement, accepter la citation. On bloque GPTBot, ClaudeBot, CCBot et on interdit Google-Extended et Applebot-Extended, tout en laissant passer OAI-SearchBot, Claude-SearchBot, PerplexityBot et les robots « User ». C'est la position d'un éditeur qui veut être cité sans nourrir les modèles gratuitement.
- Tout fermer. Le site renonce à la visibilité dans les IA. C'est défendable pour un intranet ou un contenu payant, pas pour un média qui veut peser sur une SERP ou une réponse générée.
La deuxième position est répandue chez les éditeurs de presse, et souvent mal appliquée : dans la pratique, beaucoup ont interdit d'un seul geste tout ce qui contenait « GPT » ou « Claude », donc aussi les robots de recherche et de lecture. Le résultat est un site absent des réponses générées, sans que personne dans l'équipe ne l'ait décidé.
Vérifier plutôt que supposer
Le contrôle tient en deux gestes. D'abord relire le fichier robots.txt tel que servi à la racine, jeton par jeton, en gardant le tableau ci-dessus sous les yeux. Ensuite ouvrir les logs du serveur pour voir quels robots viennent réellement, à quelle fréquence, et lesquels reçoivent un code 403 ou 404. Un robot d'IA qui ne figure jamais dans les logs n'est pas forcément absent : il a pu être arrêté en amont par un pare-feu, avant d'atteindre le serveur. Cette vérification est décrite pas à pas dans « Lire un access log en 30 minutes ».
Pour la partie Google, la Search Console fournit un rapport robots.txt qui montre la dernière version lue par Googlebot, sa date de récupération et les erreurs d'analyse éventuelles ; la présentation de robots.txt par Google en décrit l'usage. Pour les autres éditeurs, il n'existe pas d'équivalent : ce sont les logs qui font foi, et un test manuel avec le user-agent de chaque robot reste le moyen le plus sûr de vérifier ce que le serveur répond réellement.
Un média qui veut être cité ne peut pas s'en remettre à un fichier écrit il y a deux ans. Les jetons changent, les robots se multiplient, et une ligne ajoutée par précaution un jour de 2023 peut coûter toute présence dans les réponses des IA en 2026.
Écrit par
Yann Léguillon
Président de Mazette, l'éditeur de Joornal. Il accompagne des entreprises qui construisent leur média : structuration éditoriale, visibilité dans les moteurs et dans les IA, production à l'échelle.