llms.txt v2 : inutile en SEO, utile aux agents IA ?
Deux ans après sa proposition, llms.txt n’a toujours pas prouvé qu’il améliorait les citations dans les moteurs IA. Sa v2 change pourtant la donne en assumant un autre rôle : aider les agents à naviguer dans un site et à trouver une version Markdown de ses contenus.
En bref
- Google Search n’utilise pas llmsLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte..txt et affirme que le fichier n’améliore ni la visibilité ni le classement dans ses fonctions d’IA générative.
- Une étude SE Ranking sur près de 300 000 domaines n’a trouvé aucune corrélation entre la présence du fichier et la fréquence des citations IA.
- Ahrefs a observé que 97 % des llms.txt présents dans son échantillon n’avaient reçu aucune requête en mai 2026.
- La v2, publiée le 10 août 2026, formalise surtout la découverte de versions Markdown et de fichiers llms.txt par des agents, via des relations de liens HTML et des en-têtes HTTP.
- Le fichier reste donc peu convaincant comme levier SEOSearch Engine Optimization : ensemble de pratiques pour améliorer la visibilité organique dans les moteurs de recherche./GEOGenerative Engine Optimization : stratégies pour apparaître dans les réponses génératives (AI Overviews, chatbots)., mais devient plus cohérent comme couche de navigation pour les agents et la documentation technique.
Sommaire · 9 sections
Deux ans après, llms.txt cherche encore sa place
Quand Jeremy Howard a proposé llms.txt en septembre 2024, l’idée était séduisante : offrir aux modèles et aux agents un fichier Markdown simple, placé sur un site, capable de résumer son contenu et de pointer vers les ressources importantes.
Le parallèle avec robots.txt ou un sitemapFichier listant les URLs importantes d’un site pour guider le crawl (complément, pas un ranking factor magique). est rapidement devenu tentant. Une nouvelle génération de moteurs arrivait, les éditeurs voulaient être compris et cités par ChatGPT, Claude, Perplexity ou les réponses génératives de Google, et llms.txt ressemblait à une réponse technique simple à un problème complexe.
Deux ans plus tard, cette promesse n’est pas vraiment confirmée.
La version 2 de la proposition llms.txt, mise à jour le 10 août 2026, arrive donc dans une situation paradoxale : le format reste peu utilisé par les systèmes auxquels on l’associait initialement, mais son auteur choisit de le faire évoluer au lieu de l’abandonner.
Et c’est justement ce qui rend cette v2 intéressante.
Non, llms.txt n’est toujours pas un levier SEO démontré
Sur ce point, les signaux sont désormais assez convergents.
Google a récemment clarifié sa position dans son guide consacré à l’optimisation pour les fonctionnalités d’IA générative de Search : Google Search n’utilise pas les fichiers llms.txt. Leur présence ne donne aucun avantage de visibilité ou de classement dans Google Search, y compris dans ses expériences génératives.
Google classe même les « fichiers texte IA » et autres marquages spéciaux parmi les éléments dont les éditeurs n’ont pas besoin pour apparaître dans AI Overviews ou AI Mode. Le moteur continue de recommander les fondamentaux habituels : contenu utile, crawlabilité, indexationInclusion d’une URL dans l’index d’un moteur, condition nécessaire (mais non suffisante) pour ranker. et structure technique claire.
Les études disponibles vont dans le même sens.
SE Ranking a analysé près de 300 000 domaines en 2025. Seulement 10,13 % disposaient d’un fichier llms.txt. Surtout, l’étude n’a trouvé aucune corrélation entre la présence du fichier et la fréquence des citations par les systèmes d’IA. Dans leur modèle prédictif, retirer la variable llms.txt améliorait même les résultats.
Ce n’est pas une preuve que le fichier ne pourra jamais avoir d’effet. Mais c’est une bonne raison de ne pas le vendre comme un facteur de visibilité aujourd’hui.

