Une agence vous propose d'ajouter un fichier llms.txt à votre site pour « être lu par les IA ». Un plugin WordPress vous le génère en un clic. Le fichier existe vraiment, la spécification vient d'être mise à jour en août 2026, et pourtant Google écrit noir sur blanc qu'il ne le lit pas. Voici ce que ce fichier fait, qui le consomme réellement, et le seuil à partir duquel il commence à servir à quelque chose.
En bref :
- Google Search écrit dans sa documentation qu'il n'utilise pas les fichiers llms.txt, et range leur création dans la liste des choses à ignorer.
- L'audit Lighthouse de Chrome vérifie le fichier depuis mai 2026, mais son absence est marquée « Non applicable », pas en échec. Il ne signale qu'une erreur serveur.
- Le consommateur réel du fichier, tel que la spécification le décrit, c'est l'agent qui navigue à la demande, en particulier l'agent de code qui cherche une référence d'API dans une documentation.
- Cloudflare a scanné les 200 000 domaines les plus visités et a délibérément exclu llms.txt de son score d'aptitude aux agents, au profit de la version markdown des pages, qui passe sur 3,9 % des sites.
- Le seuil : le fichier a un consommateur le jour où répondre à une question courante de vos clients demande de recouper plusieurs pages de votre site. En dessous, un bon sitemap et des pages lisibles font le même travail.
Ce que le fichier est, en une page
Un llms.txt est un sommaire écrit pour une machine. Pas un fichier de configuration, pas une balise, pas une instruction de blocage.
La spécification tient en peu de choses. Le fichier est du markdown. Sa seule section obligatoire est un titre de niveau 1 avec le nom du site. Viennent ensuite un résumé court en citation, quelques paragraphes libres si nécessaire, puis des sections de niveau 2 qui contiennent des listes de liens, chaque lien pouvant porter une phrase de description après un deux-points.
C'est tout. Un humain le lit sans effort, un programme le parse sans ambiguïté.
L'intention est explicite : le fichier reste assez petit pour tenir dans une fenêtre de contexte, et le détail vit derrière les liens, récupéré seulement quand il est nécessaire. Un agent est censé lire ou chercher dans le fichier, repérer ce dont il a besoin, puis suivre le lien correspondant.
La confusion la plus fréquente porte sur la comparaison avec les fichiers que vous connaissez déjà. Un robots.txt dit qui a le droit d'entrer. Un sitemap.xml liste tout ce qui existe. Un llms.txt fait autre chose : il donne une lecture guidée, avec un ordre et des priorités. Ce ne sont pas trois versions du même fichier, ce sont trois questions différentes. La question de l'accès des robots est traitée dans notre article sur le fait d'autoriser ou bloquer les crawlers IA.
La spécification argumente d'ailleurs sur ce point : un sitemap ne liste généralement pas les versions lisibles par un modèle, n'inclut pas d'URL externes utiles à la compréhension, et couvre un ensemble de documents dont le volume dépasse largement ce qu'un modèle peut ingérer d'un coup.
Ce que llms.txt ne fait pas, dit par Google
C'est la partie que les vendeurs du fichier omettent, et elle est publique depuis juillet 2026.
Dans sa page d'orientation sur les fonctionnalités génératives, Google publie une liste de choses que vous pouvez ignorer pour Google Search. Le premier point de cette liste concerne directement notre sujet. Google y écrit qu'il n'est pas nécessaire de créer de nouveaux fichiers lisibles par machine, de fichiers texte pour l'IA, de balisage ou de markdown pour apparaître dans Google Search, y compris dans ses capacités génératives, parce que Google Search lui-même ne les utilise pas.
La même page va plus loin dans sa synthèse finale, en recommandant de privilégier les stratégies SEO efficaces plutôt que les astuces d'optimisation pour l'IA, et en citant nommément la création de fichiers texte inutiles comme llms.txt.
Il n'y a pas d'ambiguïté à lever ici, et pas de complot à débusquer. Google dit simplement que ce fichier n'entre pas dans son pipeline. Ce qui pilote votre présence dans les AI Overviews et dans AI Mode, ce sont les mêmes conditions que pour la recherche classique : une page indexée, explorable, éligible à un extrait.
Ce constat ne dit rien de Perplexity, de ChatGPT ou de Claude. Aucun de ces trois éditeurs ne documente publiquement la lecture d'un /llms.txt comme étape de son pipeline de recherche, ni dans un sens ni dans l'autre. En l'absence de documentation, la position honnête est de ne rien affirmer. Le mécanisme documenté de la citation, lui, est détaillé dans notre article sur la façon dont les IA choisissent leurs sources.
Le malentendu Lighthouse
En mai 2026, Google ajoute une vérification du fichier dans Lighthouse. Le SERP en conclut que Google a changé d'avis. La documentation de l'audit dit le contraire.
Lighthouse est l'outil de diagnostic intégré à Chrome, historiquement centré sur la performance et l'accessibilité. Il a reçu une famille d'audits dite « navigation agentique », dont un porte sur llms.txt. La nouvelle a circulé vite, souvent résumée en « Google vérifie maintenant votre llms.txt ».
Lisez ce que la documentation Chrome de cet audit dit exactement. Lighthouse signale les pages si une erreur serveur survient à la récupération du fichier. Et si le fichier n'est pas fourni par le serveur, donc en cas de 404, l'audit est marqué Non applicable, parce que fournir le fichier reste optionnel à ce stade.
Traduction : ne pas avoir de llms.txt ne vous coûte aucun point. Avoir un llms.txt cassé, en revanche, en coûte. C'est l'inverse exact de ce qu'on vous vend.
Le cadrage de Chrome mérite d'être cité, parce qu'il donne la vraie fonction du fichier. Sans lui, écrit la documentation, les agents peuvent passer plus de temps à explorer le site pour en comprendre la structure de haut niveau et le contenu principal. Le bénéfice annoncé porte sur le temps et le coût d'un agent qui vous visite, pas sur votre visibilité.
Absence de fichier : Non applicable, aucun impact. Fichier renvoyant une erreur serveur : signalé. Un llms.txt mal publié est donc le seul cas où ce fichier vous pénalise. Aucune source, Google compris, ne documente un gain de visibilité.
Ce qui a changé en août 2026 : la version 2
La spécification vient d'être révisée, et sa page de changements est le document le plus utile du sujet, parce qu'elle dit ce que deux ans d'usage ont invalidé.
La proposition d'origine date de septembre 2024. Son auteur écrit qu'à l'époque, l'idée que des modèles de langage lisent régulièrement des sites web était encore spéculative. Ce n'est plus le cas, et la v2 en tire quatre conséquences.
Premièrement, la découverte. La demande la plus fréquente était : comment un agent trouve-t-il la version markdown d'une page, ou le fichier qui la couvre, sans deviner ? La v2 répond par des relations de lien standard. Une relation alternate de type text/markdown pointe vers la version markdown de la page, une relation describedby pointe vers le llms.txt qui la décrit. Les deux se posent dans le HTML ou dans un en-tête de réponse HTTP.
Ce détail a une conséquence pratique qui compte pour une PME : l'en-tête HTTP se configure au niveau du serveur ou du CDN, sans toucher une seule page. Là où la v1 supposait une modification du site, la v2 ouvre une voie qui relève de l'hébergement.
Deuxièmement, les versions markdown des pages. La spec recommande de servir une version propre de chaque page utile à un agent, à la même URL, avec .md ajouté ou l'extension remplacée. La v1 n'autorisait que la première forme, la v2 accepte les deux parce que les outils de publication faisaient déjà les deux.
Troisièmement, la portée. La v1 tolérait un fichier dans un sous-chemin sans dire ce que ça voulait dire. La v2 le définit : un fichier couvre les pages sous son chemin, et quand plusieurs s'appliquent, l'agent prend le plus spécifique. Un /docs/llms.txt couvre /docs/ et rien d'autre.
Quatrièmement, et c'est le plus parlant, un retrait. La v1 décrivait un outil, llms_txt2ctx, chargé de dérouler le fichier en un contexte prêt à l'emploi. La v2 le sort de la proposition, et avec lui la signification mécanique de la section « Optional », qui n'existait que pour indiquer à cet outil ce qu'il pouvait omettre. Le fichier n'est plus une matière première à compiler. Il est un sommaire qu'on consulte.
Qui lit réellement ce fichier
La spécification est explicite sur son usage constaté, et cet usage est plus étroit que ce que le SERP raconte.
Deux phrases méritent d'être lues mot à mot. D'abord : les fichiers llms.txt sont utilisés surtout pour la documentation logicielle, où des agents de code les suivent pour trouver des références d'API et des tutoriels. Ensuite : l'attente initiale était que le fichier serve à l'inférence plutôt qu'à l'entraînement, et c'est ainsi qu'il a été utilisé.
Autrement dit, le consommateur documenté n'est pas un moteur de réponse qui construit un index. C'est un agent qui a une tâche en cours et qui doit se repérer vite dans un ensemble de pages.
Cette description colle à un type de site précis. Une documentation technique. Une base de connaissances. Un catalogue structuré. Elle colle beaucoup moins à un site vitrine de quinze pages où chaque service tient sur une page qui répond entièrement à la question qu'on lui pose.
Le profil des publieurs le confirme. Les laboratoires d'IA publient un llms.txt pour leur propre documentation développeur : le fichier d'OpenAI et celui d'Anthropic répondent tous les deux. Côté outillage, Mintlify génère le fichier et les versions markdown pour tous les sites de documentation qu'elle héberge, et côté WordPress, Yoast SEO comme AIOSEO le produisent automatiquement.
Retenez ce dernier point, il pèse dans l'arbitrage. Si votre site tourne sous WordPress avec l'une de ces extensions, le fichier est probablement déjà là. Payer pour sa création est alors une facture sans objet.
Le seuil de bascule : quand ce fichier a un consommateur
Le seuil n'est pas un nombre de pages, c'est une question : répondre à ce que vos clients demandent oblige-t-il à recouper plusieurs pages de votre site ?
Ce critère n'est pas inventé pour l'occasion, il sort de la logique même de la spécification. Le fichier existe parce qu'un site dépasse ce qu'un agent peut avaler d'un coup, et parce que le détail doit rester derrière des liens. Si votre page « Dépannage chaudière » contient déjà le prix, le délai, la zone couverte et les conditions, aucun agent n'a besoin d'un sommaire pour y arriver. Il lui faut une page lisible, pas une carte du site.
Deux conditions, à remplir ensemble :
- Une question courante de vos clients demande de croiser au moins trois pages. Documentation produit, base de connaissances, catalogue à variantes, procédures internes publiques. C'est le cas d'usage que la spec décrit.
- Vous êtes capable de servir les pages liées dans un format propre. Les liens d'un llms.txt sont censés pointer vers du contenu lisible par un modèle. Un sommaire qui renvoie vers des pages HTML lourdes restaure exactement le problème qu'il prétendait résoudre.
Il existe aussi un seuil haut, dont personne ne parle. Le fichier doit tenir en contexte. Passé une certaine taille, il cesse d'être un sommaire et redevient un annuaire, c'est-à-dire un sitemap déguisé, avec le même défaut de volume. Notre propre fichier, dont nous reparlons plus bas, occupe déjà 32 Ko pour 112 entrées. C'est encore lisible, mais on voit la limite d'ici.
En dessous du seuil bas, la bonne réponse est simple et elle ne coûte rien à personne : un sitemap correct, des pages qui répondent entièrement à une question, et un accès ouvert aux robots. C'est aussi, mot pour mot, ce que Google recommande.
Et si vous ne devez faire qu'une seule chose au-delà de ça, ce n'est pas le fichier. Quand Cloudflare a construit son score d'aptitude aux agents, en avril 2026, il a fait un choix qui tranche le débat mieux que n'importe quel argument : par défaut, son outil vérifie que le site sait servir du markdown quand on le lui demande, et ne vérifie pas llms.txt. L'inclusion du fichier est laissée en option pour ceux qui la souhaitent.
Le gain, lui, est mesuré : la version markdown d'une page demande beaucoup moins de jetons, jusqu'à 80 % de moins dans certains cas mesurés par Cloudflare. Un agent qui reçoit du markdown lit la page entière au lieu d'en abandonner la moitié.
llms.txt commence à payer quand une question courante de vos clients oblige un agent à recouper trois pages ou plus, et que vous pouvez lui servir ces pages en markdown. Une seule des deux conditions ne suffit pas. En dessous, sitemap et pages lisibles font le même travail.
Où en est le reste du web, chiffres à l'appui
La mesure la plus solide sur le sujet ne porte pas sur llms.txt, et c'est en soi une information.
En avril 2026, Cloudflare Radar a pris les 200 000 domaines les plus visités du web, écarté les catégories sans intérêt pour un agent comme les redirections et les serveurs publicitaires, puis scanné le reste. Les résultats situent le terrain :
| Standard vérifié | Part des sites scannés |
|---|---|
| robots.txt présent | 78 % |
| Négociation de contenu markdown | 3,9 % |
| Content Signals dans le robots.txt | 4 % |
| MCP Server Cards et API Catalogs | moins de 15 sites sur l'ensemble du jeu de données |
Deux lectures possibles, et elles sont toutes les deux vraies. La première : presque personne n'est prêt, donc être parmi les premiers coûte peu et distingue. La seconde : ces standards sont si peu répandus qu'aucun agent ne peut encore compter dessus, ce qui limite le rendement immédiat.
Pour une PME belge, la conclusion pratique est que ce chantier n'est pas une urgence commerciale. C'est un investissement d'infrastructure dont le rendement dépend d'une adoption qui n'a pas eu lieu. Le classer avant l'accès des robots ou la qualité des pages serait une erreur d'ordre.
Notre propre fichier, et ce qu'il nous coûte
Nous publions un llms.txt, et il serait malhonnête de vous vendre le contraire de ce qu'on fait.
Le fichier est en ligne sur atta-ai.com/llms.txt. Il est généré depuis nos fichiers de contenu, ce qui veut dire qu'aucune liste d'articles n'est maintenue à la main. Seuls trois blocs sont écrits : le positionnement, les services, et une courte note de méthode à destination des assistants. Le reste se met à jour tout seul à chaque publication.
Mesuré le 15 août 2026, en récupérant le fichier en production et en comptant : 32 568 octets, 112 entrées de liste de liens.
Pourquoi on le fait, alors qu'on vient d'écrire que le rendement n'est pas démontré ? Pour une raison unique et assumée : le coût marginal est nul. Le fichier se génère depuis une source qui existe déjà. S'il ne sert à rien, il n'aura rien coûté. S'il sert un jour, il sera à jour ce jour-là.
Ce raisonnement ne se transpose pas à un devis de plusieurs centaines d'euros pour un fichier écrit à la main, qui sera périmé à votre prochaine publication. La différence entre les deux situations n'est pas le fichier, c'est ce qu'il coûte à maintenir. Voilà le seul critère qui devrait décider.
Ce qu'on ferait à votre place
Si votre site est une vitrine de dix à quarante pages, ne payez pas pour un llms.txt. Vérifiez d'abord que vos pages sont lisibles et que les robots y ont accès, ce qui décide réellement de votre présence dans les réponses générées. Si votre CMS le génère tout seul, laissez-le faire et surveillez juste qu'il ne renvoie pas d'erreur, seul cas où le fichier vous pénalise.
Si vous publiez une documentation, une base de connaissances ou un catalogue où la réponse se construit sur plusieurs pages, alors le fichier a un consommateur, et la bonne question devient celle du format des pages liées avant celle du sommaire lui-même.
Dans les deux cas, méfiez-vous d'un prestataire qui vend ce fichier comme un levier de visibilité. Il vend un livrable facile à produire et impossible à évaluer. La bonne prestation commence par ce qui se mesure : qui accède à vos pages, ce qu'ils y lisent, et ce qui ressort quand on interroge un assistant sur votre métier. C'est ce qu'on regarde d'abord dans notre accompagnement en référencement IA, et le cadre complet est posé dans notre guide du référencement IA pour les PME.
Vous voulez savoir si ce chantier vaut quelque chose dans votre cas précis, avant de signer quoi que ce soit ? Parlons-en trente minutes. On repart avec un ordre de priorité, pas avec un fichier de plus.
FAQ
Q: Google lit-il le fichier llms.txt ?
A: Non. Sa documentation sur les fonctionnalités génératives indique qu'il n'est pas nécessaire de créer de fichiers lisibles par machine, de fichiers texte pour l'IA ou de markdown pour apparaître dans Google Search, y compris dans ses capacités génératives, parce que Google Search ne les utilise pas. La même page range la création de llms.txt parmi les tactiques à ignorer.
Q: Pourquoi Lighthouse le vérifie-t-il, alors ?
A: Parce que l'audit ne mesure pas le référencement mais le confort d'un agent qui visite votre site. Et il ne pénalise pas l'absence : si le fichier n'existe pas, le résultat est marqué Non applicable. Seule une erreur serveur à la récupération est signalée. Un fichier mal publié coûte donc des points, un fichier absent n'en coûte aucun.
Q: Faut-il le mettre à la racine du site ?
A: Pas obligatoirement, et c'est nouveau depuis la version 2 d'août 2026. Le fichier couvre les pages situées sous son chemin. Un fichier placé dans /docs/ couvre /docs/ et rien d'autre, et quand plusieurs fichiers s'appliquent, l'agent retient le plus spécifique. Cela permet de participer même quand on ne contrôle qu'un répertoire sur un hébergement partagé.
Q: Mon site fait vingt pages, ça vaut le coup ?
A: Sans doute pas. Le fichier sert quand une question courante oblige un agent à recouper plusieurs pages. Sur un site où chaque service tient sur une page complète, un sitemap correct et des pages lisibles font le même travail. Si votre extension WordPress le génère déjà toute seule, laissez-la faire, mais ne payez pas pour ça.
Q: Quel est le vrai chantier prioritaire, alors ?
A: Le format et l'accès. Cloudflare, qui a scanné les 200 000 domaines les plus visités, vérifie par défaut la capacité à servir du markdown et ne vérifie pas llms.txt. La version markdown d'une page demande jusqu'à 80 % de jetons en moins d'après ses mesures. Avant tout ça : vérifier que les robots ont bien accès à vos pages.
