SEO & IA

La vérité sur le fichier llms.txt

Tous les grands acteurs de l'IA publient un llms.txt sur leurs sites de documentation. Aucun ne s'engage à lire le vôtre. J'ai testé les URL une par une, relu les déclarations officielles et les études de logs. Voici ce que ça donne, en séparant les faits, les déclarations et les hypothèses.

Fred Gaveau4 août 2026~11 min de lecture

Le point de départ est une bizarrerie. Le llms.txt est présenté depuis deux ans comme le fichier qui parle aux intelligences artificielles. Et de fait, elles en publient toutes un : Anthropic, OpenAI, Mistral, Perplexity, xAI, Google en partie. Si quelqu'un sait à quoi sert ce fichier, ce sont bien eux.

Sauf qu'aucun d'eux n'a jamais écrit que ses propres robots le lisaient sur votre site. Et la seule entreprise qui s'est exprimée clairement sur le sujet — Google — a dit non.

Cette enquête part de là. J'ai testé chaque URL à la main, retrouvé les déclarations officielles quand elles existent, et lu les études de logs publiées. Le format est volontairement séparé en trois : ce qui est prouvé, ce qui est déclaré, et ce qui reste de la spéculation — la mienne comprise.

Ce que j'ai vérifié moi-même

J'ai interrogé dix-sept URL en ligne de commande le 4 août 2026 à 13 h 24 UTC, en suivant les redirections et en relevant le code HTTP et le poids du corps renvoyé. Tous les liens du tableau sont actifs : vérifiez par vous-même, c'est le principe.

Instantané du 4 août 2026, 13 h 24 UTC. Un fichier peut apparaître ou disparaître demain — c'est précisément ce qui est arrivé à Google.

Trois choses sautent aux yeux dans ce tableau.

Un : le fichier vit sur les sous-domaines de documentation, jamais sur le site grand public. docs., developers., platform. répondent 200. Les racines anthropic.com et google.com répondent 404. Une seule exception dans le panel : Vercel, dont /docs/llms.txt redirige vers vercel.com/llms.txt, réellement servi à la racine comme la spécification le demande.

Deux : Google est fragmenté. Firebase en a un, Google Cloud non, le site des modèles Gemini non plus. Ce n'est pas une politique, c'est un accident — j'y reviens.

Trois : le format a explosé en vol. La spécification décrit un index court. Firebase sert 1,7 Mo, xAI 1,3 Mo, la variante complète de Vercel 7,4 Mo. Un index de 1,7 Mo n'est plus un index : c'est le corpus qu'il était censé résumer.

D'où vient ce fichier

FAIT llms.txt est une proposition publiée le 3 septembre 2024 par Jeremy Howard (Answer.AI, co-fondateur de fast.ai) sur llmstxt.org. L'idée : un fichier Markdown à la racine du site, structuré — un titre #, un résumé en citation, des sections ## de liens annotés — pour offrir aux modèles une carte propre du contenu, au lieu de leur faire deviner la structure d'un site moderne bourré de JavaScript.

L'analogie avec robots.txt et sitemap.xml est assumée, et c'est elle qui a fait le succès de l'idée. Mais elle est trompeuse sur un point décisif : robots.txt et sitemap.xml ont été adoptés par les moteurs avant d'être popularisés. Ici, c'est l'inverse.

FAIT La page de spécification ne revendique aucune adhésion d'éditeur d'IA, ne mentionne aucun processus de normalisation (ni IETF, ni W3C, ni WHATWG) et se décrit elle-même comme ouverte aux contributions de la communauté via un dépôt GitHub. Détail rarement relevé : llms-full.txt ne figure pas dans la spécification. C'est une convention née de l'usage, que tout le monde applique différemment.

Le cœur du sujet : quelqu'un lit-il vraiment ce fichier ?

C'est la seule question qui compte, et elle a des réponses chiffrées.

Ce que disent les journaux de serveur

FAIT Le 5 mars 2026, Dries Buytaert — créateur de Drupal, directeur technique d'Acquia — publie une analyse d'un mois de journaux Cloudflare. Son site a reçu 52 requêtes sur /llms.txt en un mois. Toutes provenaient d'outils d'audit SEO. Aucune ne venait d'un moteur de réponse ou d'un crawler d'IA. Sur l'ensemble de l'infrastructure d'hébergement d'Acquia : environ 5 000 requêtes sur 400 millions, soit 0,001 %, quasi exclusivement des outils SEO.