Le chiffre qui fait le plus mal : 97 % des fichiers ne sont pas lus
En juin 2026, Ahrefs a publié une analyse basée sur 137 210 domaines utilisant ses outils d’analytics.
Dans cet échantillon, 28 % des domaines publiaient un llms.txt. Ce taux est probablement supérieur à celui du Web dans son ensemble : Ahrefs précise lui-même que ses utilisateurs sont plus techniques et plus sensibilisés au SEO que la moyenne.
Mais le résultat le plus important se trouve ailleurs.
Parmi les quelque 38 000 domaines disposant d’un fichier valide, 97 % n’avaient reçu aucune requête vers leur llms.txt pendant le mois de mai 2026.
Pas uniquement aucune requête provenant de ChatGPT ou Perplexity : aucune requête du tout.
Et parmi les fichiers effectivement consultés, la majorité du trafic ne provenait pas de moteurs de recherche IA. Les outils d’audit SEO, crawlers généralistes, scanners de llms.txt et autres outils d’analyse représentaient une part importante des accès. Les agents et outils IA existaient bien dans les logs, mais restaient minoritaires.
Un détail est toutefois révélateur : parmi les bots de retrieval IA observés par Ahrefs, Claude-Code arrivait en tête. Le signal est faible en volume, mais il correspond précisément au cas d’usage où llms.txt paraît le plus logique : un agent de code qui veut extraire rapidement le contexte d’une documentation sans charger tout son HTML.
Ahrefs rapporte aussi une formule parlante de John Mueller : llms.txt peut se lire comme une béquille temporaire destinée à économiser des tokensUnité de texte traitée par un modèle (souvent un morceau de mot). Les coûts et fenêtres de contexte se comptent en tokens. à certains agents, plutôt que comme un nouveau signal de recherche. Cette interprétation colle mieux aux données que le récit d’un « robots.txtFichier qui indique aux robots ce qu’ils peuvent crawler ; ce n’est pas un mécanisme de sécurité. pour les LLM ».
Ahrefs a également observé un point particulièrement révélateur : dans son jeu de donnéesEnsemble de données structuré utilisé pour entraîner, valider ou tester un modèle., les bots IA ne tentaient pas spontanément de récupérer /llms.txt lorsqu’il n’existait pas. Autrement dit, publier le fichier ne signifie pas automatiquement qu’un agent va penser à le chercher.
C’est précisément l’un des problèmes que la v2 tente de résoudre.
Alors pourquoi sortir une v2 ?
Parce que le rôle de llms.txt devient plus clair.
La liste officielle des changements de la v2 identifie comme principal problème la découvrabilité.
Si un agent arrive sur une page, comment peut-il savoir qu’une version Markdown existe ? Comment découvre-t-il le fichier llms.txt qui décrit cette partie du site sans devoir deviner une URL ?
La v2 introduit pour cela deux relations standardisées :
rel="alternate" type="text/markdown"pour pointer vers la représentation Markdown d’une page ;rel="describedby"pour indiquer le fichier llms.txt qui décrit la ressource.
Ces liens peuvent être déclarés dans le HTML avec un élément <link> ou directement dans les en-têtes HTTP Link.
La v2 formalise aussi les fichiers llms.txt placés dans des sous-répertoires. Un /docs/llms.txt peut par exemple décrire tout ce qui se trouve sous /docs/, le fichier le plus spécifique prenant le dessus.
Elle assouplit également plusieurs éléments de la première proposition. Les deux conventions d’URL pour les versions Markdown — page.html.md et page.md — sont désormais acceptées. L’outil llms_txt2ctx est retiré de la spécification et la section Optional perd sa sémantique mécanique particulière : elle redevient simplement une section comme une autre.
Ces changements sont importants parce qu’ils montrent une évolution du projet : moins prescrire un pipeline de traitement spécifique, davantage fournir des conventions de découverte et de représentation que différents agents peuvent adopter à leur manière.
Ce changement est loin d’être cosmétique.
La première version reposait largement sur une convention : l’agent devait déjà savoir qu’il pouvait chercher un fichier llms.txt. La v2 essaie davantage de s’intégrer au fonctionnement normal du Web en permettant à une ressource d’annoncer elle-même ses représentations alternatives et son fichier descriptif.

