Robots.txt vs allowlisting d’agents signés : où WordPress s’arrête, où l’edge commence
Il y a une phrase que davantage de propriétaires de sites devraient entendre :
tous les problèmes d’accès machine ne sont pas des problèmes robots.txt.
Certains problèmes restent des décisions nettes de politique de crawl. D’autres sont devenus des décisions d’identité et de permissions runtime.
Cette frontière compte davantage en 2026 parce que les grands acteurs documentent désormais :
- des fetchers déclenchés par l’utilisateur qui ignorent généralement
robots.txt; - des agents signés qu’on peut allowlister au niveau CDN ou pare-feu ;
- des catégories de bots vérifiés et des répertoires d’agents à l’edge.
Si on ne sépare pas ces couches, on finit soit par surpromettre ce qu’un plugin peut faire, soit par sous-contrôler ce que l’infrastructure devrait réellement gouverner.
La version courte
Voici la règle de base la plus utile.
| Couche | Rôle principal | À quoi elle sert réellement |
|---|---|---|
robots.txt | Politique publique de crawl | Accès au crawl Search, nombreux opt-out d’entraînement, règles par catégorie et par chemin |
Signaux d’usage et llms.txt | Publication de posture d’usage et de guidage | Posture Search / entraînement / réponse, guidage machine, réduction d’ambiguïté |
| Allowlisting d’agents signés | Identité vérifiée d’agent | Faire confiance à un agent signé spécifique au niveau edge |
| CDN / WAF / contrôles runtime | Enforcement et permissions | Frontières de session, parcours de connexion, achats, limites anti-abus, vérification de bots |
C’est précisément pour cela que La pile de gouvernance machine existe comme article d’architecture, et pas seulement comme guide de réglages.
Ce que robots.txt sait bien faire
robots.txt reste essentiel.
C’est la bonne couche lorsque la vraie question est :
- ce crawler peut-il récupérer ces chemins ;
- faut-il laisser Search ouvert ;
- faut-il refuser un crawler d’entraînement au niveau de la politique de crawl ;
- faut-il couper des espaces d’URL de faible valeur.
Cela couvre une grande partie des choix pratiques que Better Robots.txt a été conçu pour aider à publier :
- visibilité Search ;
- posture vis-à-vis des crawlers d’entraînement ;
- frontières d’archives ;
- posture vis-à-vis des outils SEO ;
- hygiène de crawl par chemin et par catégorie.
C’est une couche de publication et de politique.
Ce n’est pas une couche d’enforcement d’identité signée.
Ce qui a changé dans le web agentique
Deux familles de documentation rendent cette frontière beaucoup plus claire.
Les fetchers Google déclenchés par l’utilisateur
Google indique que les user-triggered fetchers ignorent généralement robots.txt parce que la récupération est initiée par l’utilisateur.
Google documente aussi Google-Agent comme étant utilisé par des agents hébergés sur l’infrastructure Google pour naviguer sur le web et exécuter des actions à la demande d’un utilisateur.
Cela veut dire qu’une partie du problème agentique Google n’est plus seulement :
« Que dit mon fichier public de crawl ? »
La vraie question devient :
« Comment gérer un trafic agentique qui appartient à une autre classe de requêtes ? »
Le modèle d’agent signé d’OpenAI
OpenAI documente ChatGPT agent comme un agent signé et allowlistable dans des écosystèmes edge majeurs comme Akamai, Cloudflare, et HUMAN.
C’est un autre monde de contrôle.
Dans ce monde, les vraies questions sont :
- l’agent est-il vérifié cryptographiquement ou opérationnellement ;
- doit-il être considéré comme de confiance à l’edge ;
- quelles permissions doit-il obtenir une fois autorisé ;
- que doit-il se passer sur les routes de login, de checkout, ou d’autres zones sensibles ?
Ce ne sont pas des questions que robots.txt a été conçu pour résoudre.
Ce que fait réellement l’allowlisting d’agents signés
L’allowlisting d’agents signés concerne l’identité de confiance à l’edge.
Cela veut dire que :
- la requête n’est pas traitée comme une simple chaîne user-agent déclarée ;
- le CDN, le WAF, ou un répertoire de bots de confiance entre en jeu ;
- le système peut exposer des permissions explicites ou un comportement Allow / Deny par classe d’agent.
En pratique, cela peut inclure :
- autoriser un agent vérifié à passer l’edge ;
- restreindre les routes auxquelles il a accès ;
- lui accorder ou lui refuser certaines permissions d’action ;
- journaliser les décisions sur la base d’une identité de bot vérifiée.
C’est un problème très différent d’une simple déclaration du type :
User-agent: SomeBotDisallow: /private/
Où WordPress s’arrête
La couche WordPress ou publication est l’endroit où l’on doit :
- publier
robots.txt; - publier une posture d’usage IA ;
- publier
llms.txtet d’autres surfaces de guidage lisibles par machine ; - clarifier les frontières de catégories ;
- réduire les contradictions entre les surfaces de politique publiques.
C’est le rôle que Better Robots.txt peut honnêtement remplir.
C’est une couche de gouvernance et de publication.
Où l’edge commence
L’edge commence quand le vrai problème devient :
- l’identité vérifiée d’un bot ;
- l’allowlisting ;
- les répertoires d’agents signés ou de confiance ;
- les permissions runtime ;
- les règles WAF ;
- les frontières de session ;
- la limitation de débit et le contrôle anti-abus.
À ce moment-là, la question n’est plus :
« Quel fichier faut-il publier ? »
Elle devient :
« À quel trafic faisons-nous confiance, et que lui permettons-nous réellement de faire ? »
C’est exactement le moment où il faut arrêter de réduire le sujet à une case robots.txt.
Trois erreurs fréquentes
1. Demander à robots.txt de résoudre l’accès d’un agent signé
Il ne peut pas le faire seul.
Il peut exprimer une politique et une intention, mais il n’effectue pas la vérification edge.
2. Traiter les agents signés comme de simples user-agents
On perd alors précisément ce qui rend le modèle d’agent signé intéressant : l’identité de confiance.
3. Surpromettre le scope du plugin
Un plugin WordPress peut publier une meilleure politique. Il ne devient pas magiquement votre CDN, votre WAF, votre couche d’identité, ni votre système de permissions runtime.
Un parcours de décision pratique
Utilisez cette séquence.
Si le vrai sujet est l’accès au crawl
Utilisez robots.txt.
Si le vrai sujet est la posture d’usage aval ou le guidage machine
Utilisez les signaux d’usage, les surfaces de policy, et llms.txt.
Si le vrai sujet est l’identité et la confiance d’un agent
Utilisez l’allowlisting d’agents signés ou les contrôles de bots vérifiés à l’edge.
Si le vrai sujet est ce que l’agent peut faire après l’accès
Utilisez les permissions runtime, les contrôles de routes, et l’enforcement d’infrastructure.
Où Better Robots.txt se place
Better Robots.txt se place avant l’edge, pas à la place de l’edge.
Il aide à publier une politique machine publique plus propre et une position de gouvernance plus claire.
Cette valeur est réelle précisément parce qu’elle évite de mélanger :
- politique de crawl ;
- posture d’usage ;
- guidage interprétatif ;
- enforcement d’infrastructure.
Plus ces couches sont séparées clairement, plus le modèle final de gouvernance devient mature.
Le bon modèle mental
Le modèle mental le plus sûr est celui-ci :
robots.txt= intention publique de crawl- signaux d’usage et
llms.txt= intention publique d’usage et de guidage - allowlisting d’agents signés = identité vérifiée à l’edge
- WAF / CDN / contrôles runtime = enforcement réel et permissions
Cette frontière n’est pas une faiblesse du modèle plugin. C’est la raison pour laquelle une pile sérieuse de gouvernance a besoin de plus d’une couche.