SEO & GEO

Robots IA : qui explore votre site, et comment reprendre la main

Publié le 26 septembre 2026 · 14 min de lecture

La question n’est plus de savoir s’il faut bloquer les robots d’IA, mais lesquels, pour quelle finalité, et avec quel mécanisme. Un même éditeur exploite souvent trois robots distincts : un qui collecte pour entraîner, un qui indexe pour répondre, un qui va chercher une page parce qu’un utilisateur l’a demandé. Les confondre revient à se couper d’un trafic réel en croyant protéger son contenu.

Ce guide donne l’inventaire à jour, les mécanismes disponibles avec leur efficacité réelle, et quatre postures cohérentes selon ce que vous cherchez à obtenir. Les user-agents cités proviennent des documentations des éditeurs et sont à recopier tels quels.

Ce que couvre ce guide

Qui explore réellement votre site, avec les jetons exacts et la finalité déclarée de chacun.
Ce que robots.txt permet, ce qu’il ne permet pas, et la portée juridique nouvelle qu’il a acquise.
Le piège de Google-Extended, et le contrôle qui répond vraiment à la question depuis juin 2026.
llms.txt : ce que disent les mesures disponibles sur son utilité.
Les mécanismes en cours de normalisation, et celui déjà déployé à grande échelle.
Quatre postures, avec la configuration correspondante.

Trois finalités, pas une

Avant l’inventaire, la distinction qui structure tout le sujet.

L’entraînement. Le robot collecte pour constituer un corpus qui servira à fabriquer un modèle. Il ne vous renvoie aucun visiteur, ni aujourd’hui ni demain.
L’indexation pour la réponse. Le robot constitue un index consulté au moment où un utilisateur pose une question. C’est ce qui permet à votre site d’être cité, avec un lien.
La récupération à la demande. Une personne colle votre URL dans un assistant, qui va lire la page. C’est un visiteur, pas un robot d’exploration.

Bloquer tout ce qui porte le mot « IA » dans son nom revient à supprimer les deux dernières catégories en même temps que la première. Les mesures publiées par Cloudflare sur juillet 2025 situaient l’entraînement à environ 79 % du volume d’exploration des robots d’IA, la recherche à 17 % et les actions utilisateur à un peu plus de 3 %. L’essentiel du volume est donc séparable de ce qui vous rapporte.

L’inventaire, par éditeur

Jeton robots.txt	Éditeur	Finalité déclarée
`GPTBot`	OpenAI	Entraînement des modèles
`OAI-SearchBot`	OpenAI	Indexation pour la recherche dans ChatGPT
`ChatGPT-User`	OpenAI	Action déclenchée par un utilisateur
`OAI-AdsBot`	OpenAI	Vérification des pages soumises en publicité
`ClaudeBot`	Anthropic	Entraînement des modèles
`Claude-SearchBot`	Anthropic	Qualité des résultats de recherche
`Claude-User`	Anthropic	Accès web à l’initiative de l’utilisateur
`Googlebot`	Google	Search, Discover, Images, Video, News
`Google-Extended`	Google	Entraînement Gemini et ancrage Vertex AI
`Google-CloudVertexBot`	Google	Exploration demandée par le propriétaire du site
`PerplexityBot`	Perplexity	Indexation pour la recherche
`Perplexity-User`	Perplexity	Visite à la demande d’un utilisateur
`meta-externalagent`	Meta	Entraînement et indexation
`meta-externalfetcher`	Meta	Récupération à la demande
`Applebot`	Apple	Recherche et services Apple
`Applebot-Extended`	Apple	Entraînement des modèles Apple
`Amazonbot`	Amazon	Produits et services, peut servir à l’entraînement
`CCBot`	Common Crawl	Corpus web ouvert, réutilisé par des tiers

Jetons à employer dans robots.txt, d’après les documentations des éditeurs. Les numéros de version des chaînes user-agent évoluent, les jetons sont stables.

Deux remarques utiles. Cohere déclare expressément ne pas exploiter de robot pour collecter du contenu destiné à l’entraînement de modèles génératifs à ce jour. À l’inverse, plusieurs robots dont on mesure le trafic, notamment ceux de ByteDance et de Mistral, ne disposent d’aucune documentation publique d’éditeur : les jetons qui circulent à leur sujet proviennent d’annuaires tiers et doivent être traités comme tels.

Ce que robots.txt peut, et ce qu’il ne peut pas