De « signal pour LLM » à couche de navigation pour agents
C’est probablement ici qu’il faut arrêter de regarder llms.txt uniquement avec des lunettes SEO.
Un moteur de recherche n’a pas forcément besoin d’un fichier Markdown résumant un site. Google possède déjà un crawler, un index, une infrastructure de rendu HTML et des systèmes de classement construits précisément pour découvrir et comprendre le Web.
Un agent qui doit accomplir une tâche ponctuelle se trouve dans une situation différente.
Il peut avoir besoin de comprendre rapidement la structure d’une documentation, trouver une référence d’APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). ou sélectionner quelques pages pertinentes sans crawler des centaines d’URL. Dans ce contexte, une représentation Markdown propre et un index éditorial compact peuvent réduire le nombre de requêtes, le bruit HTML et la quantité de tokens à traiter.
Le format devient alors moins un « sitemap pour ChatGPT » qu’une interface documentaire légère destinée aux agents.
Cette lecture est renforcée par une initiative assez inattendue de Google lui-même.
Google Search l’ignore, mais Chrome Lighthouse le regarde
Depuis mai 2026, la documentation de Chrome Lighthouse consacrée à l’Agentic Browsing comporte un audit pour llms.txt.
Chrome décrit le fichier comme une « convention émergente » destinée à fournir aux LLM et agents une vue synthétique du contenu d’un site. La documentation explique qu’en son absence, un agent peut devoir passer davantage de temps à parcourir le site pour en comprendre la structure.
Mais il faut garder une nuance importante : l’audit est optionnel. Si le fichier n’existe pas et renvoie une 404, Lighthouse classe simplement le test en « Not Applicable ». Et toute la catégorie Agentic Browsing de Lighthouse est encore présentée comme expérimentale.
Il n’y a donc pas de contradiction réelle avec Google Search.
Deux produits Google répondent à deux problèmes différents : Search explique comment être découvert et classé dans son moteur ; Chrome explore comment rendre un site plus facile à utiliser par des agents autonomes.
C’est peut-être la meilleure illustration de ce qu’est devenu llms.txt.
Une adoption réelle, mais pas encore un standard du Web
Jeremy Howard souligne dans la v2 que des milliers de sites publient désormais le fichier, que certaines plateformes documentaires le génèrent automatiquement et que les documentations développeurs d’OpenAILaboratoire d’IA américain à l’origine des modèles GPT et de ChatGPT, accessibles par API et non téléchargeables., AnthropicLaboratoire d’IA américain à l’origine des modèles Claude, accessibles par API et non téléchargeables. et Gemini en proposent elles-mêmes.
C’est un signal d’intérêt. Ce n’est pas encore la preuve d’une adoption universelle par les consommateurs.
Un standard du Web devient réellement utile lorsque les logiciels qui doivent le lire s’accordent sur son comportement. robots.txt est précieux non parce que des millions de sites en publient un, mais parce que les crawlers le consultent et respectent ses directives.
Pour llms.txt, cette boucle n’est pas encore fermée.
Les éditeurs produisent déjà le fichier. Quelques outils le consomment. Certaines plateformes le génèrent automatiquement. Mais les grands systèmes d’IA n’ont pas collectivement déclaré qu’il faisait partie de leur mécanisme de découverte ou de citation du Web.
La v2 reste d’ailleurs officiellement présentée comme une proposition de standardisation, pas comme un standard établi.

Faut-il créer un llms.txt en 2026 ?
La réponse dépend surtout du type de site et de l’objectif poursuivi.
Si l’objectif est d’améliorer son classement Google, d’obtenir davantage de citations dans AI Overviews ou de gagner mécaniquement en visibilité dans ChatGPT, les données disponibles ne justifient pas d’en faire une priorité.
Pour un média, un site vitrine ou un e-commerce classique, un contenu accessible, des pages correctement indexables, une architecture claire et les fondamentaux SEO restent beaucoup plus importants.
En revanche, la balance change pour une documentation développeur, une API, une base de connaissances ou un produit dont le contenu est susceptible d’être parcouru directement par des coding agents et autres agents autonomes.
Dans ces cas, produire des versions Markdown propres et leur offrir un chemin de découverte explicite peut avoir une valeur pratique, même si cette valeur ne se mesure pas en positions SEO.
Et si un CMS ou une plateforme génère automatiquement un llms.txt correct, il y a peu de raisons de le supprimer. Il faut simplement éviter de lui attribuer des bénéfices que personne n’a encore démontrés.
La v2 ne sauve pas llms.txt : elle redéfinit son problème
Le débat autour de llms.txt a probablement commencé avec la mauvaise question : « comment optimiser un site pour les LLM ? »
La v2 en pose une autre, plus concrète : « comment aider un agent qui est déjà sur un site à trouver rapidement la représentation la plus exploitable de son contenu ? »
Sur le premier sujet, llms.txt reste très peu convaincant. Les études publiées à ce jour n’ont pas montré de gain de citations, Google Search dit explicitement ne pas l’utiliser et la majorité des fichiers observés par Ahrefs ne sont tout simplement jamais consultés.
Sur le second, le format devient beaucoup plus cohérent.
C’est peut-être pour cela que llms.txt mérite aujourd’hui davantage d’attention qu’en 2024 — mais pas pour la raison que le SEO lui avait initialement attribuée.
Lecture 404 Mates
Le vrai changement de llms.txt v2 n’est pas son adoption, mais son positionnement. La première version a souvent été présentée comme un équivalent de robots.txt ou du sitemap pour les LLM. Les données disponibles ne valident pas cette lecture. La v2 se rapproche plutôt d’une convention de découverte : indiquer à un agent où se trouvent le contexte utile et la représentation Markdown d’une ressource. Pour les éditeurs, la question devient donc moins « est-ce que cela me fera citer ? » que « est-ce que des agents ont réellement besoin de parcourir mon site comme une interface documentaire ? ».


