Validateur llms.txt

Comment vérifier un fichier llms.txt

Trois étapes, toutes sur cette page. Le validateur contrôle la structure définie sur llmstxt.org ; il ne va rien chercher sur votre site, alors collez le fichier et non l’URL.

1. Collez le fichier. Copiez le contenu de votre llms.txt (ou récupérez-le avec curl https://votredomaine.fr/llms.txt) et collez-le dans le cadre de gauche. La vérification démarre aussitôt, à chaque frappe.
2. Lisez les erreurs et les avertissements. Chaque constat porte un numéro de ligne. Les erreurs cassent le format qu’un agent analyse ; les avertissements sont des conventions utiles à suivre, mais qui ne violent pas la spécification.
3. Copiez la version corrigée. À droite se trouve une copie normalisée : puces, séparateurs et espacement réparés, tout ce qui demande une décision humaine laissé intact et signalé. Reversez-la à la racine de votre site sous /llms.txt.

Ce que vérifie le validateur

La vérification suit section par section la structure de la spécification llmstxt.org. Une erreur signifie qu’un agent lisant le fichier comme du Markdown le lira de travers ; un avertissement signifie que le fichier est valide mais laisse de la valeur de côté.

Pourquoi le format compte

llms.txt est un fichier Markdown publié à la racine d’un domaine qui donne aux grands modèles de langage un index court et trié du site : un H1 avec le nom du site, un résumé en citation, du texte libre facultatif et des listes de liens regroupées par H2, chaque lien portant une ligne de description. Ses lecteurs l’analysent mécaniquement : un agent de développement ou un outil de documentation récupère /llms.txt, le découpe en titre, résumé et sections, puis suit les liens qu’il y trouve. Un fichier dont le plan est cassé n’est pas « un peu faux » : le parseur jette la section qu’il n’a pas su lire, ou traite le fichier entier comme du texte, et l’agent va scraper votre site à la place.

Les règles étant peu nombreuses, les ratés habituels sont très ordinaires. Le nom du site écrit en texte courant au lieu de # Nom. Un sous-titre ### copié depuis la doc. Un paragraphe marketing sous un titre de section où seuls des liens ont leur place. Des liens relatifs comme /docs/ qui ne mènent nulle part dès que le fichier est lu hors contexte. Chacun se corrige en une ligne — encore faut-il que quelque chose vous dise laquelle.

Ce que le format ne fait pas : vous positionner. Google a déclaré que la Recherche ignore llms.txt, et les mesures de requêtes réelles montrent que la plupart des fichiers publiés ne sont jamais récupérés. Les preuves, et l’identité des lecteurs réels, sont dans notre article explicatif sur llms.txt (en anglais). Vérifiez le fichier parce que les agents qui lisent votre documentation l’analysent, pas parce qu’une checklist prétend que c’est bon pour le référencement.

Site bilingue : un fichier à la racine ou un par langue ?

La plupart des sites francophones techniques sont bilingues — une version française et une version anglaise, souvent sous /fr/ et /en/. La question qui se pose alors n’apparaît nulle part dans les guides anglophones, parce qu’elle ne se pose pas chez eux : faut-il un seul /llms.txt, ou un fichier par langue ?

La spécification y répond depuis la révision v2 d’août 2026 : un llms.txt peut se trouver à la racine ou à n’importe quel chemin du site, il couvre alors les pages situées sous ce chemin, et lorsque plusieurs fichiers s’appliquent, le plus spécifique l’emporte. Les deux montages sont donc légitimes :

• Un seul fichier à la racine, si le site tient en quelques dizaines de pages. Écrivez la description de chaque lien dans la langue de la page pointée, et regroupez les deux langues en sections distinctes (## Documentation et ## Documentation (English), par exemple). C’est le montage le plus simple à garder à jour, et le seul que les agents trouveront sans indication.
• Un fichier par sous-chemin — /fr/llms.txt et /en/llms.txt — dès que la liste unique dépasserait la centaine de liens, ou quand les deux versions du site n’ont pas le même périmètre. Chaque fichier reste court et cohérent dans une seule langue ; celui de la racine, s’il existe, sert de repli.

Deux détails qui ne se voient que sur un site non anglophone. D’abord, la section ## Optional garde son nom anglais : c’est une convention nommée, pas un mot à traduire, et ## Optionnel ne sera pas reconnu comme telle — ce validateur l’avertit d’ailleurs (voir le tableau ci-dessus). Ensuite, ce validateur vérifie un fichier à la fois : il ne peut pas vous dire si votre découpage par langue est le bon. Collez chaque fichier séparément.

Enfin, ne confondez pas ce fichier avec vos balises hreflang : llms.txt indexe le site pour un agent qui le lit à la demande, hreflang indique aux moteurs quelle version linguistique servir à quel visiteur. Les deux sont des surfaces machine, mais elles ne s’adressent pas au même lecteur — le générateur hreflang s’occupe de la seconde.

Ce que la version corrigée change, et ce qu’elle vous laisse

Le cadre de droite est une copie normalisée, pas une réécriture. Il répare ce qu’une machine peut réparer sans deviner votre intention :

• Puces — * et + deviennent -.
• Séparateur de description — - [Nom](URL) - description devient - [Nom](URL): description.
• Espacement — espaces de fin de ligne supprimés, suites de lignes vides réduites à une, une ligne vide entre les blocs.
• Titre manquant — un # Site name de remplacement est inséré pour que le plan soit valide ; remplacez-le.

Tout ce qui demande une décision reste volontairement intact : une URL relative reste relative et reste signalée, une ligne de texte dans une section reste où elle est, un lien en double est signalé plutôt que supprimé. L’ordre de vos entrées ne change jamais. Lisez la liste de gauche, corrigez ces points à la main, et le fichier passera.

Créer un llms.txt de zéro

Si vous n’avez pas encore de fichier, cliquez sur Insérer un modèle minimal. Vous obtenez la plus petite forme conforme : un titre, un résumé d’une phrase, une section de liens et une section ## Optional. Remplacez les lignes d’exemple par les vôtres et revérifiez.

Au-delà d’une poignée de pages, ne maintenez pas le fichier à la main : dérivez-le de l’inventaire de pages qui construit déjà votre sitemap, pour que les deux ne puissent pas se contredire sur le contenu du site. Le modèle de génération, avec un exemple complet, est décrit dans how to generate llms.txt from a sitemap (en anglais) ; clize.ai/llms.txt est produit ainsi et passe ce validateur.

Deux contrôles après publication, parce que ce sont ceux qui échouent en silence : curl -I https://votredomaine.fr/llms.txt doit renvoyer 200 avec un type de contenu text/plain ou text/markdown, et non une page 404 mise en forme servie en 200 ; et le fichier doit être accessible sans redirection vers une page HTML. Si vos pages ont elles aussi besoin d’une surface lisible par machine — un balisage FAQ conforme au texte visible, par exemple —, le générateur de schema FAQ suit la même règle : une seule source, aucune dérive.

$ npm i -g @clize/clize && clize install
$ clize seo check --domain votredomaine.fr