Le robots.txt et le blocage au niveau serveur ne jouent pas le même rôle face à un robot. Le premier est une demande, déposée dans un fichier texte à la racine du site. Le second est une barrière technique, posée devant le serveur, que le robot ne peut pas franchir même s’il choisit de l’ignorer. Cette différence explique pourquoi tant de propriétaires de sites français ajoutent une ligne Disallow dans leur robots.txt contre GPTBot ou ClaudeBot, puis se demandent, quelques semaines plus tard, si ça suffit vraiment.
La question se pose parce que ces robots ont un usage bien précis : certains aspirent le contenu pour nourrir l’entraînement d’un modèle, d’autres servent à faire remonter une page dans une réponse de chatbot. Le calcul n’est pas neutre pour un site qui cherche aussi à apparaître dans les réponses de ChatGPT et les AI Overviews : bloquer un robot d’entraînement n’a pas les mêmes conséquences que bloquer un robot de recherche. Voici qui est qui, puis la grille de décision entre robots.txt et niveau serveur.
Table des matières
Les robots IA à connaître, nommément
Chez OpenAI, quatre user-agents se partagent le travail, d’après la documentation officielle. GPTBot aspire le contenu du site pour l’entraînement des futurs modèles : le bloquer dans le robots.txt revient à refuser d’y entrer. OAI-SearchBot, lui, indexe le web pour alimenter les réponses de recherche de ChatGPT, un rôle plus proche de Googlebot que de l’entraînement. OAI-AdsBot vérifie la sécurité des publicités affichées dans ChatGPT. Le quatrième, ChatGPT-User, se déclenche quand une personne demande explicitement à ChatGPT de consulter une page précise : OpenAI précise lui-même que les règles du robots.txt peuvent ne pas s’appliquer à ce trafic déclenché par un humain, puisqu’il ne s’agit pas d’un crawl automatique.
Anthropic suit une logique voisine avec trois robots, documentés sur son centre d’aide : ClaudeBot collecte du contenu pour entraîner les modèles Claude, Claude-SearchBot sert la qualité des résultats de recherche, et Claude-User relaie une action déclenchée par un utilisateur de Claude. Anthropic propose aussi une directive Crawl-delay pour ralentir ClaudeBot sans le bloquer complètement, utile quand le robot pèse sur les performances du serveur sans qu’on veuille l’exclure totalement.
Perplexity et Google complètent la liste. D’après la documentation de Perplexity, PerplexityBot ne sert pas à l’entraînement d’un modèle : il indexe le web pour faire remonter et lier des sites dans les réponses de Perplexity, un rôle proche d’un moteur de recherche classique. Google, de son côté, sépare Googlebot, l’indexation classique pour la recherche, de Google-Extended, un jeton dédié dans le robots.txt qui contrôle l’entraînement des futurs modèles Gemini et l’amélioration factuelle (le grounding) de Vertex AI. Google précise que ce jeton n’a pas de chaîne user-agent propre : le crawl reste assuré par les user-agents Google habituels.
- GPTBot (OpenAI) : entraînement des modèles
- OAI-SearchBot (OpenAI) : recherche dans ChatGPT
- OAI-AdsBot (OpenAI) : vérification des publicités ChatGPT
- ChatGPT-User (OpenAI) : consultation déclenchée par un utilisateur
- ClaudeBot (Anthropic) : entraînement des modèles Claude
- Claude-SearchBot (Anthropic) : recherche
- Claude-User (Anthropic) : action déclenchée par un utilisateur de Claude
- Google-Extended (Google) : jeton robots.txt (pas un user-agent distinct) pour l’entraînement Gemini et le grounding Vertex AI
- PerplexityBot (Perplexity) : indexation pour les réponses Perplexity
Robots.txt : une demande, pas une barrière
Le fichier robots.txt fonctionne sur la bonne foi. Un robot respectueux le lit, trouve la ligne Disallow en face de son user-agent, et renonce à crawler la page. Rien dans le protocole n’empêche un robot de l’ignorer purement et simplement, comme le rappelle Search Engine Journal dans une réponse consacrée précisément à cette question, Ask An SEO. Un crawler mal codé, ou un robot qui n’a jamais eu l’intention de respecter la règle, passe outre sans que le site en soit averti autrement qu’en lisant ses propres logs serveur. Le cas ChatGPT-User illustre bien la limite : parce qu’il s’agit d’une action déclenchée par une personne et non d’un crawl automatique, OpenAI indique lui-même que le robots.txt peut ne pas s’appliquer à ce trafic-là.
Niveau serveur : la barrière que le robot ne peut pas franchir
Le blocage au niveau serveur change de registre. Un pare-feu applicatif (WAF), un CDN ou une règle posée sur le serveur web coupe la connexion avant que le robot n’atteigne la moindre page, qu’il ait lu le robots.txt ou non. Search Engine Journal recommande une hiérarchie précise pour qui a le choix entre les trois : un WAF en priorité, un CDN si le WAF n’est pas disponible, le serveur web en dernier recours, chaque niveau agissant plus tôt dans la chaîne et se configurant plus simplement que le suivant.
Cloudflare illustre ce que peut donner un CDN sur ce terrain. Depuis le 3 juillet 2024, un simple interrupteur dans Security > Bots, intitulé « AI Scrapers and Crawlers », bloque les robots IA identifiés par son système de machine learning, y compris ceux qui falsifient leur user-agent pour se faire passer pour un navigateur classique, d’après l’annonce officielle de Cloudflare. Le réglage est disponible même sur l’offre gratuite. C’est ce type d’outil prêt à l’emploi qui rend le niveau serveur accessible sans écrire soi-même une règle Nginx ou Apache.
Pour qui préfère bloquer par adresse IP plutôt que par un réglage CDN, Anthropic et Perplexity publient chacun la liste des IP utilisées par leurs robots, à croiser avant de bannir une adresse au pare-feu : bots.json côté Anthropic, perplexitybot.json côté Perplexity. Bloquer à l’aveugle une plage IP qui n’appartient pas réellement au robot visé revient à fermer une porte au hasard, sans certitude que le bon robot soit derrière.
La grille de décision : rester au robots.txt ou basculer au niveau serveur
Entre les deux niveaux, le choix dépend moins d’une posture de principe que de deux éléments concrets : le robot en face, et ce que disent les logs du serveur. Le robots.txt suffit pour un robot réputé respectueux, à condition de surveiller les logs pour vérifier qu’il obéit vraiment, sachant que la visibilité dans les réponses IA pèse déjà sur le trafic classique, comme le montre la chute de CTR mesurée sur les pages exposées aux AI Overviews. GPTBot, ClaudeBot, OAI-SearchBot ou PerplexityBot ont un historique de conformité documenté par leurs éditeurs respectifs, et le coût de mise en place, une ligne de texte à la portée d’un non-développeur, reste imbattable.
Le niveau serveur devient nécessaire dans deux cas précis : quand les logs montrent qu’un robot continue de crawler malgré le Disallow, ou quand le contenu protégé a une valeur telle qu’une simple demande ne suffit plus à dormir tranquille : le catalogue tarifaire d’un artisan qui vend en direct, l’espace client d’un cabinet de conseil, ou les fiches produits qu’une boutique en ligne a mis des mois à rédiger. Google multiplie par ailleurs les réglages dédiés aux robots IA, du user-agent Google-Extended jusqu’au format qu’il propose désormais aux agents IA pour dialoguer avec un site autrement qu’en cliquant sur un lien, signe que la question déborde largement le seul robots.txt.
Le cas Google-Extended : bloquer l’entraînement sans perdre son classement
Un point rassure souvent les propriétaires de sites français hésitants : la documentation de Google confirme que bloquer Google-Extended n’a aucun effet sur le classement ni sur la présence du site dans la recherche Google, d’après la page officielle listant les robots de Google. Ce jeton ne pilote que l’entraînement des modèles Gemini et le grounding de Vertex AI, un usage séparé de Googlebot et de l’indexation classique — et puisqu’il ne correspond à aucune chaîne user-agent distincte (le crawl se fait avec les user-agents Google existants), il ne se gère qu’au niveau du robots.txt, pas par un filtrage user-agent côté serveur. Refuser Google-Extended, pour un site qui ne veut pas nourrir l’entraînement d’un modèle Google, ne coûte donc rien côté visibilité SEO classique.
Ce réglage rejoint les autres bases du SEO technique sur WordPress, aux côtés de la vitesse, du cache et des images : un fichier de plus à vérifier, pas un chantier à part. La bonne pratique reste la même que pour n’importe quel réglage technique : commencer simple, robots.txt et surveillance des logs, et ne monter au niveau serveur que lorsque les faits (un robot qui ignore la règle, un contenu trop sensible pour une simple demande) l’imposent réellement.
Crédit photo : Pixabay/MightyFineBros, Pixabay/cookieone, Pixabay/Tumisu.