Le protocole est normalisé depuis la RFC 9309, publiée en septembre 2022. Deux phrases du texte méritent d’être connues avant toute décision : ces règles ne constituent pas une forme d’autorisation d’accès, et le protocole d’exclusion des robots ne remplace pas des mesures de sécurité valides. Un chemin listé dans robots.txt devient d’ailleurs publiquement découvrable : ce n’est pas l’endroit où mentionner une zone sensible.

Ce constat a changé de portée en Europe. L’article 53 du règlement sur l’IA oblige les fournisseurs de modèles à usage général à identifier et respecter les réserves de droits exprimées au titre de l’exception de fouille de textes et de données, y compris par des technologies de pointe. Le code de bonnes pratiques associé demande explicitement aux signataires de respecter robots.txt. Un Disallow visant un robot d’entraînement vaut désormais réserve de droits opposable, ce qui n’était pas le cas avant.

Reste la question du respect effectif. Le cas le plus documenté oppose Cloudflare à Perplexity en août 2025. Cloudflare affirme avoir créé des domaines de test neufs, jamais indexés, avec un robots.txt interdisant tout, et avoir néanmoins obtenu de Perplexity la restitution de leur contenu ; l’entreprise décrit une rotation d’adresses et de numéros d’autonomie en réponse aux directives restrictives, et a retiré Perplexity de sa liste de robots vérifiés. Perplexity conteste l’attribution du trafic incriminé et défend la distinction entre un agent piloté par un utilisateur et un robot d’indexation. Les deux versions sont publiées, elles sont contradictoires sur les faits techniques, et aucune juridiction ne les a tranchées.

Un point n’est pas contesté, en revanche, parce qu’il est documenté par l’éditeur lui-même : Perplexity indique que son agent Perplexity-User, dès lors qu’une requête vient d’un utilisateur, ignore généralement les règles de robots.txt. Meta documente une position voisine pour meta-externalfetcher. La logique est assumée : un agent qui agit pour le compte d’une personne est traité comme cette personne, pas comme un robot.

Google-Extended : le piège, et la vraie réponse

Beaucoup de sites ont ajouté un Disallow sur Google-Extended en croyant sortir des réponses génératives de Google. Ce n’est pas ce qu’il fait.

Google indique que Google-Extended n’a pas de chaîne user-agent propre : l’exploration reste effectuée par Googlebot. Le bloquer ne réduit donc aucun trafic robot. Google précise également qu’il n’affecte pas l’inclusion du site dans la recherche et n’est pas un signal de classement. Son périmètre est l’entraînement des futurs modèles et l’ancrage dans les applications Gemini et Vertex AI. Il ne pilote ni les AI Overviews ni le mode IA, qui s’alimentent à l’index de Search.

La réponse existe depuis 2026, et c’est le changement le plus important de l’année pour un éditeur. Google a annoncé en juin 2026 un contrôle dédié, disponible mondialement, accessible dans les paramètres de la Search Console. Il permet de décider si le site apparaît dans les fonctionnalités génératives de la recherche, AI Overviews, mode IA et fonctionnalités génératives dans Discover. Google précise que les sites qui s’en retirent ne recevront ni trafic ni impressions de ces fonctionnalités, et que ce réglage n’est pas utilisé comme signal de classement pour le reste de la recherche. Le réglage est hérité par défaut des propriétés parentes, se propage généralement en un à deux jours, et la valeur par défaut est l’inclusion.

Le compromis reste réel : sortir des réponses génératives, c’est renoncer aux impressions qu’elles produisent. Mais l’arbitrage se fait désormais explicitement, sur un réglage documenté, au lieu de reposer sur une directive robots.txt qui ne faisait pas ce qu’on croyait.

Les balises, pour un réglage plus fin

Google documente l’effet de trois directives sur ses fonctionnalités génératives. nosnippet empêche également l’utilisation du contenu comme entrée directe des AI Overviews et du mode IA. max-snippet limite dans les mêmes proportions la part du contenu utilisable. data-nosnippet applique la même logique au niveau d’un bloc de texte, ce qui permet d’exclure un paragraphe précis sans toucher au reste de la page. Toutes s’expriment aussi en en-tête HTTP via X-Robots-Tag.

Deux balises à ne pas recommander : noai et noimageai. Aucun grand éditeur ne documente les respecter, et une étude de 2024 ne recensait que quatre-vingt-deux hôtes les employant sur environ 1,4 million analysés. Le protocole de réserve de droits du W3C, qui s’exprime via un fichier /.well-known/tdmrep.json, est mieux aligné sur le droit européen mais reste tout aussi marginal en adoption.

llms.txt : ce que disent les mesures

