Un fichier llms txt est un document markdown à la racine de votre domaine qui décrit ce qu’est le site et pointe vers les pages qui valent la peine d’être lues. L’idée emprunte son emplacement au robots.txt mais pas son objectif. Le robots.txt dit aux robots d’exploration ce qu’il faut éviter. Ce fichier indique à un modèle de langage où se trouve la substance, dans un format qu’il peut lire en un seul passage sans avoir à naviguer à travers la navigation, les bannières de cookies et les pieds de page.
C’est une proposition, pas une norme, et c’est la première chose à clarifier avec un client. Aucun assistant majeur ne s’est engagé à le lire, et en publier un ne vous garantit pas d’être cité. Nous le recommandons toujours pour la plupart des sites avec une documentation réelle ou une bibliothèque de contenu approfondie, car cela coûte une heure, cela ne peut pas faire de mal, et l’exercice de l’écrire fait ressortir des problèmes qui valent la peine d’être corrigés de toute façon.
Ce qui doit figurer dans un fichier llms txt
La convention est un markdown simple. Un seul H1 avec le nom du site ou de l’organisation. Une courte citation en bloc résumant ce que vous faites en une ou deux phrases. Ensuite, des sections H2 regroupant les liens, chaque lien étant suivi de deux points et d’une brève description du contenu de la page. Limitez-vous aux pages qui contiennent des informations, pas à l’ensemble du plan du site. Une centaine de liens bien choisis valent mieux qu’un vidage de chaque URL.
Les descriptions sont la partie que les gens bâclent et la partie qui compte. Une ligne ne contenant que le titre de la page ne dit rien au lecteur qu’il ne pourrait obtenir en consultant la page. Une ligne indiquant à quelle question la page répond et pour qui permet à un modèle de décider s’il doit l’ouvrir ou non, ce qui est tout l’intérêt du document.
En rédiger un qui soit réellement utile
Considérez-le comme un briefing pour un étranger compétent avec un temps limité. Que doivent-ils savoir sur votre organisation, et quels dix ou trente documents leur remettriez-vous en premier ? Ce cadre produit un bien meilleur fichier que de le traiter comme un artefact technique à générer.
Quelques règles que nous appliquons à chacun de ceux que nous écrivons :
- Servez-le à la racine sous forme de texte brut ou de markdown, pas derrière une redirection ou une réécriture.
- Utilisez des URL absolues, afin que le fichier ait du sens lorsqu’il est lu en dehors de son origine.
- Décrivez chaque lien en une phrase claire plutôt que de répéter son titre.
- Regroupez les liens sous des titres qu’un humain reconnaîtrait : docs, tarifs, guides, politiques.
- N’incluez que les pages que vous seriez heureux de voir citées, et gardez-le en dessous de quelques centaines de lignes.
Certains sites publient également des versions étendues avec le texte intégral des pages clés intégré. Cela vaut la peine de le faire lorsque votre documentation est réellement volumineuse et fortement interconnectée. Pour un site marketing normal, cela ajoute une charge de maintenance sans retour observable, et une copie obsolète de votre page de tarifs est pire qu’aucune copie du tout.
Un détail pratique piège les gens. De nombreux systèmes de gestion de contenu ne serviront pas un fichier arbitraire à partir de la racine, et la solution de contournement choisie est souvent une redirection du chemin racine vers une page à l’intérieur du site. Un client récupérant l’adresse racine obtient alors une chaîne de redirection ou une page HTML au lieu du markdown, ce qui ruine l’exercice. Vérifiez la réponse avec une simple requête et confirmez que vous récupérez le texte avec un type de contenu sensé, sans la mise en page de votre thème enveloppée autour.
Ce qu’il ne fait pas
Il ne contrôle pas l’accès. Tout ce que vous listez est une page qui était déjà publique, et tout ce que vous voulez garder hors de l’entraînement ou de la récupération doit être géré par des directives robots.txt, l’authentification ou les contrôles spécifiques aux robots d’exploration que publient les principaux fournisseurs. Traiter ce fichier comme une couche d’autorisation est une erreur que nous avons dû corriger plus d’une fois.
Il ne remplace rien non plus. Votre plan du site continue de piloter la découverte, vos données structurées continuent de décrire les entités, vos règles robots continuent de régir l’exploration. Le fichier llms txt se situe à côté d’eux comme un résumé lisible par l’homme de ce qui compte, et si les assistants ne le lisent jamais, tout le reste de votre site fonctionne toujours exactement comme avant.
La maintenance est le coût réel
Des fichiers comme celui-ci pourrissent. Les liens bougent, les produits sont renommés, la page que vous avez mise en avant est fusionnée avec une autre. Un fichier rempli de redirections et d’impasses fait une pire impression que de n’en avoir aucun. Mettez-le sur le même cycle de révision que votre plan du site et votre navigation, vérifiez-le lorsque vous publiez un changement de site, et supprimez les entrées que vous ne maintenez plus plutôt que de les laisser se dégrader.
Notre recommandation est proportionnée : écrivez-en un, gardez-le court et honnête, révisez-le trimestriellement et ne le laissez pas devenir un projet. La valeur réside principalement dans les effets secondaires. Décider quelles trente pages représentent votre site, et écrire une phrase précise sur chacune, tend à exposer un contenu pauvre, des explications en double et des pages que personne n’a pu résumer. Ces conclusions valent l’heure passée même si aucun robot d’exploration ne demande jamais le fichier.
Continuez à lire : GEO
Service associé: GEO – AIO – AEO