FAIT Une analyse de journaux d'Ahrefs portant sur 137 000 domaines (publiée en juin 2026, reprise par PPC Land) conclut que 97 % des fichiers llms.txt n'ont reçu aucune requête en mai 2026. Les robots de récupération IA représentaient 1,1 % des requêtes constatées.

FAIT Enfin, une étude SE Ranking du 7 novembre 2025 sur 300 000 domaines ne trouve aucun effet mesurable de llms.txt sur les citations par les IA. Retirer la variable du modèle prédictif améliorait même sa précision.

Ce que Google déclare

DÉCLARATION Google est le seul grand acteur à s'être exprimé formellement. Sa documentation officielle sur les fonctionnalités IA de la recherche (developers.google.com, mise à jour du 10 décembre 2025) écrit noir sur blanc :

DÉCLARATION Sur Reddit, John Mueller a comparé llms.txt à la balise meta keywords — abandonnée précisément parce que c'est le site lui-même qui la remplit — puis, rapporté en juin 2026 : « I don't think anyone knows – it's purely speculative for now (the file has existed for years, yet none of the AI systems use it — what does it mean?) ». Il ajoute un critère de décision que je trouve honnête : le jour où une plateforme IA qui vous amène des clients réclame le fichier, faites-le. D'ici là, non.

DÉCLARATION Gary Illyes, de l'équipe Search, a indiqué lors d'un Search Central Live en juillet 2025 que Google ne prend pas en charge llms.txt et ne prévoit pas de le faire — position relayée par Search Engine Roundtable.

Ce que les autres ne disent pas

NON VÉRIFIÉ Pour OpenAI, Anthropic, Perplexity et Mistral, je n'ai trouvé aucune déclaration publique affirmant que leurs robots consomment le llms.txt d'un site tiers — ni aucune l'excluant. Le silence n'est pas une preuve d'absence, mais il n'est pas non plus un engagement. Publier un fichier sur sa propre documentation ne dit rien de ce que fait son crawler chez vous : ce sont deux équipes, deux produits, deux problèmes.

La contradiction Google, documentée

C'est l'épisode le plus révélateur, et il est vérifiable.

RAPPORTÉ Le 3 décembre 2025, un llms.txt apparaît sur developers.google.com/search/docs/. Il est repéré par la consultante SEO Lidia Infante. Il est retiré le jour même. Selon les comptes rendus, le fichier n'était pas une décision de l'équipe Search : le système de gestion de contenu interne de Google, commun à plusieurs propriétés développeur, s'était mis à en générer automatiquement. Certaines équipes l'ont retiré, d'autres non.

FAIT — vérifié le 4 août 2026 Cette lecture est confirmée par l'état actuel du terrain. developers.google.com/search/docs/llms.txt, developer.chrome.com/llms.txt, web.dev/llms.txt, cloud.google.com/llms.txt, ai.google.dev/llms.txt : 404 partout. Et firebase.google.com/docs/llms.txt : 200, 1,7 Mo. Une équipe a oublié de faire le ménage. Le « llms.txt de Google » qu'on cite un peu partout comme preuve d'adoption est un résidu de déploiement automatique.

FAIT Et pourtant, au même moment, une autre partie de Google va dans l'autre sens. Lighthouse 13.3, l'outil d'audit intégré à Chrome, embarque une catégorie expérimentale « Agentic Browsing » qui contient un audit llms.txt (documentation mise à jour le 5 mai 2026). Il y est décrit comme « an emerging convention used to provide a machine-readable summary of a website's content, specifically designed for LLMs and AI agents », et l'audit note que sans ce fichier, les agents passent plus de temps à explorer le site.

MON INTERPRÉTATION Ce n'est pas de l'hypocrisie, et je ne le présenterai pas comme telle. C'est que « Google » n'est pas une entité unique et que les deux équipes ne parlent pas du même usage : Search parle de classement et de citation dans un moteur de réponse, Chrome parle d'efficacité d'un agent qui navigue. Les deux positions sont défendables séparément. Elles sont simplement incompatibles pour le lecteur qui cherche à savoir si « Google » recommande ou non le fichier. Et cette confusion-là, personne ne la dissipe. Search Engine Journal l'a résumé d'une formule juste : la recommandation de Google dépend du produit auquel vous posez la question.

Alors pourquoi tout le monde en publie un ?

