Le fichier llms.txt est un document markdown placé à la racine d’un site pour donner à un agent une carte de ses contenus. La proposition date du 3 septembre 2024 et n’a jamais été ratifiée. Elle ne contrôle aucun accès : les autorisations d’exploration restent l’affaire de robots.txt.
Ce que décrit exactement la proposition
Jeremy Howard, cofondateur d’Answer.AI, publie la proposition sur llmstxt.org le 3 septembre 2024. Le constat de départ tient en deux lignes. Une page HTML enveloppe son information dans de la navigation, des scripts et de la publicité, et la reconvertir en texte propre reste imprécis. Les fenêtres de contexte, elles, restent trop petites pour avaler un site entier.
Le fichier répond par une carte, pas par une copie. Il liste des liens commentés vers les ressources qu’un agent voudra lire, et reste assez court pour tenir en contexte. Le détail vit derrière les liens, récupéré seulement si la question l’exige.
Une structure imposée, dans un ordre imposé
Le format retient le markdown plutôt qu’un format structuré classique, parce que la cible est un modèle de langage. La spécification impose malgré tout un ordre strict, lisible par un analyseur syntaxique ou une expression régulière :
- une marque d’ordre d’octets facultative ;
- un titre H1 portant le nom du projet ou du site, seule section obligatoire ;
- une citation en bloc résumant le projet, avec les informations nécessaires pour comprendre la suite ;
- zéro ou plusieurs sections libres, de tout type sauf des titres ;
- zéro ou plusieurs listes de fichiers, chacune introduite par un H2, dont chaque élément contient un lien markdown suivi, si besoin, d’un deux-points et d’une note.
# Example SAS
> Éditeur français de logiciels de gestion de maintenance, exploités en SaaS depuis 2012.
Les pages listées ci-dessous existent aussi en markdown : ajoutez `.md` à l'URL.
## Produit
- [Fonctionnalités](https://example.com/produit/fonctionnalites.md) : périmètre fonctionnel, module par module
- [Tarifs](https://example.com/produit/tarifs.md) : grille publique, par utilisateur et par mois
## Documentation
- [Référence API](https://example.com/docs/api.md) : points d'entrée REST, authentification, quotas
## Optional
- [Mentions légales](https://example.com/legal.md)
La section « Optional » relève de la convention : elle regroupe les liens qu’un agent peut sauter quand le contexte disponible se réduit.
Ce que la version 2 a modifié
La page « Changes » de llmstxt.org date la v2 d’août 2026. Trois évolutions comptent pour une équipe technique. Le fichier peut vivre à la racine ou sous n’importe quel chemin, et couvre alors les pages situées sous ce chemin ; quand plusieurs fichiers s’appliquent, l’agent retient le plus spécifique. Les versions markdown d’une page acceptent désormais deux formes d’URL, l’ajout de .md à l’URL complète comme le remplacement de l’extension.
Surtout, la v2 règle la découvrabilité par des relations de lien standard. Un rel="alternate" de type text/markdown désigne la version markdown d’une page, un rel="describedby" désigne le llms.txt qui la couvre. Les deux passent par un élément <link> ou par un en-tête HTTP, ce qui se configure au niveau du serveur ou du CDN sans toucher aux gabarits.
Link: </docs/guide.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"
Le statut réel : une proposition, pas un standard adopté
Aucun organisme de normalisation n’a ratifié llms.txt. Ni l’IETF ni le W3C ne l’ont inscrit à leur catalogue, contrairement à robots.txt, formalisé par la RFC 9309 en septembre 2022. Le fichier vit donc sur sa seule adoption volontaire, côté éditeurs comme côté moteurs.
La position des éditeurs de modèles
Google s’est exprimé à plusieurs reprises, sans ambiguïté. En juillet 2025, Gary Illyes indiquait que Google ne prend pas en charge llms.txt et ne prévoit pas de le faire. En juin 2026, John Mueller ajoutait, dans un échange rapporté par Search Engine Journal, que le sujet reste « purement spéculatif pour l’instant », en relevant que le fichier existe depuis des années sans qu’aucun système d’IA ne l’utilise.
Le paradoxe amuse les praticiens : les laboratoires publient eux-mêmes un llms.txt pour leur documentation développeur, OpenAI, Anthropic et Gemini compris, sans s’engager à lire ceux des autres. Aucun éditeur de modèle grand public n’a annoncé de prise en charge en production.
Ce que montrent les mesures
Ahrefs a publié le 15 juin 2026 une analyse de 137 210 domaines suivis par son outil d’analytics. Résultat : 28 % de ces domaines publient un llms.txt, et 97 % de ces fichiers n’ont reçu aucune requête au cours du mois de mai 2026. Parmi les 3 % restants, les outils d’IA nommés représentaient 19,5 % des requêtes, le reste venant d’outils d’audit SEO, de robots non identifiés et de moteurs classiques.
Chrome intègre depuis peu un audit Lighthouse dédié à la navigation agentique. Sa logique traduit bien le statut du fichier : l’audit signale une erreur serveur sur /llms.txt, mais se déclare non applicable en cas de 404, la publication restant facultative.
Ce que llms.txt ne remplace pas
La confusion la plus coûteuse consiste à ranger llms.txt à côté de robots.txt, comme un deuxième fichier de règles. La spécification elle-même corrige cette lecture : les deux fichiers poursuivent des objectifs différents.
robots.txt reste le seul fichier d’autorisation
robots.txt exprime une autorisation d’accès, lue avant l’exploration, applicable à des chemins entiers. llms.txt n’exprime rien de tel. Il n’a ni directive, ni syntaxe de refus, ni jeton d’agent. Un fichier llms.txt exemplaire sur un site dont robots.txt interdit tout n’ouvre aucune porte, et l’inverse est vrai : bloquer un robot dans robots.txt reste efficace, que le site publie un llms.txt ou non.
sitemap.xml répond à une autre question
Un sitemap énumère l’ensemble des URL indexables destinées à des humains. llms.txt sélectionne, commente et hiérarchise. Les auteurs de la proposition listent trois écarts assumés : le sitemap ignore les versions markdown des pages, n’accepte pas de liens externes utiles à la compréhension, et couvre un volume qui dépasse largement une fenêtre de contexte.
Ouvrir ou fermer l’accès aux robots d’IA engage donc un arbitrage commercial autant que technique, entre visibilité dans les réponses génératives et contrôle sur la réutilisation des contenus. La décision se prépare avec des mesures de trafic et une lecture fine des journaux, un travail que des spécialistes du sujet comme Triaina agence GEO mènent avec les équipes techniques. Les principes de fond sont détaillés dans notre article sur la generative engine optimization.
Trois familles de robots, trois arbitrages distincts
Regrouper tous les agents sous l’étiquette « robots d’IA » conduit à des réglages contre-productifs. Les documentations officielles séparent nettement trois usages, et chacun se bloque ou s’autorise indépendamment.
Les robots d’entraînement
Ils collectent du texte destiné à l’apprentissage des modèles. GPTBot chez OpenAI, ClaudeBot chez Anthropic, Google-Extended chez Google, Bytespider chez ByteDance, CCBot pour le corpus Common Crawl. Les bloquer retire le site du corpus, sans effet direct sur la présence dans les réponses. Ce volume domine : d’après l’analyse publiée par Cloudflare le 28 août 2025, l’entraînement représente près de 80 % de l’exploration des robots d’IA.
Les robots de recherche
Ils construisent l’index consulté au moment de répondre. OAI-SearchBot alimente les résultats de recherche de ChatGPT, Claude-SearchBot améliore la qualité des résultats côté Anthropic, PerplexityBot rafraîchit l’index de Perplexity. Ces agents conditionnent la citation de vos pages. Les interdire revient à sortir du champ des réponses génératives, comme sortir de l’index de Google revient à disparaître de ses pages de résultats.
Les récupérations déclenchées par un utilisateur
ChatGPT-User, Claude-User et Perplexity-User ne parcourent pas le web en continu : ils vont chercher une page précise parce qu’un humain vient de la demander. Le statut de ces requêtes fait débat. OpenAI indique que les règles de robots.txt peuvent ne pas s’appliquer à ces actions initiées par un utilisateur, et Perplexity défend une position voisine pour Perplexity-User, présenté comme un agent et non comme un robot. Ces récupérations à la demande pèsent peu en volume : Cloudflare les classait, avec les requêtes non déclarées, sous les 5 % du trafic des robots d’IA.
Écrire les règles dans robots.txt
La syntaxe n’a rien de nouveau. Un groupe accepte plusieurs lignes User-agent, suivies de ses Disallow et Allow. Un agent applique le groupe dont le jeton correspond le plus précisément à son nom, jamais l’union de plusieurs groupes : dès qu’un groupe nommé existe pour lui, le groupe * cesse de le concerner.
# Entraînement des modèles : refus
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: CCBot
User-agent: Bytespider
Disallow: /
# Recherche et citation : ouverture
User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Allow: /
# Récupération déclenchée par un utilisateur
User-agent: ChatGPT-User
User-agent: Claude-User
Allow: /
User-agent: *
Disallow: /wp-admin/
Sitemap: https://example.com/sitemap.xml
Deux pièges reviennent en audit. Écrire User-agent: Claude* n’étend rien du tout, le caractère générique ne vaut que dans les chemins, pas dans les jetons d’agent. Et ajouter un jeton d’entraînement à un groupe de blocage global déjà en place suffit rarement : la documentation d’Anthropic recommande par exemple Crawl-delay pour freiner ClaudeBot plutôt qu’un refus sec, quand l’objectif se limite à protéger la charge serveur.
Ce que le blocage coûte réellement en visibilité
L’asymétrie entre exploration et trafic renvoyé nourrit le débat. Sur la première semaine d’août 2025, Cloudflare mesurait des rapports entre pages explorées et visiteurs renvoyés de 50 000 pour 1 chez Anthropic, 887 pour 1 chez OpenAI et 118 pour 1 chez Perplexity. Ces ordres de grandeur expliquent la bascule de juillet 2025, quand Cloudflare a activé le blocage par défaut des robots d’IA sur les nouveaux domaines et lancé son dispositif de paiement à l’exploration.
Le cas Google mérite un traitement à part. Le jeton Google-Extended ne dispose d’aucune chaîne d’agent utilisateur propre : la documentation de Google Search Central précise que l’exploration passe par les agents Google existants et que le jeton sert uniquement de levier de contrôle dans robots.txt. Le même document affirme que ce jeton n’affecte ni l’inclusion dans Google Search, ni le classement.
Conséquence directe : les résumés générés par Google s’appuient sur l’index construit par Googlebot, et bloquer Google-Extended ne les fait pas disparaître. Les seuls leviers documentés côté Google sont les contrôles d’aperçu, nosnippet, max-snippet et l’attribut HTML data-nosnippet, appliqués aux zones que vous refusez de voir reprises. Bloquer Googlebot, lui, revient à quitter le moteur, une décision d’un tout autre ordre. Le sujet rejoint les mécanismes décrits dans notre analyse sur le fait d’être cité par ChatGPT.
La limite structurelle : un respect volontaire
La RFC 9309 a normalisé l’analyse syntaxique, la gestion des erreurs et la mise en cache de robots.txt. Elle n’a introduit aucun mécanisme d’application. Un robot qui ignore le fichier ne viole aucune règle technique, seulement une convention.
Les manquements documentés existent. En août 2025, Cloudflare a publié une enquête accusant Perplexity d’utiliser des robots non déclarés, sous une chaîne d’agent de navigateur générique et avec rotation d’adresses IP, pour atteindre des sites qui bloquaient ses agents officiels ; l’éditeur a été retiré de la liste des robots vérifiés. Bytespider traîne une réputation comparable depuis 2023, alors même que ByteDance documente le respect du protocole d’exclusion.
L’application réelle passe donc par la couche réseau : filtrage WAF, listes de robots vérifiés, limitation de débit par empreinte. Une piste de normalisation avance en parallèle, portée par le groupe de travail AIPREF de l’IETF. Deux brouillons y cohabitent, l’un définissant un vocabulaire de préférences avec les catégories train-ai et search, l’autre un en-tête HTTP Content-Usage et une directive équivalente dans robots.txt. Aucun des deux n’a atteint le statut de RFC à ce jour.
Vérifier dans ses journaux ce qui passe réellement
Toute décision de réglage doit se mesurer sur vos journaux serveur, pas sur une déclaration d’éditeur. Un journal au format combiné contient déjà tout le nécessaire.
Compter les passages par agent
Le premier comptage prend une ligne de commande. Il donne la répartition réelle des robots et, accessoirement, le nombre de requêtes qu’a reçues votre llms.txt.
grep -aoiE 'GPTBot|OAI-SearchBot|OAI-AdsBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Bytespider|CCBot' access.log \
| sort | uniq -c | sort -rn
grep -ac 'GET /llms.txt' access.log
Ne cherchez pas Google-Extended dans ce résultat : ce jeton n’apparaît jamais dans une requête HTTP. Pour l’activité Google, filtrez sur Googlebot et GoogleOther.
Vérifier l’identité déclarée
Une chaîne d’agent se falsifie en une ligne. Les éditeurs publient donc leurs plages d’adresses : OpenAI expose gptbot.json, searchbot.json et chatgpt-user.json sur son domaine, Anthropic publie claude.com/crawling/bots.json, Google documente la vérification par résolution DNS inverse. Croisez systématiquement l’agent déclaré avec l’adresse source avant de conclure qu’un robot officiel a franchi une règle.
Prochaine étape concrète : extraire trente jours de journaux, compter les passages par famille d’agents, puis décider chemin par chemin ce que vous ouvrez à l’entraînement, à la recherche et aux récupérations à la demande. Le fichier llms.txt viendra après, comme un confort pour les agents de code, jamais comme une barrière. Cette lecture par la donnée rejoint la méthode décrite dans notre dossier sur la visibilité web des entreprises tech, et complète les enjeux d’ancrage documentaire abordés à propos de la génération augmentée par récupération.