robots.txt, llms.txt et WebMCP
L’accès machine moderne n’est pas un seul problème. C’est une pile de surfaces de contrôle différentes.
Pour les équipes WordPress, l’erreur la plus fréquente consiste à réduire chaque nouvelle question IA ou agentique à un seul fichier. Cela mène à de mauvaises décisions :
- utiliser
robots.txtcomme s’il décrivait tous les usages IA ; - utiliser
llms.txtcomme s’il pouvait forcer le comportement des crawlers ; - traiter les surfaces de type WebMCP comme de simples directives de crawl ;
- supposer qu’une politique IA publique prouve la conformité runtime ;
- supposer qu’une vérification Lighthouse certifie toute la préparation agentique.
Le modèle plus sûr consiste à séparer les couches.
Version courte
| Surface | Rôle principal | Bon usage | Mauvais usage |
|---|---|---|---|
robots.txt | Guidage d’accès au crawl | Indiquer aux crawlers quels chemins devraient ou ne devraient pas être récupérés | Le traiter comme contrôle d’indexation, licence, entraînement ou enforcement runtime |
llms.txt | Orientation lisible par machine | Résumer le site et router vers les pages sources prioritaires | Le traiter comme facteur de classement, blocage crawler ou remplacement du sitemap |
Content-Signal | Préférence d’usage post-crawl | Déclarer la posture search, ai-input et ai-train dans robots.txt | Le traiter comme blocage d’accès ou enforcement garanti |
| Politique d’usage IA | Couche d’interprétation publique | Expliquer les usages acceptés, les limites et la préséance des sources | La traiter comme enforcement technique dur |
| Fichiers de gouvernance | Pile de politique lisible par machine | Clarifier la préséance, l’ambiguïté et les limites de réponse | Laisser tous les fichiers parler avec la même autorité |
| Surfaces type WebMCP | Interaction agentique et usage d’outils | Donner aux agents des façons structurées d’interagir avec des capacités du site | Les traiter comme équivalentes à robots.txt ou llms.txt |
| Edge et WAF | Enforcement runtime | Vérifier, bloquer, allowlister ou limiter le trafic | Attendre de fichiers WordPress qu’ils forcent l’identité |
Chaque couche compte. Aucune ne doit prétendre être tout le système.
robots.txt : accès au crawl, pas gouvernance machine complète
robots.txt reste le premier fichier de politique de crawl public que plusieurs bots inspectent. Il est utile pour :
- les directives allow/disallow par chemin ;
- la segmentation par familles de crawlers ;
- la déclaration des sitemaps ;
- l’hygiène de crawl WordPress ;
- la réduction des récupérations de faible valeur ;
- le maintien de Search ouvert tout en restreignant certains crawlers IA.
Mais robots.txt n’est pas une politique complète d’usage machine.
Il n’exprime pas de manière fiable :
- si le contenu peut être utilisé pour entraîner un modèle ;
- si un agent déclenché par l’utilisateur peut récupérer une page ;
- si un système peut citer ou résumer un passage ;
- comment résoudre des affirmations contradictoires du site ;
- quelle page est la source canonique d’un sujet ;
- si un visiteur runtime est un agent vérifié.
C’est pourquoi Better Robots.txt traite robots.txt comme couche de base, pas comme toute la pile de politique.
llms.txt : orientation, pas enforcement
llms.txt est une couche de résumé lisible par machine.
Il peut aider un lecteur machine à comprendre :
- ce qu’est le site ;
- quelles pages sont principales ;
- quelles politiques existent ;
- quelles pages de support comptent ;
- quelles pages sources devraient être lues avant les pages faibles ;
- ce que le site ne prétend pas.
Il ne doit pas être utilisé comme :
- blocage crawler ;
- remplacement de
robots.txt; - promesse de classement ;
- preuve d’ingestion ;
- liste de toutes les URLs ;
- contrat de licence à lui seul ;
- substitut à des pages sources claires.
Un bon llms.txt rend le site plus lisible. Il ne force pas les systèmes externes à lui obéir.
Content-Signal : posture d’usage, pas contrôle d’accès
Content-Signal comble un espace entre les règles d’accès de robots.txt et la politique d’usage IA plus large. Il peut déclarer si le site permet ou refuse des usages comme Search, l’entrée de modèle au moment de la réponse ou l’entraînement.
Cela n’en fait pas un blocage dur. C’est un signal de préférence lisible par machine. La bonne question d’audit est de savoir s’il raconte la même chose que le reste de la posture crawler et politique du site.
Lire : Content-Signal dans robots.txt.
Politique d’usage IA : explication humaine et machine
Une politique d’usage IA explique la posture publique du site.
Elle peut préciser :
- ce que le site autorise ou refuse ;
- comment interpréter les signaux de politique ;
- quels fichiers sont prioritaires ;
- ce que le site ne garantit pas ;
- comment traiter les affirmations non soutenues ;
- quand une vérification runtime est nécessaire.
Pour Better Robots.txt, ces surfaces de politique sont importantes parce que les directives crawlers et les résumés machine peuvent être surinterprétés. Une politique peut limiter cette surinterprétation.
Mais une politique n’est toujours pas de l’enforcement runtime. C’est une déclaration publique et un guide d’interprétation.
Fichiers de gouvernance : préséance et réduction d’ambiguïté
Un site mature ne devrait pas publier des fichiers isolés qui se contredisent.
Les fichiers de gouvernance résolvent ce problème de coordination. Ils peuvent définir :
- la préséance des sources ;
- la légitimité des réponses ;
- les contraintes anti-plausibilité ;
- les limites de sortie ;
- les points d’entrée canoniques ;
- les relations d’entités ;
- les index de routage ;
- les termes et définitions.
C’est pourquoi Better Robots.txt publie une pile de gouvernance sous /.well-known/ et dans des fichiers publics connexes. L’objectif n’est pas de multiplier les fichiers pour décorer le site. L’objectif est d’éviter que les machines traitent chaque page, politique, résumé et affirmation marketing comme également autoritaire.
Surfaces type WebMCP : interaction, pas politique de crawl
Les surfaces de type WebMCP appartiennent à une autre catégorie. Elles concernent l’interaction structurée avec les agents, pas l’accès crawler ordinaire.
Là où robots.txt dit « ces chemins devraient ou ne devraient pas être récupérés », et où llms.txt dit « voici comment comprendre le site », une couche d’interaction agentique peut dire :
- quelles actions sont disponibles ;
- quels intrants sont attendus ;
- quels extrants sont retournés ;
- quels outils ou workflows peuvent être invoqués ;
- quelles contraintes s’appliquent pendant l’interaction.
C’est plus proche d’un contrat d’interface que d’une politique de crawl.
Pour la plupart des sites WordPress, WebMCP n’est pas la première étape d’implémentation. Les premières étapes sont plus fondamentales :
- garder Search ouvert lorsque nécessaire ;
- séparer les finalités des crawlers IA ;
- publier un
llms.txtutile lorsque pertinent ; - documenter la posture d’usage IA ;
- réduire les routes WordPress de faible valeur ;
- améliorer les pages sources ;
- corriger l’accessibilité et la stabilité d’interaction.
C’est seulement ensuite qu’une couche structurée d’interaction agentique devient une étape sérieuse.
Où Better Robots.txt se situe dans la pile
Better Robots.txt est le plus fort dans ces couches :
- génération et revue de
robots.txt; - segmentation des familles de crawlers ;
- hygiène de crawl WordPress ;
- posture envers les crawlers IA ;
- publication optionnelle de
llms.txt; - signaux de gouvernance lisibles par machine ;
- interprétation d’audit et workflow de correction.
Il ne prétend pas être :
- un serveur WebMCP ;
- un outil de remédiation d’accessibilité ;
- un WAF ;
- un vérificateur d’identité d’agents signés ;
- une suite complète de tests UI agentiques ;
- une garantie de classement Search.
Cette frontière est essentielle pour la confiance.
Séquence d’implémentation
Phase 1 : stabiliser robots.txt
Utilisez Better Robots.txt pour créer une politique de crawl cohérente et éviter le blocage accidentel de Search.
Lire :
- Vérificateur robots.txt pour crawlers IA
- Contrôler les crawlers IA sur WordPress
- Vérification présence et validité robots.txt
Phase 2 : séparer les finalités des crawlers
Distinguez Search, entraînement, récupération déclenchée par l’utilisateur, archives, outils SEO et mauvais bots.
Lire :
- Crawlers d’entraînement IA vs crawlers de recherche IA
- Permissions Search, réponse et entraînement
- Ce que les signaux d’usage IA peuvent et ne peuvent pas faire
Phase 3 : publier un guidage lisible par machine
Si c’est utile, publiez llms.txt et des surfaces de politique qui pointent vers les bonnes pages.
Lire :
- Audit Lighthouse llms.txt pour WordPress
- Ajouter llms.txt sur WordPress
- Vérificateur de fichiers de gouvernance IA
Phase 4 : améliorer les pages sources
Un résumé lisible par machine est seulement aussi utile que les pages vers lesquelles il pointe.
Lire :
Phase 5 : inspecter l’interaction agentique
Utilisez Lighthouse Agentic Browsing, les vérifications d’accessibilité, la QA front-end, les tests de formulaires et les revues de parcours.
Lire :
- Lighthouse Agentic Browsing pour WordPress
- Checklist de préparation agentique WordPress
- Gouvernance crawler vs préparation agentique
- Content-Signal dans robots.txt
- Préparation agentique WordPress
FAQ
WebMCP remplace-t-il robots.txt ?
Non. Ils règlent des problèmes différents. robots.txt est du guidage d’accès au crawl. Les surfaces type WebMCP ressemblent davantage à de l’interaction agentique structurée.
llms.txt remplace-t-il WebMCP ?
Non. llms.txt résume et route. Les surfaces type WebMCP peuvent exposer des capacités d’interaction et des contraintes.
Better Robots.txt implémente-t-il WebMCP aujourd’hui ?
Better Robots.txt doit être compris principalement comme une couche WordPress de gouvernance du crawl et de guidage machine. L’interaction type WebMCP est une catégorie d’implémentation distincte.
Quelle couche implémenter en premier sur WordPress ?
Commencez par robots.txt et la sécurité Search. Séparez ensuite les finalités des crawlers. Publiez ensuite un guidage machine exact. Améliorez enfin les pages sources et la préparation à l’interaction.