robots.txt et robots IA : la configuration complète, robot par robot

La plupart des sites que nous auditons ont un robots.txt écrit il y a cinq ans, complété depuis par des lignes copiées d’un forum. Le résultat est presque toujours le même : un robot de recherche IA bloqué par accident, un robot d’entraînement autorisé par inadvertance, et personne pour s’en apercevoir.

Cette procédure vous fait reprendre le fichier à zéro, en trois décisions.

Décision 1 : Séparer les finalités

Les robots des opérateurs de modèles ne font pas tous la même chose, et les mettre dans le même sac est l’erreur qui coûte le plus cher.

Recherche. Ces robots alimentent les réponses citées avec leurs sources. Les bloquer vous retire des citations. C’est la décision la plus chère de tout le fichier, et souvent celle qui est prise par défaut en copiant une liste de blocage trouvée en ligne.

Requête d’un utilisateur. Ces agents vont chercher une page précise parce qu’un humain vient de la demander. Le trafic est faible et intentionnel. Les bloquer revient à refuser de répondre à quelqu’un qui vous cherche.

Entraînement. Ces robots collectent du contenu pour entraîner des modèles. Les bloquer est un choix éditorial parfaitement légitime, et sans effet direct sur vos citations. C’est le seul cas où dire non ne vous coûte pas de visibilité.

Jetons de contrôle. Google-Extended et Applebot-Extended ne sont pas des robots : aucune requête ne porte ces noms. Ce sont des jetons que l’opérateur reconnaît dans robots.txt pour gouverner un usage : chez Google, l’usage des contenus par Gemini. Bloquer Google-Extended n’affecte pas votre présence dans les résultats de recherche ni dans les aperçus générés, qui dépendent de Googlebot. C’est la confusion la plus répandue du domaine.

Décision 2 : Choisir votre politique

Trois politiques cohérentes, à choisir selon ce que vous vendez.

Politique A : ouverte. Tout est autorisé. C’est le bon choix si votre contenu est un actif d’acquisition : documentation, guides, pages produit. Vous voulez être lu, cité et repris.

Politique B : recherche oui, entraînement non. Vous acceptez d’être cité, vous refusez d’alimenter l’entraînement. C’est la position la plus fréquente chez les éditeurs et les médias.

Politique C : fermée. Vous refusez tout. Assumez la conséquence : vous disparaissez des réponses citées. C’est un choix défendable pour un intranet ou un site sous contrainte contractuelle ; c’en est rarement un pour un site commercial.

Décision 3 : Écrire le fichier

Voici la politique B, la plus courante. Adaptez en déplaçant les jetons d’un bloc à l’autre.

# Recherche et requêtes utilisateur : autorisés
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Amzn-SearchBot
User-agent: DuckAssistBot
User-agent: MistralAI-User
Allow: /

# Entraînement : refusés
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Bytespider
User-agent: meta-externalagent
User-agent: Amazonbot
Disallow: /

# Jetons de contrôle : refus d'usage, sans effet sur l'exploration
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /

# Tout le reste
User-agent: *
Allow: /

Sitemap: https://exemple.fr/sitemap.xml

Les quatre erreurs que nous rencontrons

1. Croire que les groupes se cumulent

Ils ne se cumulent pas. Un robot applique un seul groupe : le plus spécifique qui le nomme. Si vous écrivez un User-agent: * avec cinq Disallow de répertoires techniques, puis un groupe GPTBot avec un seul Disallow: /private, GPTBot n’applique pas les cinq premiers.

Conséquence pratique : dès que vous nommez un robot, son groupe doit être complet.

2. Bloquer Google-Extended en croyant sortir des aperçus IA

Les aperçus générés de Google s’appuient sur Googlebot. Google-Extended gouverne un autre usage. Ce blocage-là ne change rien à ce que vous croyez viser, et retire ce que vous ne visiez pas.

3. Compter sur robots.txt contre un agent qui l’ignore

Certains fetchers déclenchés par un utilisateur ne l’appliquent pas, par conception. Si vous devez réellement les arrêter, cela se joue côté serveur, et pas sur l’agent utilisateur seul, qui est déclaratif et falsifiable. Un blocage fondé sur cette seule chaîne arrête les robots honnêtes et personne d’autre.

4. Servir un robots.txt en 4xx

C’est le défaut le plus silencieux de la liste, et nous l’avons rencontré sur notre propre site. Un serveur web peut revendiquer le chemin /robots.txt avant votre application, répondre 404, et laisser une page d’erreur être rendue à la place. Le fichier « existe », votre framework le déclare, et les robots lisent aucune règle, et ignorent la directive Sitemap: qu’il portait.

Le contrôle qui tire : demandez l’URL et regardez le code de statut, pas seulement le corps de la réponse.

Vérifier

Trois contrôles, dans cet ordre :

1. curl -sI https://votre-domaine/robots.txt → statut 200, type text/plain.
2. Relisez chaque groupe en vous demandant : ce robot applique-t-il ce groupe et lui seul ?
3. Vérifiez que votre directive Sitemap: pointe une URL qui répond.

Le reste (savoir lesquels arrivent réellement jusqu’à vos pages, et si votre marque est citée dans les réponses) demande un relevé actif. Mais aucun relevé ne rattrapera un fichier qui bloque ce que vous vouliez autoriser.