llms.txt v2 : une meilleure découvrabilité technique, toujours aucun gain GEO démontré

Le document de spécification publié sur llmstxt.org, signé Jeremy Howard, affiche une date de modification au 10 août 2026. La v2 ne repart pas de zéro. Elle corrige des problèmes de découvrabilité que deux ans d’adoption ont fait remonter : comment un agent trouve-t-il la version Markdown d’une page ? Comment sait-il quel fichier llms.txt couvre un sous-répertoire ?

Ces corrections rendent le protocole plus cohérent. Mais elles ne changent rien à la question qui intéresse les équipes SEO et GEO : est-ce que llms.txt v2 améliore la visibilité dans les moteurs génératifs ? La réponse, à ce jour, reste non. Le guide complet llms.txt publié sur ExternFlow détaille le contexte et le niveau de preuve.

En bref. La v2 de llms.txt ajoute deux mécanismes de découverte (rel alternate et rel describedby) et clarifie le rôle des fichiers dans les sous-répertoires. Google Search ignore toujours ce fichier, et OpenAI ne le documente pas comme condition de visibilité dans ChatGPT Search.

Qu’est-ce qui change concrètement dans llms.txt v2 ?

Quatre modifications principales.

• Découverte par lien rel. La v2 recommande deux relations HTML : rel= »alternate » type= »text/markdown » pour pointer vers la version Markdown d’une page, et rel= »describedby » pour indiquer le fichier llms.txt qui la couvre.
• Deux formes d’URL Markdown. La version Markdown d’une page peut être obtenue en ajoutant .md à l’URL complète (page.html.md) ou en remplaçant l’extension par .md (page.md).
• Sous-répertoires. Un fichier llms.txt couvre toutes les pages situées sous son chemin. Si plusieurs fichiers s’appliquent, le plus spécifique l’emporte.
• Usage attendu. Les agents consultent ou recherchent llms.txt, puis suivent les liens vers le contenu lisible par machine.

Ces changements répondent à un problème concret : sans mécanisme de découverte, les agents devaient deviner l’existence d’un fichier llms.txt. La v1 ne spécifiait ni comment le trouver, ni comment gérer les documentations organisées en sous-dossiers.

Pourquoi Lighthouse ne transforme-t-il pas llms.txt en facteur SEO ?

Chrome Lighthouse inclut un audit llms.txt depuis une mise à jour documentée le 5 mai 2026 (avant la v2). La documentation officielle qualifie llms.txt de « convention émergente ». L’audit est optionnel : si le fichier renvoie un code 404, le contrôle est classé Not Applicable, pas échoué.

Lighthouse mesure des pratiques techniques. Un score positif sur un audit optionnel ne signifie pas que Google Search utilise le fichier pour classer les pages. La distinction est la même que pour le passage en HTTPS en 2016 : l’audit existait avant que le signal de classement ne soit confirmé. Pour llms.txt, cette confirmation n’existe pas.

Google et ChatGPT utilisent-ils llms.txt pour classer ou citer les pages ?

Google Search. La position est explicite : Google indique que Search ignore llms.txt. Le fichier n’aide ni ne pénalise la visibilité dans Google Search, AI Overviews ou AI Mode. Cette déclaration figure dans le guide d’optimisation pour les fonctionnalités génératives.

ChatGPT Search. OpenAI recommande d’autoriser OAI-SearchBot pour la découvrabilité dans ChatGPT Search. Sa documentation publique ne présente pas llms.txt comme condition de crawl, d’indexation ou de classement. Cela ne prouve pas que ChatGPT ne consulte jamais un fichier llms.txt. Cela signifie qu’aucun usage comme signal de visibilité n’est documenté officiellement. L’analyse RESONEO de l’index ChatGPT Search confirme que les mécanismes de sélection restent opaques.

Les vrais prérequis de visibilité dans les moteurs génératifs passent avant llms.txt : accessibilité du crawl, couverture des sous-questions, citabilité des passages et consensus tiers.

Quels sites devraient adopter la v2 maintenant ?

La réponse dépend du cas d’usage, pas d’une règle universelle.

Pour une PME WordPress sans documentation technique, le temps investi dans llms.txt serait mieux employé à résoudre un problème de crawl ou à renforcer le maillage interne. Les études GEO n’ont pas encore établi de lien entre la présence d’un fichier llms.txt et un gain de citations.

La v2 améliore le protocole, pas le niveau de preuve GEO

llms.txt v2 rend la convention plus crédible techniquement. La découverte est mieux définie, les sous-répertoires sont couverts, le comportement attendu des agents est explicité. C’est un progrès pour les équipes qui maintiennent des documentations complexes.

Pour les équipes SEO et GEO, la conclusion reste la même : mettre à jour si un cas d’usage agentique réel existe, prioriser les fondamentaux sinon. La méthode pour combiner SEO et GEO rappelle que la visibilité générative se construit d’abord par le contenu, les entités et les signaux tiers.

Sources et références

Cet article s’appuie notamment sur la spécification v2 de llms.txt publiée sur llmstxt.org, signée Jeremy Howard avec une date de modification au 10 août 2026. Le changelog est détaillé dans le dépôt GitHub AnswerDotAI. La documentation de l’audit Lighthouse est accessible dans le guide Chrome for Developers. La position de Google Search est explicitement formulée dans le guide d’optimisation pour les fonctionnalités génératives. Le mécanisme de découvrabilité dans ChatGPT Search est documenté dans la FAQ OpenAI pour les éditeurs et développeurs.