Validateur llms.txt

Huit points, tous tirés de la spécification llmstxt.org. Il cherche un H1 unique donnant le nom du site, une citation résumant ce que fait le site, des sections H2 regroupant les liens par thème, et des liens Markdown suivis d’une description après les deux-points. Il contrôle ensuite que les liens sont absolus, que le fichier reste léger, et que le serveur renvoie bien du texte brut et non une page HTML.

Ce dernier contrôle attrape de loin l’échec le plus fréquent. Un serveur sans llms.txt renvoie souvent la page d’accueil du site au lieu d’une erreur 404 : le fichier semble donc présent dans un navigateur tout en ne contenant rien d’exploitable par un modèle.

Parce qu’un fichier llms.txt est conçu pour être extrait de votre site et chargé dans une fenêtre de contexte. Une fois là, un lien écrit /docs/demarrage n’a plus d’origine à laquelle se rattacher. Le modèle ne peut pas le suivre, et l’entrée devient du poids mort dans un budget que vous payez déjà.

C’est toute la différence avec un sitemap. Un sitemap est lu par un crawler qui sait d’où il vient. Un llms.txt est lu par un modèle qui a pu recevoir le texte via trois intermédiaires. Les URLs absolues sont la seule forme qui survit à ce trajet.

Oui. Basculez l’outil en mode collage et déposez le contenu directement. Rien n’est récupéré et rien n’est conservé : le fichier est analysé et noté sur place.

C’est le mode que nous recommandons pendant la rédaction. Publier un fichier, découvrir qu’il est mal formé, le corriger puis redéployer est une boucle lente pour une vérification qui prend quelques secondes. Cela permet aussi de valider des fichiers de sites que vous ne contrôlez pas, ce qui sert quand vous auditez un client ou regardez comment un concurrent a structuré le sien.

Non, et l’outil valide contre une spécification communautaire et non ratifiée. Le format a été proposé par Answer.AI en septembre 2024 et documenté sur llmstxt.org, mais il n’a été adopté ni par le W3C ni par l’IETF, et aucun grand éditeur d’IA ne s’est engagé à le lire.

Ce qui s’est produit est une adoption sans ratification. Les assistants de code et les cadriciels d’agents le récupèrent pour construire leur contexte, et un nombre croissant de sites de documentation en publient un. La position honnête est que le fichier coûte quelques minutes et porte une option sur un écosystème qui va clairement vers du contenu structuré au moment de l’inférence.

Parce que llms.txt est l’index et non le contenu. La spécification sépare délibérément les deux : llms.txt porte la carte, llms-full.txt porte le territoire. Un fichier qui dépasse la centaine de kilooctets a généralement cessé d’être une carte.

Le coût est réel. Tout ce qui entre dans une fenêtre de contexte en chasse autre chose : un index gonflé évince le contenu dont le modèle a besoin pour répondre. Un fichier resserré de vingt ou trente liens bien décrits l’emporte à chaque fois sur un fichier exhaustif, pour la même raison qu’un bon sommaire vaut mieux qu’une photocopie du livre entier.

Il supprime de la friction, ce qui vaut quelque chose sans valoir tout. Un fichier bien formé indique au modèle ce que couvre votre site et quelles pages comptent, sans qu’il ait à le déduire du HTML exploré. Pour les agents et les assistants de code qui le récupèrent directement, l’effet est immédiat et mesurable.

Pour un assistant grand public répondant à une question générale, l’effet est au mieux indirect. Aucun n’a confirmé le lire au moment de la requête. Traitez ce fichier comme une infrastructure que vous mettez en place à bas coût, et non comme un levier qui déplace les citations à lui seul, puis consacrez l’effort économisé au contenu dont ces citations dépendent réellement.