Voici l'hypothèse que je défends, et les fichiers eux-mêmes la soutiennent : llms.txt n'a jamais été un fichier SEO. C'est un fichier de documentation développeur. Le lecteur visé n'est pas GPTBot en train d'indexer le web pour un moteur de réponse. C'est un développeur avec Cursor, Claude Code ou Copilot ouvert, dont l'agent a besoin de charger une doc d'API à jour plutôt que de réciter une version périmée apprise à l'entraînement.

FAIT Les fichiers le disent explicitement. Celui de Cohere contient une section intitulée « Instructions for AI Agents » qui recommande d'ajouter .md à n'importe quelle URL pour obtenir du Markdown propre, et de connecter un serveur MCP « for AI client integration (Claude Code, Cursor, etc.) ». Celui de Cloudflare précise que chaque produit a son propre llms.txt, « the recommended way to explore a specific product's content ». Ces phrases ne s'adressent pas à un moteur de recherche.

FAIT Les journaux de Buytaert vont dans le même sens : les agents intégrés aux IDE récupèrent bien ces ressources, contrairement aux crawlers des moteurs de réponse.

Si cette lecture est juste, alors tout le débat « llms.txt améliore-t-il ma visibilité IA ? » repose sur une erreur de casting. On juge un outil de documentation technique aux critères du référencement. Il échoue, évidemment. Ça ne veut pas dire qu'il ne sert à rien — ça veut dire qu'il ne sert pas à ça.

Ce qui marche vraiment, et que personne ne vend : le Markdown

FAIT C'est la donnée la plus utile de toute cette enquête, et elle est passée inaperçue. Toujours dans les journaux de Buytaert, quand une page est disponible en Markdown à une URL prévisible :

Autrement dit : les crawlers d'OpenAI vont chercher du Markdown quand il existe à une URL devinable — typiquement /ma-page.md. Un tiers de leurs récupérations, pour GPTBot. C'est infiniment plus que les 0,001 % du llms.txt.

FAIT Et le corollaire est brutal : « No AI crawler uses content negotiation. Not one. » Aucun robot IA n'utilise l'en-tête Accept pour demander du Markdown. La négociation de contenu, la méthode propre et normalisée depuis trente ans, est ignorée par tout le monde. Ce qui marche, c'est le suffixe d'URL, la solution la plus bête.

C'est exactement le motif qu'utilisent Stripe, Cohere, Perplexity et Anthropic dans leurs fichiers : chaque entrée pointe vers un jumeau .md. Le llms.txt est l'annuaire ; les jumeaux Markdown sont ce qui est réellement consommé.

Le cas Stripe : quand l'index devient un ordre

FAIT Le llms.txt de Stripe ne commence pas par une description. Il commence par des impératifs adressés à la machine qui le lit. Extrait vérifié, premières lignes du fichier :

# Stripe Documentation

When installing Stripe packages, always check the npm registry for the latest
version rather than relying on memorized version numbers. Run `npm view stripe
version` [...] Never hardcode an old version number from training data — always
install with `@latest` or verify the current version first.

HYPOTHÈSE Ce détournement pose une question de sécurité que je pose sans pouvoir la trancher : si un fichier public non signé peut contenir des instructions, et qu'un agent le charge dans son contexte sans distinguer « description du site » de « ordre à exécuter », on est dans le périmètre de l'injection de prompt. Je n'ai trouvé aucun incident public documenté exploitant un llms.txt. Le risque est structurel, pas constaté. Mais le format n'offre aujourd'hui aucun moyen de séparer les deux — et Stripe, qui agit de bonne foi, vient de démontrer que la porte est ouverte.

Huit propositions pour réparer le format

Critiquer est facile. Voici ce qui, à mon avis, transformerait llms.txt d'objet de foi en outil utile. Chaque proposition s'appuie sur un mécanisme qui existe déjà ailleurs.

1. Arrêter de l'écrire à la main. Le générer.

Un llms.txt rédigé à la main pourrit en trois mois : les pages bougent, le fichier non. Il doit être produit au moment du build, depuis la même source que le sitemap ou le CMS. Ironie du sort : c'est exactement ce que faisait le système interne de Google — et l'accident de décembre 2025 vient de ce que la génération était automatique alors que la décision ne l'était pas. Automatisez la génération, pas la décision.

2. Servir les jumeaux Markdown avant l'index.