La proposition vient de Jeremy Howard, en septembre 2024 : un fichier Markdown à la racine, qui présente le site et pointe vers ses contenus principaux, pour aider un modèle à s’y repérer. L’idée est séduisante et la spécification tient en une page. Elle n’est adossée à aucun organisme de normalisation.

Les faits disponibles sont les suivants. John Mueller, chez Google, a déclaré en juin 2025 qu’aucun système d’IA n’utilisait alors llms.txt. Une étude Ahrefs publiée en juin 2026, portant sur 137 210 domaines, relève que 28 % d’entre eux publient un tel fichier, et que 97 % de ces fichiers n’ont reçu aucune requête du tout au cours du mois observé. Sur le reliquat, les robots d’IA nommés représentent moins d’un cinquième des requêtes, derrière les outils d’audit SEO.

Conclusion praticable : publier un llms.txt ne coûte rien et ne fait aucun mal, mais ce n’est pas un levier. Le présenter comme une prestation de visibilité sur les moteurs génératifs n’est pas sérieux en l’état des mesures.

Les mécanismes qui montent

Content Signals, déjà déployé

Cloudflare a publié en septembre 2025 une syntaxe qui s’écrit dans robots.txt et distingue trois usages plutôt que l’accès :

Content-Signal: search=yes, ai-train=no

Les trois signaux sont search pour l’indexation et les extraits, ai-input pour l’alimentation d’un modèle au moment de la réponse, et ai-train pour l’entraînement. Cloudflare a déployé cette ligne par défaut sur son robots.txt géré, avec plus de 3,8 millions de domaines concernés dès l’annonce, en laissant volontairement ai-input non renseigné pour ne pas présumer de la préférence du propriétaire.

AIPREF, en cours de normalisation

L’IETF a constitué un groupe de travail dédié à l’expression des préférences d’usage pour l’IA. Le vocabulaire en cours définit trois catégories : train-ai pour la modification des paramètres d’un modèle, ai-use pour l’usage d’un contenu comme entrée d’un modèle, search pour la sélection et le renvoi vers la source. L’attachement se fait par un en-tête HTTP Content-Usage ou par une directive du même nom dans robots.txt.

Le principe directeur est le bon : séparer l’accessibilité, exprimée par Allow et Disallow, de la préférence d’usage. Attention toutefois, Content-Signal et Content-Usage sont deux syntaxes concurrentes qui ne sont pas interchangeables.

Le blocage et la facturation au niveau du CDN

Cloudflare a fait évoluer sa position par étapes : blocage en un clic en septembre 2024, choix proposé à l’inscription pour les nouveaux domaines en juillet 2025, mise à disposition générale d’AI Crawl Control en août 2025, puis trois catégories indépendantes en juillet 2026, Search, Agent et Training, chacune avec trois choix. Depuis septembre 2026, les nouveaux domaines bloquent par défaut les robots classés Training ou Agent sur les pages affichant de la publicité.

Une chausse-trape technique mérite d’être signalée : bloquer la catégorie Training bloque aussi les robots multi-usages, Googlebot et Applebot compris, puisque la règle la plus restrictive l’emporte. Cloudflare a introduit en septembre 2026 un réglage permettant de refuser l’entraînement tout en restant visible en recherche, avec une liste d’opérateurs qui s’engagent à respecter cette séparation.

La facturation à l’exploration existe, en bêta : le serveur répond HTTP 402 Payment Required avec un en-tête de prix, le robot accepte ou annonce son prix plafond, et l’authentification passe par des signatures cryptographiques. C’est une piste à suivre, pas une source de revenu à inscrire au budget.

Quatre postures cohérentes

Il n’y a pas de bonne réponse universelle. Il y a quatre positions défendables, et il faut en choisir une plutôt que de mélanger les trois premières.

Posture 1 : tout ouvert

Pour un site dont le contenu est un outil d’acquisition et non un actif vendu. Vous cherchez la citation, partout. Ne bloquez rien, surveillez simplement la charge serveur. C’est la position par défaut, et elle est rationnelle pour la majorité des sites de PME.

Posture 2 : visible, mais pas entraînable

La plus courante chez les éditeurs de contenu. Vous acceptez d’être cité avec un lien, vous refusez d’alimenter un corpus d’entraînement. Concrètement :

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: *
Disallow:

Sitemap: https://votre-domaine.fr/sitemap_index.xml

Les robots d’indexation, OAI-SearchBot, Claude-SearchBot, PerplexityBot, restent autorisés par la règle générale. C’est volontaire : ce sont eux qui vous apportent des liens. La dernière ligne des groupes spécifiques doit être vérifiée sous-domaine par sous-domaine, un robots.txt ne vaut que pour son hôte.

