GPTBot, ClaudeBot, PerplexityBot : bloquer ou laisser passer ?

Trois robots, deux métiers différents

Un robot d’entraînement lit une page pour l’ajouter à la base de données qui servira à construire un futur modèle. Un robot de réponse lit une page au moment précis où un utilisateur pose une question, pour extraire une citation ou un lien dans la réponse générée. Techniquement, les deux s’annoncent de la même façon dans un fichier robots.txt, avec une ligne User-agent. Économiquement, ils n’ont rien à voir : bloquer l’un protège un contenu contre une réutilisation future, bloquer l’autre retire immédiatement votre site des réponses citées par ChatGPT, Claude ou Perplexity. La confusion entre les deux est la première erreur que commettent les PME romandes lorsqu’elles configurent leur fichier robots.txt.

Depuis l’ouverture massive des assistants de recherche IA au grand public, beaucoup de responsables marketing romands se posent la question dans l’urgence, souvent après avoir lu un article alarmiste sur le pillage de contenu par les modèles de langage. La réaction réflexe consiste à bloquer tout ce qui ressemble à un robot IA dans le fichier robots.txt. Cette réaction protège effectivement un contenu contre l’entraînement futur d’un modèle, mais elle retire aussi, dans le même geste, toute chance d’apparaître dans une réponse ChatGPT, Claude ou Perplexity le jour même. Le reste de cet article détaille le calcul, robot par robot, pour éviter de trancher les deux questions en même temps sans le vouloir.

GPTBot, ClaudeBot, PerplexityBot : qui fait quoi

Chaque opérateur publie en réalité plusieurs robots, avec des fonctions distinctes. Les confondre revient à bloquer sa visibilité dans les réponses IA en croyant seulement limiter l’entraînement.

Une confusion fréquente mérite d’être signalée à part : Google-Extended n’est pas Googlebot. Bloquer Google-Extended n’a aucun effet sur l’indexation classique d’un site dans Google Recherche, qui reste entièrement pilotée par Googlebot. Un responsable marketing qui bloque Google-Extended pensant protéger son référencement classique ne change rien à son classement, mais réduit sa présence potentielle dans les résumés générés par l’intelligence artificielle de Google.

Une analyse du réseau Cloudflare publiée en août 2026 montre que GPTBot est bloqué 2,33 fois pour chaque site qui l’autorise, alors qu’OAI-SearchBot, le robot de recherche de la même entreprise, est autorisé presque aussi souvent qu’il est bloqué. Les éditeurs qui ont pris le temps de distinguer les deux robots ne subissent donc pas le même arbitrage que ceux qui bloquent « OpenAI » en bloc.

Pour une fiduciaire genevoise ou un cabinet d’architectes vaudois, la différence se traduit très concrètement. Un client potentiel demande à ChatGPT une recommandation de fiduciaire à Genève : si GPTBot est bloqué mais qu’OAI-SearchBot est autorisé, la page reste éligible à cette réponse. Si les deux sont bloqués sous une même règle générique, la fiduciaire disparaît purement et simplement de cette conversation, sans que personne dans l’entreprise ne s’en rende compte, faute d’outil de suivi dédié aux citations IA.

Le vrai calcul : ce qu’un blocage protège, ce qu’il coûte

Ce qu’un blocage protège réellement

Bloquer un robot d’entraînement limite la réutilisation de vos textes dans un futur modèle de langage. C’est pertinent pour un contenu à forte valeur ajoutée éditoriale, un jeu de données propriétaire, ou un secteur où la confidentialité contractuelle interdit toute réutilisation externe. Ce blocage n’a en revanche aucun effet rétroactif : un contenu déjà indexé par un robot d’entraînement avant le blocage reste dans les jeux de données déjà constitués.

Ce qu’un blocage coûte en visibilité IA

Bloquer un robot de réponse, souvent par excès de prudence en bloquant tous les user-agents contenant « GPT » ou « AI », retire mécaniquement votre site des réponses citées. Pour une PME dont l’objectif affiché est justement d’être trouvée par les moteurs de réponse, ce choix contredit l’objectif business. C’est un passage autonome qui résume le sujet : un robot d’entraînement construit un modèle, un robot de réponse construit une citation ; le premier se bloque pour protéger un contenu, le second se bloque au prix de la visibilité qu’on cherche à obtenir.