C'est la proposition la plus rentable, et elle inverse l'ordre des priorités communément admis. Puisque les crawlers d'OpenAI récupèrent du Markdown à hauteur d'un tiers de leurs requêtes mais ignorent la négociation de contenu, servez /ma-page.md à côté de /ma-page, à URL prévisible, et déclarez-le dans le HTML avec <link rel="alternate" type="text/markdown" href="/ma-page.md">. Ça fonctionne aujourd'hui, mesurablement, contrairement au llms.txt. Si vous ne deviez faire qu'une seule chose de cet article, c'est celle-là.

3. Déménager dans /.well-known/.

La RFC 8615 définit depuis 2019 un espace de noms standard pour exactement ce genre de fichiers, avec un registre IANA à la clé. /.well-known/llms.txt réglerait d'un coup la question de l'emplacement — celle qui explique que tous les fichiers du tableau vivent sur des sous-domaines de doc plutôt qu'à la racine — et ouvrirait la seule voie de normalisation crédible.

4. Le déclarer dans robots.txt.

Une ligne, Llms: https://exemple.com/llms.txt, sur le modèle exact de la directive Sitemap: — qui n'a jamais été normalisée non plus, et que tous les moteurs respectent pourtant. Coût nul, découverte garantie, et un mécanisme dont l'adoption est déjà prouvée par vingt ans d'usage.

5. Dater chaque entrée.

Un index sans fraîcheur est inutilisable : face à une page rendue en direct, un modèle n'a aucune raison de préférer une ligne d'index qui peut dater de deux ans. Une date par entrée — - [Page](url) (2026-07-12) : description — et un Last-Modified honnête sur le fichier lui-même donnent enfin de quoi arbitrer.

6. Séparer l'index du corpus, formellement.

Le format doit poser un plafond dur — disons 50 Ko — pour llms.txt, et renvoyer tout le reste vers un llms-full.txt explicitement défini dans la spécification (il n'y figure toujours pas). Les 1,7 Mo de Firebase et les 1,3 Mo de xAI ne sont pas des abus : ce sont les symptômes d'un format qui n'a jamais dit où s'arrêter.

7. Signer, ou assumer que ça ne vaut rien.

Le reproche de John Mueller — « c'est le site qui le remplit, comme meta keywords » — est imparable tant qu'aucune signature n'existe. Les outils sont là : signatures de messages HTTP (RFC 9421), clé publiée en DNS TXT. Un fichier auto-déclaré et non signé aura toujours exactement la valeur probante d'une meta keywords de 2003.

8. Interdire l'impératif — ou le baliser.

Tant qu'aucun mécanisme ne distingue une description d'une instruction, le format devrait interdire les ordres, ou imposer une section ## Agent instructions nettement délimitée que les agents traitent comme des données non fiables. Le cas Stripe n'est pas un abus isolé : c'est le premier symptôme.

Et pour finir : mesurez-le.

Aucune de ces propositions ne vous dispense du geste le plus simple. Un accès à /llms.txt, c'est une ligne dans vos journaux de serveur. Filtrez sur les user-agents des robots IA, comparez avec vos pages HTML, et vous saurez en une semaine si ce fichier sert à quelque chose chez vous. C'est la seule donnée qui vous concerne vraiment. Toutes les autres, y compris les miennes, sont les moyennes de quelqu'un d'autre.

Verdict : faut-il en mettre un en 2026 ?

Il n'y a pas une réponse, il y en a quatre.

Et une règle qui vaut pour tous : ne payez personne pour écrire votre llms.txt. C'est vingt minutes de travail, ou zéro si vous le générez. La seule chose qui mérite du budget, c'est de vérifier ensuite que les robots passent vraiment — et ça, ce sont vos journaux qui le disent, pas un prestataire.

Pour le reste, ma position n'a pas bougé depuis notre premier article sur le sujet : le fichier ne nuit pas, il coûte presque rien, et si l'usage décolle un jour vous serez en place. Ce qui a changé, ce sont les données. On sait maintenant, chiffres à l'appui, que ce n'est pas un levier de visibilité IA — et on commence à comprendre ce que c'est vraiment : un outil pour les agents de code, mal nommé et mal casté.

Note de transparence : Snorklee publie son propre llms.txt, à la racine, avec une mise en garde écrite dedans. Nous appliquons donc exactement ce que nous recommandons : le poser, ne pas y croire, et le mesurer.