Vous avez probablement lu qu'il fallait « ajouter un llms.txt ». Vous avez peut-être aussi lu que Google déclare ne pas l'utiliser. Les deux sont exacts, et l'agacement vient de ce que personne ne précise pour qui le fichier est écrit. Ce guide répond à trois questions dans l'ordre : ce que le fichier est, qui le lit, et s'il vaut votre temps.
Ce qu'est llms.txt, exactement
llms.txt est une convention proposée en septembre 2024 par Jeremy Howard (Answer.AI) et documentée sur llmstxt.org. Le principe : un fichier Markdown, servi en texte brut à /llms.txt, qui présente le site à un modèle de langage — ce qu'est l'organisation, quelles pages font autorité, où se trouve la documentation propre. C'est une table des matières éditorialisée, pas un fichier de permissions.
La confusion la plus fréquente est de le traiter comme un robots.txt. robots.txt dit ce qui est interdit et suit une norme réelle, RFC 9309. llms.txt dit ce qui compte, n'interdit rien, et n'est normalisé par personne. Un crawler qui ignore votre llms.txt ne viole aucune règle.
La seconde confusion porte sur le sitemap. Un sitemap XML est exhaustif et destiné à une machine qui indexe : il liste tout, sans hiérarchie de sens. llms.txt est sélectif et destiné à une machine qui résume : il liste peu, avec une phrase d'explication par lien. Si votre llms.txt contient vos 800 URLs, vous avez écrit un sitemap dans le mauvais format.
Le format, ligne par ligne
La structure attendue tient en quatre éléments : un titre H1 (le nom de l'entité), un bloc de citation qui résume le site en une ou deux phrases, des sections H2 contenant des listes de liens au format Markdown avec une description après le deux-points, et une section facultative — souvent nommée Optional — pour ce qui peut être ignoré si le contexte manque de place.
# Riad Zitoun
> Riad de 8 chambres dans la médina de Marrakech, ouvert toute l'année,
> propriété familiale depuis 1998. Réservation directe, sans intermédiaire.
## Pages de référence
- [Les chambres](https://exemple.ma/chambres): les 8 chambres, superficie, literie, prix par saison
- [Le petit-déjeuner et la table d'hôtes](https://exemple.ma/table): horaires, menus, allergènes
- [Nous trouver](https://exemple.ma/acces): adresse exacte, dépose taxi, parking gardé le plus proche
- [Conditions d'annulation](https://exemple.ma/conditions): délais, remboursements, arrhes
## Faits vérifiables
- Adresse : 12 derb Zitoun, médina, Marrakech 40000, Maroc
- Téléphone : +212 5 24 00 00 00
- Chambres : 8 · Capacité : 19 personnes · Enregistrement : à partir de 14h
- Langues parlées : arabe, français, anglais, espagnol
## Optional
- [Journal du riad](https://exemple.ma/journal): billets saisonniers, utile mais pas essentiel
Trois détails font la différence entre un fichier lu et un fichier ignoré. Les URLs doivent être absolues : le fichier est souvent lu hors contexte, un lien relatif n'a alors plus de base. La description après le deux-points doit être informative — « nos services » ne sert à rien, « prix par saison et politique d'annulation » oriente réellement la lecture. Et le fichier doit être court : il est lu en même temps que la question de l'utilisateur, dans une fenêtre de contexte partagée.
Ce que Google en dit — la version non commentée
Le 15 mai 2026, Google a publié un guide d'optimisation pour les fonctionnalités génératives de la recherche. Sa position sur les fichiers de ce type est écrite noir sur blanc dans le guide lui-même : il n'est pas nécessaire de créer de nouveaux fichiers destinés aux machines, de balisage particulier ou de Markdown pour apparaître dans Google Search, y compris ses fonctionnalités génératives, parce que Google Search ne les utilise pas. Le maintien d'un llms.txt n'améliore ni ne dégrade le classement.
Cette clarté est une bonne nouvelle : elle déplace la discussion du terrain de la croyance à celui de l'audience. La vraie question n'est pas « est-ce que ça marche », c'est « qui le lit ? ».
Qui lit réellement ce fichier
Trois familles de lecteurs, très différentes, avec des enjeux très différents.
- Les agents et assistants de développement. Les outils qui travaillent sur du code — assistants d'IDE, agents de documentation — vont chercher un llms.txt parce qu'il leur épargne le parsing d'une page rendue en JavaScript. C'est aujourd'hui l'usage le plus établi et le plus mesurable.
- Les agents à la demande. Lorsqu'un utilisateur colle votre URL dans un assistant, la requête part immédiatement, avec un User-Agent identifiable (
ChatGPT-User,Claude-User,Perplexity-User). Ce trafic-là est déclenché par un humain qui vous a déjà en tête : c'est la visite la plus qualifiée de votre journal. - Les outils tiers de l'écosystème GEO. Tableaux de bord de visibilité, moteurs de recherche pour agents, annuaires spécialisés. Ils sont petits pris un à un, mais ce sont eux qui alimentent les comparatifs sur lesquels d'autres modèles s'appuient ensuite.
Ce que cette liste ne contient pas est aussi important : ni Googlebot, ni l'indexation classique. llms.txt est un fichier destiné aux agents, pas aux moteurs de recherche. Traitez-le comme tel et il cesse d'être décevant.
Vérifiez qui vous lit — trois commandes
La théorie ne remplace pas vos journaux. Sur un serveur Apache ou nginx, une seule ligne vous dit si un agent a déjà demandé le fichier :
# Qui a demandé llms.txt, et avec quel User-Agent ?
grep 'llms.txt' /var/log/nginx/access.log | awk '{print $1, $12, $13, $14}' | sort | uniq -c
# Quels agents IA sont passés cette semaine, toutes URLs confondues ?
grep -Ei 'GPTBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Google-Extended|Bytespider' \
/var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Le fichier répond-il vraiment 200, en texte brut, sans redirection surprise ?
curl -sSI -L https://votre-domaine.com/llms.txt | grep -Ei 'HTTP/|content-type|location'
Le troisième contrôle attrape la panne la plus courante et la plus invisible : un soft-404. Beaucoup d'hébergements renvoient la page d'accueil, avec un code 200, pour n'importe quelle URL inconnue. Votre llms.txt « existe » donc pour tout vérificateur naïf, alors qu'il sert du HTML. C'est un défaut que nous avons corrigé dans notre propre audit après l'avoir vu passer : un fichier absent qui répond 200 est pire qu'un 404, parce qu'il se signale comme sain.
llms.txt, llms-full.txt, /ai/index.md, sitemap.xml : lequel fait quoi
| Fichier | Lecteur visé | Contenu | Effet sur Google Search |
|---|---|---|---|
| /llms.txt | Agents, outils de dev | Résumé + liens choisis, ~1–3 Ko | Aucun (documenté) |
| /llms-full.txt | Agents disposant d'un grand contexte | Le contenu de référence en entier, en Markdown | Aucun |
| /ai/index.md | Agent qui veut une page précise | Le jumeau Markdown d'une page HTML donnée | Aucun |
| /sitemap.xml | Moteurs de recherche | Toutes les URLs, avec dates | Oui — c'est son rôle |
| JSON-LD (schema.org) | Moteurs et modèles | Les faits de l'entité, typés | Oui — résultats enrichis |
Un point d'attention sur le jumeau Markdown : si la même URL peut répondre en HTML ou en Markdown selon l'en-tête Accept, le serveur doit renvoyer Vary: Accept. Sans cela, un cache intermédiaire peut servir du Markdown au visiteur humain suivant. Nous nous sommes fait prendre sur notre propre domaine ; la règle est désormais posée sans condition.
Les sept erreurs qui rendent le fichier inutile
- Y recopier le sitemap. 400 liens sans description ne disent rien à un modèle ; ils consomment du contexte et repoussent l'information utile.
- Des URLs relatives. Le fichier est lu hors de son contexte d'origine ;
/chambresn'y résout plus. - Des descriptions promotionnelles. « Le meilleur riad de Marrakech » n'est pas un fait exploitable. « 8 chambres, ouvert toute l'année, annulation gratuite jusqu'à 48 h » l'est.
- Des faits invérifiables. Un modèle qui vous cite engage sa propre fiabilité ; il privilégie ce qu'il peut recouper sur votre site.
- Le laisser pourrir. Un fichier qui annonce des horaires de 2024 produit une citation fausse — pire qu'aucune citation.
- Le mettre ailleurs qu'à la racine. C'est
https://domaine.com/llms.txt, pas un sous-dossier. - Le servir en HTML. Le
Content-Typedoit êtretext/plain. Une page d'erreur stylée qui répond 200 compte comme un fichier manquant.
Alors, faut-il l'écrire ?
Verdict honnête, en deux lignes. Si vous attendez un gain de classement Google : non, la documentation dit l'inverse et personne ne peut vous promettre autre chose. Si votre audience comprend des développeurs, si votre produit est documenté, ou si vous voyez déjà passer ChatGPT-User et Claude-User dans vos journaux : oui, parce qu'écrire deux kilo-octets coûte une demi-heure et que le fichier travaille pour ces lecteurs-là.
Le vrai bénéfice est d'ailleurs souvent indirect. Pour écrire un bon llms.txt, il faut décider quelles sont les cinq pages qui font autorité, formuler ce que fait l'entreprise en une phrase, et lister des faits vérifiables. La plupart des sites découvrent à ce moment-là qu'ils ne savent pas répondre — et cette clarification-là profite à tout le reste : au JSON-LD, aux méta-descriptions, et à la page d'accueil.