Comment configurer robots.txt pour les robots IA ?

« Faut-il bloquer les robots IA ? » n’a pas de réponse, parce que ce n’est pas une seule question. Chaque grande entreprise d’IA exploite des robots distincts pour des rôles distincts : les robots d’entraînement alimentent les corpus des modèles, les robots d’indexation de recherche alimentent les réponses qui vous citent, et les robots à la demande lisent une page parce qu’une personne vient d’interroger l’assistant à son sujet. Si vous les bloquez tous d’une seule ligne, vous ne prenez pas position sur l’entraînement des IA : vous vous retirez des réponses de l’IA.

Les coûts sont asymétriques. Bloquer un robot d’entraînement est un choix de principe qui, dans la plupart des cas, ne coûte aucune visibilité : Google et Apple le documentent explicitement, et pour OpenAI et Anthropic cela découle de la séparation des robots, puisque la recherche repose sur des agents distincts, aux conséquences documentées séparément. Bloquer un agent de recherche ou de consultation à la demande a un coût direct et documenté. OpenAI, par exemple, indique que les sites qui refusent OAI-SearchBot « ne seront pas affichés dans les réponses de recherche de ChatGPT ». Le fonctionnement propre à chaque assistant est détaillé dans nos guides pour être cité par ChatGPT, Claude et Perplexity ; cette page en donne la carte complète.

Deux chiffres cadrent l’échange. Cloudflare a mesuré combien de pages les entreprises d’IA explorent pour chaque visite qu’elles renvoient en retour : selon les données de Cloudflare Radar pour juin 2025, environ 1 700 explorations par visite renvoyée pour OpenAI et environ 70 900 pour Anthropic. Ces ratios baissent depuis (le tableau de bord AI Insights de Cloudflare les suit en direct), mais le principe de l’échange est clair : vous cédez une exploration intensive contre des citations. Le tableau ci-dessous sert à en fixer les termes.

Chaque ligne ci-dessous est vérifiée dans la documentation de l’opérateur lui-même, à jour d’août 2026. « Jeton » signifie que le nom ne fonctionne que comme groupe robots.txt : il n’existe pas de robot distinct avec ce user-agent.

Le tableau permet de définir trois politiques praticables.

Configuration 1 : priorité à la visibilité. Tout autoriser, explicitement : un groupe Allow par agent pour chaque robot documenté du tableau (tous sauf Bytespider, car un Allow pour un robot qui ignore le fichier n’est que du bruit), plus un groupe général. Elle convient aux sites qui vivent d’être trouvés et cités : entreprises de contenu, agences, la plupart des B2B. C’est ce que nous appliquons nous-mêmes ; voir « Comment nous gérons notre propre fichier » plus bas.

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

…et ainsi de suite pour chaque agent du tableau. Notre fichier de production sur get-geo.ai/robots.txt en est la version complète.

Configuration 2 : sans entraînement. Le choix délibéré le plus courant : rester hors des corpus des modèles, rester dans les réponses. Interdisez les robots d’entraînement et les jetons, autorisez le reste. Deux réserves avant de copier-coller : la ligne Bytespider est déclarative (la section suivante explique pourquoi), et retirer Meta-ExternalAgent est le seul refus d’entraînement qui a un coût en visibilité, puisqu’il vous sort aussi de l’index de Meta :

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: *
Allow: /

Configuration 3 : verrouillage. Légitime pour du contenu payant ou propriétaire. Robots.txt permet à plusieurs lignes User-agent de partager un même bloc de règles, ce qui garde l’ensemble compact. Nous laissons Applebot de côté ici, car le bloquer vous retire aussi de la recherche de Siri et de Spotlight, ce qui est une décision plus lourde que les réponses de l’IA :

User-agent: GPTBot

User-agent: OAI-SearchBot

User-agent: ChatGPT-User

User-agent: ClaudeBot

User-agent: Claude-SearchBot

User-agent: Claude-User

User-agent: PerplexityBot

User-agent: Perplexity-User