La méthode en cinq étapes

1. Clarifier l’objectif : protéger un contenu propriétaire, viser des citations dans les réponses IA, ou les deux selon les sections du site.
2. Séparer, pour chaque opérateur, le robot d’entraînement du robot de réponse, plutôt que de bloquer un opérateur en bloc.
3. Écrire une ligne User-agent explicite par robot dans robots.txt, jamais une règle générique visant tout ce qui contient « bot » ou « AI ».
4. Vérifier dans les journaux du serveur que les robots respectent effectivement les directives publiées, plutôt que de se fier au seul fichier.
5. Revoir la configuration chaque trimestre : les opérateurs ajoutent régulièrement de nouveaux user-agents, avec des fonctions différentes.

Configuration robots.txt : un exemple concret

Voici une configuration qui autorise les robots de réponse tout en bloquant les robots d’entraînement, adaptée à une PME qui vise la visibilité dans les réponses IA sans céder l’intégralité de son contenu à l’entraînement de modèles tiers :

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Disallow: /

Cette configuration illustre un arbitrage précis, pas une recommandation universelle : une PME qui vend un contenu à forte valeur documentaire peut préférer bloquer aussi les robots de réponse ; un média qui vit du trafic direct peut préférer tout autoriser.

Vérifier que vos directives sont respectées

Les grands opérateurs déclarent publiquement respecter le fichier robots.txt pour leurs robots nommés, mais rien n’empêche une erreur de configuration côté site ou un robot tiers qui usurpe un user-agent connu. Deux vérifications suffisent la plupart du temps : consulter les journaux d’accès du serveur pour confirmer que les IP correspondent aux plages publiées par l’opérateur, et tester la page avec l’outil d’inspection d’URL de Google Search Console pour confirmer qu’aucune règle involontaire ne bloque un robot légitime.

Un troisième contrôle, plus rarement pratiqué, consiste à interroger directement les moteurs de réponse sur son propre secteur, avec un petit jeu de questions représentatif (« quelle fiduciaire recommander à Genève », « quel cabinet d’architectes travaille en Suisse romande »), et à noter si le site apparaît. C’est la seule vérification qui mesure l’effet réel du calcul robots.txt plutôt que sa seule conformité déclarative. Un tableau de suivi mensuel, même sommaire, suffit à repérer une régression après un changement de configuration.

Quand ce calcul fin n’est pas le bon choix

La distinction robot par robot suppose du temps de maintenance et une veille sur les user-agents publiés par chaque opérateur. Deux cas justifient une approche plus radicale. D’abord, un site qui traite des données sous obligation de confidentialité contractuelle ou réglementaire (santé, finance, données clients) : bloquer tous les robots IA sans distinction reste la position la plus sûre, même au prix d’une invisibilité totale dans les réponses IA. Ensuite, un site éditorial qui vit du volume de citations et n’a aucun contenu sensible : tout autoriser, sans se soucier de la distinction entraînement/réponse, évite une maintenance disproportionnée par rapport à l’enjeu. Entre ces deux extrêmes, la majorité des PME romandes a intérêt au calcul fin décrit ici : ni le blocage réflexe qui sacrifie la visibilité IA sans bénéfice mesurable, ni l’ouverture totale qui cède un contenu propriétaire sans contrepartie.

Un dernier facteur pèse dans la décision : la taille de l’équipe qui maintiendra la configuration dans la durée. Une PME sans responsable technique dédié a plus intérêt à une règle simple, révisée une fois par an avec l’aide d’un prestataire, qu’à une matrice de dix robots mise à jour au fil de l’actualité. Le calcul fin décrit dans cet article reste un outil, pas une obligation : mieux vaut une configuration simple appliquée correctement qu’une configuration précise jamais tenue à jour.

La configuration du robots.txt reste un réglage technique parmi d’autres : elle ne remplace pas le travail de fond sur la structure des pages et les données vérifiables détaillé dans notre panorama des six leviers de la visibilité dans les moteurs de réponse IA. Le fichier robots.txt et le llms.txt répondent à deux questions différentes : le premier autorise ou bloque l’accès, le second résume le contenu pour les robots déjà autorisés à passer. Pour une PME qui veut savoir où elle se situe avant d’ajuster ses directives, le Sprint GEO part d’un audit concret. L’ensemble des articles du studio sur le sujet reste consultable sur le blog.