Posture 3 : ni entraînement, ni réponse générative

Pour un site dont le modèle économique repose sur la visite. À la configuration précédente s’ajoutent le contrôle dédié de la Search Console pour sortir des fonctionnalités génératives de Google, et le blocage des robots d’indexation des assistants. Mesurez avant et après : vous renoncez à des impressions, l’arbitrage doit se prendre sur des chiffres.

Posture 4 : la négociation

Pour un catalogue de contenu qui a une valeur marchande. Blocage par défaut au niveau du CDN, réponse 402 avec vos coordonnées de licence, et discussion commerciale au cas par cas. Cela suppose un volume de contenu qui justifie l’effort, et des interlocuteurs prêts à payer.

Erreurs fréquentes

Bloquer Google-Extended en croyant sortir des AI Overviews. Ce sont deux mécanismes sans rapport.
Bloquer GPTBot et croire avoir bloqué OpenAI. OAI-SearchBot et ChatGPT-User continuent, et c’est heureux.
Bloquer les agents pilotés par un utilisateur. Ce sont vos visiteurs, avec un intervalle de temps proche de zéro entre l’intérêt et la lecture.
Recopier un robots.txt trouvé en ligne sans vérifier les jetons. Un jeton mal orthographié ne bloque rien et ne prévient personne.
Compter sur robots.txt pour protéger une zone sensible. La RFC dit l’inverse en toutes lettres.
Publier un llms.txt et le présenter comme une action de visibilité. Les mesures disponibles ne le soutiennent pas.
Oublier les sous-domaines. Chaque hôte a son propre robots.txt.

Mesurer, plutôt que supposer

Le rapport entre le nombre de pages explorées et le nombre de visiteurs renvoyés est l’indicateur qui éclaire la décision. Les mesures publiées par Cloudflare sur juillet 2025 donnent des ordres de grandeur éloquents : environ 38 000 pages explorées pour un visiteur côté Anthropic, un peu plus de mille côté OpenAI, moins de deux cents côté Perplexity, et cinq côté Google. Ces valeurs bougent beaucoup d’une semaine à l’autre et ne valent que pour leur date de mesure : à ne pas citer comme des constantes.

Sur votre propre site, le calcul se fait dans les journaux du serveur. Comptez les requêtes par user-agent sur trente jours, comptez les sessions référées par les assistants, et divisez. Vous saurez alors lequel de ces robots vous coûte de la bande passante sans contrepartie, et lequel vous amène des lecteurs.

Questions fréquentes

Bloquer les robots d’entraînement nuit-il au référencement ?

Google indique expressément que Google-Extended n’est pas un signal de classement et n’affecte pas l’inclusion dans la recherche. Pour les autres éditeurs, le robot d’entraînement est distinct du robot d’indexation, donc le blocage de l’un n’affecte pas l’autre.

Combien de sites bloquent réellement ?

Cloudflare mesurait en juin 2025 qu’environ 14 % des domaines les plus visités comportaient une directive visant explicitement un robot d’IA. En septembre 2026, l’entreprise indique que 17 % des propriétaires restreignent l’entraînement. C’est une minorité active, pas une pratique générale.

Un robot peut-il ignorer mon robots.txt ?

Techniquement oui, le fichier n’est pas un contrôle d’accès. Deux éditeurs documentent même le fait que leur agent à la demande ne le respecte généralement pas. Si vous voulez un blocage effectif, il passe par le serveur ou le CDN, pas par un fichier texte.

Faut-il bloquer par adresse IP ?

Les éditeurs publient leurs plages et les mettent à jour, ce qui suppose une synchronisation régulière de votre côté. Plusieurs le déconseillent pour cette raison. La vérification par résolution DNS inverse est plus robuste, et les signatures cryptographiques en cours de déploiement règleront le sujet à terme.

Le blocage a-t-il un effet rétroactif ?

Non. Ce qui a déjà été collecté l’est. Une réserve de droits vaut pour l’avenir, et sa valeur juridique en Europe repose sur l’obligation faite aux fournisseurs de modèles de la respecter, pas sur un effacement de corpus.

Un test à faire aujourd’hui

Ouvrez votre robots.txt dans un navigateur. S’il ne mentionne aucun des jetons du tableau ci-dessus, vous êtes en posture 1 sans l’avoir choisi. S’il mentionne Google-Extended et rien d’autre, vous êtes dans le cas le plus fréquent : une directive qui ne fait pas ce que vous pensiez. Dans les deux cas, la décision prend dix minutes une fois la posture arrêtée.