Taxonomie des bots
Better Robots.txt fonctionne mieux lorsque les visiteurs machine sont séparés par rôle, et non seulement par marque ou par chaîne de user-agent.
C’est la seule manière stable de publier une politique sans rabattre des modes d’accès très différents dans une seule catégorie floue de « bot IA ».
Pourquoi la taxonomie doit évoluer
Une taxonomie plate suffisait encore lorsque la plupart des sites devaient surtout distinguer :
- les bots de recherche ;
- tout le reste.
Ce n’est plus suffisant.
Une taxonomie utile doit désormais distinguer non seulement qui visite, mais aussi :
- pourquoi la visite a lieu ;
- si le trafic est automatique ou déclenché par l’utilisateur ;
- quelle surface de contrôle gouverne réellement la décision.
Sans cela, les équipes commettent des erreurs de catégorie.
Elles bloquent le Search alors qu’elles voulaient seulement refuser l’entraînement.
Elles publient des règles robots.txt pour un trafic qui relève en réalité de l’edge.
Elles traitent la récupération pour réponse et l’entraînement comme s’il s’agissait du même usage.
Catégories principales
Les crawlers de recherche
Ces bots servent la découverte, l’indexation et le rafraîchissement dans des produits de recherche.
Question typique : veut-on rester découvrable là où ces systèmes peuvent encore renvoyer du trafic ?
Les crawlers ou tokens d’entraînement
Ces surfaces servent le développement futur des modèles, et non la visibilité directe en recherche.
Question typique : veut-on que le contenu serve à entraîner ou améliorer de futurs systèmes génératifs ?
Les systèmes de réponse ou de récupération
Ces systèmes soutiennent la génération de réponses, la récupération, le grounding, ou la qualité des réponses de recherche.
Question typique : veut-on que le contenu soit tiré dans des pipelines de réponse ou de récupération ?
Les fetchers déclenchés par l’utilisateur
Ces requêtes existent parce qu’un utilisateur final a demandé à un produit de visiter, récupérer, ou agir sur une URL.
Question typique : s’agit-il encore d’une décision normale de crawl, ou faut-il la gouverner différemment parce que l’accès est initié par un humain ?
Better Robots.txt traite cette classe séparément des crawlers de recherche IA. Un blocage général de recherche IA ne doit pas être lu comme une garantie que les fetchers déclenchés par l’utilisateur sont bloqués. Selon le fournisseur, ces requêtes peuvent exiger une analyse de logs, des règles WAF, une vérification d’IP ou un traitement propre au fournisseur au-delà de robots.txt.
Les agents signés ou vérifiés
Ces agents peuvent être vérifiés ou allowlistés au niveau du CDN, du WAF, ou de l’infrastructure.
Question typique : le vrai problème de contrôle porte-t-il maintenant sur l’identité, la vérification, et les permissions runtime plutôt que sur la seule politique publique de crawl ?
Les bots d’archive
Ces bots capturent ou rejouent le contenu à des fins de préservation ou d’accès historique.
Question typique : la capture d’archive est-elle acceptable, neutre, ou indésirable pour ce profil de site ?
Les bots d’outils SEO
Ces bots crawlent pour la recherche SEO, le monitoring, et l’intelligence concurrentielle.
Question typique : la valeur créée justifie-t-elle la charge de crawl et l’exposition extractive ?
Les bots de faible valeur ou abusifs
Ces bots créent du coût, de la pression extractive, ou du bruit sans valeur significative pour le site.
Question typique : faut-il traiter cela comme un sujet de politique de crawl, ou comme un sujet d’abus à gérer en infrastructure ?
Dimensions secondaires de décision
Une taxonomie forte doit aussi intégrer les dimensions suivantes.
Valeur de découverte
Ce visiteur machine aide-t-il le site à apparaitre là où il veut réellement être trouvé ?
Risque de réutilisation ou d’extraction
Augmente-t-il le risque d’extraction de faible retour ou de réutilisation aval non souhaitée ?
Mode de déclenchement
L’accès est-il automatique, déclenché par l’utilisateur, mixte, ou incertain ?
Surface de contrôle principale
La décision est-elle principalement gouvernée par :
robots.txt- des signaux d’usage
llms.txt- des contrôles Search à la page
- des contrôles d’infrastructure ou d’edge
Vérifiabilité
La requête peut-elle être vérifiée de façon fiable, ou ne repose-t-elle que sur une chaîne user-agent déclarative ?
Coût d’infrastructure
Le trafic crée-t-il un coût significatif côté serveur, crawl, ou opérations ?
Réversibilité
Le site peut-il modifier cette décision plus tard sans dommage majeur de visibilité ?
Un même fournisseur peut couvrir plusieurs catégories
C’est la règle opérationnelle la plus importante de la taxonomie.
Il ne faut jamais présumer qu’un fournisseur correspond à une seule catégorie.
Exemples :
- Google peut relever du Search, du contrôle d’usage aval, et du trafic agentique déclenché par l’utilisateur.
- OpenAI peut relever de la recherche, de l’entraînement, de la visite déclenchée par l’utilisateur, et de l’agent signé.
- Anthropic peut relever de l’entraînement, de l’optimisation de recherche, et de la récupération dirigée par l’utilisateur.
- Apple peut relever du crawl Search et du contrôle d’usage aval des données.
C’est pourquoi la taxonomie classe les rôles d’abord et les noms ensuite.
Comment les modèles s’articulent : huit catégories, quatre familles, trois contrôles
La même réalité se décrit à trois résolutions. Elles s’emboitent ; elles ne s’opposent pas.
- Huit catégories de rôle forment le modèle machine canonique, publié dans
/bot-taxonomy.json. Chaque user-agent documenté correspond à exactement une catégorie dans le registre machine/bot-registry.json. - Quatre familles pratiques sont le résumé destiné aux humains, utilisé dans le paysage des crawlers IA : les crawlers de recherche, les crawlers ou tokens d’entraînement, les systèmes de réponse ou de récupération, et les agents déclenchés par l’utilisateur ou signés.
- Trois contrôles opérationnels sont les choix qu’un site publie dans
robots.txt: entraînement IA, recherche et découverte IA, et accès déclenché par l’utilisateur.
Les trois contrôles se résolvent directement sur les huit catégories :
- L’entraînement IA gouverne
training_crawlers_or_tokens. - La recherche et découverte IA gouverne
search_crawlersavecanswer_or_retrieval_systems. - L’accès déclenché par l’utilisateur gouverne
user_triggered_fetchers.
Les quatre catégories restantes, agents signés ou vérifiés, bots d’archive, bots d’outils SEO, et bots de faible valeur ou abusifs, se gouvernent au niveau infrastructure (allowlisting CDN, règles WAF, limites de débit), et non par les contrôles robots.txt.
Les user-agents par catégorie
Ce tableau associe chaque user-agent documenté à une catégorie canonique et au contrôle opérationnel qui le gouverne. C’est la vue lisible de /bot-registry.json, où chaque entrée porte aussi son URL de source fournisseur et son statut de documentation. Les classements suivent la documentation propre à chaque fournisseur ; un même user-agent peut couvrir plusieurs rôles dans le temps.
| User-agent | Fournisseur | Catégorie | Contrôle | Statut |
|---|---|---|---|---|
GPTBot | OpenAI | Crawlers ou tokens d’entraînement | Entraînement IA | Documenté |
OAI-SearchBot | OpenAI | Crawlers de recherche | Recherche et découverte IA | Documenté |
ChatGPT-User | OpenAI | Fetchers déclenchés par l’utilisateur | Accès déclenché par l’utilisateur | Documenté |
OAI-AdsBot | OpenAI | Fetchers déclenchés par l’utilisateur | Accès déclenché par l’utilisateur | Documenté |
ClaudeBot | Anthropic | Crawlers ou tokens d’entraînement | Entraînement IA | Documenté |
Claude-SearchBot | Anthropic | Crawlers de recherche | Recherche et découverte IA | Documenté |
Claude-User | Anthropic | Fetchers déclenchés par l’utilisateur | Accès déclenché par l’utilisateur | Documenté |
anthropic-ai | Anthropic | Crawlers ou tokens d’entraînement | Entraînement IA | Hérité |
Claude-Web | Anthropic | Systèmes de réponse ou de récupération | Recherche et découverte IA | Hérité |
PerplexityBot | Perplexity | Crawlers de recherche | Recherche et découverte IA | Documenté |
Perplexity-User | Perplexity | Fetchers déclenchés par l’utilisateur | Accès déclenché par l’utilisateur | Documenté |
Googlebot | Crawlers de recherche | Recherche et découverte IA | Documenté | |
Google-Extended | Crawlers ou tokens d’entraînement | Entraînement IA | Documenté | |
Applebot | Apple | Crawlers de recherche | Recherche et découverte IA | Documenté |
Applebot-Extended | Apple | Crawlers ou tokens d’entraînement | Entraînement IA | Documenté |
CCBot | Common Crawl | Crawlers ou tokens d’entraînement | Entraînement IA | Documenté |
AI2Bot | Ai2 | Crawlers ou tokens d’entraînement | Entraînement IA | Documenté |
Bytespider | ByteDance | Bots de faible valeur ou abusifs | Niveau infrastructure | Non spécifié publiquement |
Google-Extended et Applebot-Extended sont des tokens de contrôle, pas des fetchers distincts : ils ne portent aucune chaîne user-agent propre et gouvernent seulement l’usage pour l’entraînement de données déjà crawlées. Bytespider est classé parmi les bots de faible valeur ou abusifs parce qu’il est largement observé comme ignorant robots.txt ; gouvernez-le au niveau infrastructure plutôt que par robots.txt seul.
À quoi sert cette taxonomie
Cette taxonomie aide les équipes à :
- séparer les décisions de politique avant publication ;
- éviter de mélanger Search, entraînement, récupération, et trafic déclenché par l’utilisateur ;
- choisir la bonne surface de contrôle ;
- réduire les contradictions entre sorties de gouvernance.
Ce que cette taxonomie ne prouve pas
Cette taxonomie ne prouve pas :
- la conformité effective des crawlers ;
- l’enforcement technique ;
- un effet juridique à elle seule ;
- l’état runtime réel ;
- l’authenticité d’un user-agent déclaré.
C’est une couche de classification de gouvernance. C’est sa fonction.