llms.txt v2 est là : ce qui change et ce que vous devez mettre à jour
Le 10 août 2026, Jeremy Howard a publié la v2 de la proposition llms.txt, la première révision depuis le lancement du format en septembre 2024. Deux ans d’adoption ont produit une liste claire de ce qui manquait, de ce qui était ambigu et de ce qui n’était tout simplement pas utilisé comme la spécification le supposait.
Commençons par la bonne nouvelle : votre fichier llms.txt actuel reste valide. Le format du fichier n’a pas changé. Ce qui a changé, c’est tout ce qui l’entoure, et surtout la réponse à une question que des milliers d’adoptants posaient sans relâche.
Le problème que résout la v2
La v1 vous demandait de publier un llms.txt rempli de liens et de servir des versions Markdown propres de vos pages à l’adresse page.html.md. Mais elle n’a jamais relié les deux bouts.
Comme le dit Howard, le fichier « orientait les agents vers les pages, mais rien dans la spécification ne leur indiquait où se trouvaient réellement les versions Markdown ».
Un agent arrivant sur https://exemple.com/docs/auth n’avait donc aucun moyen fiable de répondre à deux questions simples :
- Existe-t-il une version Markdown de cette page, et où ?
- Existe-t-il un
llms.txtcouvrant cette page, et où ?
Il devait deviner : essayer d’ajouter .md, essayer /llms.txt à la racine, croiser les doigts. La v2 remplace la devinette par une déclaration.
Changement 1 : les link relations rendent votre Markdown découvrable
C’est le changement majeur. La v2 recommande deux link relations HTML standard :
rel="alternate" type="text/markdown"pointe d’une page vers sa version Markdownrel="describedby"pointe d’une page vers lellms.txtqui la couvre
Vous pouvez les livrer sous forme d’éléments <link> dans votre <head> :
<link rel="alternate" type="text/markdown" href="/docs/page.html.md" />
<link rel="describedby" href="/docs/llms.txt" />Ou, préférable pour la plupart des équipes, sous forme d’en-tête de réponse HTTP Link: :
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"Pourquoi la version en en-tête compte : vous pouvez l’ajouter dans la configuration de votre serveur web ou de votre CDN sans toucher à un seul template. Elle fonctionne aussi pour les ressources non HTML, y compris les fichiers Markdown eux-mêmes. Sur Cloudflare, Netlify, Vercel ou nginx, c’est un changement de configuration, pas une migration.
Ce ne sont d’ailleurs pas des conventions inventées : alternate et describedby sont des link relations déjà enregistrées auprès de l’IANA. La v2 a choisi de réutiliser la plomberie du web plutôt que d’en inventer une nouvelle.
Changement 2 : deux motifs d’URL Markdown sont désormais admis
La v1 spécifiait une seule convention : ajouter .md à l’URL complète, de sorte que /docs/tutorial.html devienne /docs/tutorial.html.md.
En pratique, beaucoup d’outils de publication ont fait l’autre chose évidente et ont remplacé l’extension : /docs/tutorial.md. La v2 accepte les deux.
| Motif | Original | Version Markdown |
|---|---|---|
Ajouter .md | /docs/tutorial.html | /docs/tutorial.html.md |
| Remplacer l’extension | /docs/tutorial.html | /docs/tutorial.md |
| URL sans extension | /docs/tutorial/ | /docs/tutorial/index.html.md ou /docs/tutorial/index.md |
La note de la spécification elle-même : la pratique « a divergé de la v1 d’une manière qui mérite d’être bénie ». C’est une façon saine de faire vivre un standard. Aucun des deux motifs n’est privilégié : utilisez celui que votre stack produit naturellement, puis déclarez-le avec rel="alternate".
Changement 3 : la couverture par sous-chemin est maintenant définie précisément
Un fichier llms.txt couvre les URL situées sous son propre chemin, et lorsque plusieurs fichiers s’appliquent, les agents doivent utiliser le plus spécifique. Ainsi /docs/llms.txt couvre tout ce qui se trouve dans /docs/ et prime sur le /llms.txt racine pour ces pages.
C’est plus qu’une clarification. C’est la raison pour laquelle llms.txt vit dans un chemin plutôt que sous /.well-known/ (RFC 8615). Les URI well-known n’existent qu’à la racine de l’origine, et beaucoup d’auteurs ne contrôlent qu’un sous-répertoire : un site de projet GitHub Pages, un dossier de documentation sur un hébergement mutualisé, la section d’une équipe dans un domaine d’entreprise. Avec la v2, quiconque peut publier un fichier dans un chemin peut y publier un llms.txt.
Si vous hébergez documentation, blog et site marketing sous un même domaine, vous pouvez désormais donner à chacun son fichier délimité, en sachant lequel l’emporte.
Changement 4 : llms_txt2ctx disparaît, et la mécanique « Optional » aussi
La v1 livrait un outil en ligne de commande, llms_txt2ctx, qui développait un llms.txt en un gros bloc de contexte, la section ## Optional portant un sens mécanique (à sauter quand le contexte se resserre).
La v2 retire les deux de la spécification. Non parce que l’expansion de contexte serait mauvaise, mais parce que ce n’est pas ainsi que les agents se comportent. Les agents réels consultent ou recherchent dans le llms.txt, puis suivent uniquement les liens dont ils ont besoin. Le fichier reste assez petit pour tenir dans le contexte ; le détail vit derrière les liens et n’est récupéré qu’à la demande.
## Optional existe toujours, mais purement par convention : des liens secondaires qu’un agent peut ignorer quand il veut un contexte plus court. Sans sémantique d’outillage associée.
Changement 5 : le cadrage a rattrapé la réalité
La section contextuelle de 2024 était une prédiction : les agents liraient couramment les sites web. La v2 la réécrit comme une description, parce que c’est devenu la routine.
La spécification cite désormais les preuves : des milliers de sites publient le fichier, les plateformes de documentation le génèrent automatiquement, Lighthouse de Chrome l’audite dans le cadre de ses vérifications de navigation agentique, et les laboratoires d’IA publient le leur : OpenAI, Anthropic et l’équipe Gemini de Google servent un llms.txt pour leur documentation développeur.
Ce que le format exige toujours (inchangé)
Cela vaut la peine d’être rappelé, car c’est là que les erreurs se produisent et rien de tout cela n’a bougé en v2 :
- Une marque d’ordre des octets (BOM) facultative
- Un H1 avec le nom de votre projet ou de votre site. C’est le seul élément obligatoire
- Un blockquote contenant un court résumé avec les informations clés nécessaires pour comprendre le reste du fichier
- Zéro ou plusieurs sections Markdown (paragraphes, listes, tout sauf des titres) apportant plus de détails
- Zéro ou plusieurs sections délimitées par des H2 contenant des listes de fichiers
Chaque liste de fichiers est une liste Markdown où chaque élément comporte un lien obligatoire, puis facultativement un : et des notes :
# Titre
> La description facultative va ici
Les détails facultatifs vont ici
## Nom de la section
- [Titre du lien](https://link_url) : Détails facultatifs du lien
## Optional
- [Titre du lien](https://link_url)Votre checklist v2
- Conservez votre fichier actuel. Il reste conforme à la spécification. Ne le réécrivez pas.
- Servez des versions Markdown de vos pages importantes, avec l’un ou l’autre motif d’URL.
- Ajoutez les deux link relations, idéalement en en-tête HTTP
Link:au niveau du CDN ou du serveur, pour éviter toute modification de template. - Délimitez vos fichiers par chemin si un domaine héberge plusieurs espaces distincts.
- Faites pointer vos liens vers du Markdown, pas du HTML. Les liens contenus dans
llms.txtdoivent mener à du contenu adapté aux LLM. C’était déjà vrai en v1 et c’est l’erreur la plus fréquente. - Validez avant de publier, pour que le fichier livré s’analyse réellement.
Une chose que la v2 n’a pas changée
llms.txt reste une proposition, pas un standard web ratifié, et toujours pas un facteur de classement Google. Google a dit clairement qu’il n’utilise pas ce fichier. La v2 rend le format plus utile aux agents qui le lisent vraiment, un ensemble réel et croissant, mais elle n’en fait pas un levier SEO.
Si quelqu’un vous vend la v2 comme une amélioration de classement, lisez d’abord llms.txt est-il un facteur de classement Google ?.
En résumé
La v2 est une révision modeste et sensée qui comble la seule lacune structurelle de la v1 : les agents pouvaient lire votre fichier, mais ne pouvaient pas le trouver, ni trouver le Markdown vers lequel il pointait. Deux link relations comblent ce trou, et l’une d’elles tient en une ligne de configuration CDN.
Prêt à mettre à jour ? Générez un fichier conforme à la spécification avec notre générateur llms.txt, puis vérifiez-le avec le validateur llms.txt. Si vous hésitez encore sur l’intérêt du fichier pour votre site, commencez par Quand llms.txt a du sens.