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 ?
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.
À 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.