User-agent: Google-Extended

User-agent: Applebot-Extended

User-agent: Meta-ExternalAgent

User-agent: Meta-ExternalFetcher

User-agent: CCBot

User-agent: Amazonbot

User-agent: Amzn-SearchBot

User-agent: Amzn-User

User-agent: DuckAssistBot

User-agent: Bytespider
Disallow: /

Lisez la section suivante avant de déployer cette configuration : pour plusieurs des agents ci-dessus, le fichier est une demande, pas une barrière.

Robots.txt est une politique publiée, pas un mécanisme de contrainte, et pour toute une catégorie d’agents, les fournisseurs le disent eux-mêmes. OpenAI à propos de ChatGPT-User : « Comme ces actions sont initiées par un utilisateur, les règles robots.txt peuvent ne pas s’appliquer. » Meta à propos de Meta-ExternalFetcher : il « peut contourner robots.txt parce qu’il effectue des consultations demandées par l’utilisateur ». Le robot à la demande de Perplexity « ignore généralement les règles robots.txt ». Amazon à propos d’Amzn-User : il « peut ne pas suivre toutes les directives robots.txt ». La logique est cohérente : un humain a fait la demande, donc la consultation est traitée comme la visite de cet humain, et non comme une exploration.

Reste Bytespider, qui n’a aucune documentation et ignore le fichier dans les faits, d’après les mesures : Cloudflare l’a observé sur plus de sites protégés que tout autre robot IA (40,4 % à la mi-2024), et HAProxy lui attribue près de 90 % de son trafic de robots IA, en notant qu’il ignore les instructions de robots.txt.

L’application des règles se joue donc un cran plus bas. Vérifiez les robots avec les listes d’IP que la plupart des fournisseurs publient (OpenAI, Anthropic, Apple, Common Crawl et DuckDuckGo tiennent des listes JSON, Amazon publie ses plages sur sa page développeur), puis bloquez sur le CDN ou le WAF ce que vous voulez réellement arrêter. La vérification compte plus qu’il n’y paraît : HUMAN Security a mesuré qu’une requête sur dix-huit portant le user-agent d’un robot IA connu est usurpée.

Notre propre robots.txt suit la configuration priorité à la visibilité : dix-neuf groupes Allow explicites, un par agent (chaque agent du tableau qui respecte le fichier, les robots à la demande que nous accueillons de toute façon, et le Bingbot classique), suivis d’un Allow général. Nous l’avons remanié sous cette forme en août 2026, en supprimant dans la même opération l’ancien groupe anthropic-ai. En vérifiant les faits de ce guide, nous avons aussi retiré un groupe cohere-ai purement hypothétique : la documentation de Cohere indique qu’elle n’exploite actuellement aucun robot.

L’objection évidente : une seule ligne « User-agent: * / Allow: / » produirait le même comportement des robots. C’est vrai. Les groupes explicites apportent trois choses que la ligne unique n’apporte pas. Chaque fournisseur reçoit un signal d’intention sans ambiguïté, et non une simple absence d’objection. Les modifications futures sont plus sûres : un Disallow ajouté pour un agent ne peut pas s’appliquer en silence à des agents auxquels personne n’avait pensé. Enfin, le fichier sert aussi de liste de contrôle : quand un fournisseur lance un nouvel agent, comme OpenAI et Anthropic l’ont fait tous deux ces deux dernières années, l’écart se voit dans le fichier lui-même et dans nos journaux d’exploration.

Notre guide sur le GEO appliqué à notre propre site explique le dispositif d’ensemble. Un site éditorial avec des archives payantes pourrait plutôt choisir la configuration 2 ou 3. Quel que soit votre choix, relisez le fichier chaque trimestre : OpenAI a ajouté OAI-SearchBot en 2024, Anthropic a ajouté Claude-SearchBot en 2025, et Amazon avait scindé son exploration en trois agents dès 2026. Une politique rédigée en 2024 peut ne plus couvrir les robots concernés.