llms.txt

llms.txt est un index en texte brut d’un site conçu pour les modèles plutôt que pour les navigateurs : un titre, un résumé en une ligne et une liste de liens vers les pages qui méritent d’être lues. Docsbook génère automatiquement llms.txt et llms-full.txt pour chaque espace de travail — aucune configuration, aucune étape de compilation, rien à maintenir manuellement à jour.

Cette page explique exactement ce que Docsbook place dans ces fichiers, puis — puisque cette page porte sur des affirmations honnêtes et lisibles par les machines — quelle est réellement la solidité des preuves en faveur de llms.txt. La version courte de la seconde moitié : publiez-le, son coût est nul, n’attribuez-lui aucun résultat.

Où Docsbook fournit-il ces fichiers ?#

Les quatre sont fournis sous forme de text/plain; charset=utf-8 et ne nécessitent aucune authentification. Un espace de travail publié sur un chemin du domaine apex — une démo de présentation comprise, puisqu'une démo est un espace de travail — obtient la même paire sur ce chemin, limitée au seul projet nommé dans l'URL, de sorte qu'un robot d'exploration qui récupère l'index d'un produit ne reçoit jamais les pages d'un autre produit.

Chaque page est répertoriée à son URL canonique. Un espace de travail dont les pages sont canoniques sur le domaine apex n'est jamais annoncé sur son sous-domaine miroir, car cet hôte redirige et répond Disallow: / dans robots.txt. Fournir à un robot d'exploration une liste d'URL qu'on lui indique de ne pas récupérer est pire que de ne lui fournir aucune liste.

Que contient exactement le fichier llms.txt de l’espace de travail ?#

Markdown, dans cet ordre : un H1 contenant le nom de l’espace de travail ou du produit, un bloc de citation résumant ce que contient la documentation et où elle se trouve, un H2 par dépôt connecté, puis sous chaque H2 une liste à puces de [page title](canonical URL) pour chaque page Markdown publiée. Ensuite vient une section À propos de cet espace de travail — la partie destinée aux agents plutôt qu’aux robots d’exploration :

## About this workspace
 
- Hosted by: [Docsbook](https://docsbook.io) — AI-native documentation platform
- MCP server (manage this workspace via AI agent): https://docsbook.io/api/mcp/server
- Skills catalog (AI agent instructions for docs tasks): https://docsbook.io/skills
- Last generated: 2026-09-05T09:14:22.104Z
 
> To connect an AI agent to this workspace: `claude mcp add --transport http docsbook https://docsbook.io/api/mcp/server`

Trois comportements méritent d’être connus :

• Le H1 nomme le produit, pas le compte. Un fichier limité à un seul dépôt porte le nom d’affichage de cet espace de travail ; seul un fichier couvrant l’ensemble du compte porte l’identifiant de connexion du compte. Le H1 est la première chose qu’un assistant cite lorsqu’on lui demande ce qu’est un produit, et l’identifiant de connexion du compte est généralement une mauvaise réponse.
• Un espace de travail vide renvoie tout de même un fichier valide — le H1, une ligne indiquant qu’aucune documentation publique n’est encore indexée, et un lien vers l’accueil. Un index vide est un fait ; une erreur 404 est un mystère.
• Une page qui ne peut pas être récupérée est ignorée, et non considérée comme une erreur fatale. llms-full.txt est assemblé page par page ; si un fichier est inaccessible, une erreur est consignée et cette page est exclue, au lieu de faire échouer l’ensemble de la requête.

Dans llms-full.txt, chaque page apparaît sous son propre H2 avec une ligne Source: contenant son URL canonique, et ses métadonnées YAML sont supprimées. La ligne source permet à un assistant de citer la page d’où provient une phrase plutôt que de citer le bundle.

llms.txt ou llms-full.txt — lequel un agent préfère-t-il ?#

llms.txt       — compact index: page titles and links, one line each
llms-full.txt  — the full Markdown body of every page, concatenated

Utilisez l’index lorsque l’agent a besoin d’une carte et récupérera les pages à la demande ; utilisez le fichier complet lorsqu’il souhaite disposer de l’intégralité de la base de connaissances en une seule requête et que sa fenêtre de contexte le permet. Il existe une troisième surface pour le cas intermédiaire : chaque page est disponible au format Markdown brut à l’adresse /api/md/<owner>/<repo>/<page path>, et la même route sans chemin de page renvoie tous les fichiers Markdown du dépôt concaténés. C’est la route utilisée par l’option Afficher en Markdown dans le menu de la page.

En quoi llms.txt est-il différent de sitemap.xml ?#

Ils répondent à des questions différentes et aucun ne remplace l’autre.

Docsbook génère les deux, et audit_geo vérifie les deux.

À quelle fréquence est-il actualisé ?#

Docsbook régénère le fichier à partir de vos pages publiées sur demande et met le résultat en cache pendant une heure (Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400). Une page que vous publiez sur GitHub apparaît dans l’heure qui suit la prochaine récupération. Il n’y a aucune étape de compilation, aucun fichier à valider et aucun quota — un agent peut le récupérer aussi souvent qu’il le souhaite.

Que puis-je modifier concernant ce qu’un agent voit ?#

Trois choses, et seulement trois :

1. Nommez bien vos fichiers. Le texte des liens dans llms.txt provient du chemin du fichier, et non du frontmatter de la page title. api-rate-limits.md devient « Limites de débit de l’API » ; un README.md à la racine du dépôt devient « Vue d’ensemble » ; page2.md devient « Page2 », et aucun modèle ne le sélectionnera.
2. Publiez la page. Seuls les fichiers Markdown commités sur la branche par défaut sont répertoriés. Les brouillons et les modifications non poussées ne figurent dans aucun des deux fichiers.
3. Rédigez le premier paragraphe sous forme de réponse. llms-full.txt contient le corps textuel tel quel, donc ce qui ouvre la page est ce qu’un assistant lit en premier.

Quelle est la solidité des preuves en faveur de llms.txt ?#

Faible, et Docsbook ne prétendra pas le contraire. Voici l'ensemble des éléments, dans les deux sens.

Ce que le fichier vous apporte malgré tout. Un agent auquel vous fournissez l'URL — dans un prompt, un client MCP ou un processus d'assistance — obtient en une seule récupération une vue complète et actuelle de votre documentation, au lieu de l'explorer. Votre serveur MCP et votre catalogue de compétences peuvent être découverts à partir de celui-ci. Il peut être comparé par différences, ce qui en fait un inventaire peu coûteux de ce qui est effectivement publié. Et il ne vous coûte rien, puisque Docsbook le génère.

Ce qu'il ne vous apporte pas. Aucune indication sur le trafic provenant des assistants. Si vous voulez savoir si les assistants lisent votre documentation, mesurez ce qui laisse une trace : les accès des robots provenant des agents utilisateurs des assistants et le trafic référent provenant des domaines des assistants. Les deux sont visibles dans vos analyses ; un fichier accessible à une URL ne constitue pas à lui seul une preuve de quoi que ce soit.

Limites et questions ouvertes#

• Le texte du lien ignore votre title de frontmatter. Une page intitulée « Limites de débit et quotas » dans le frontmatter est répertoriée comme « Limites de l'API » si tel est le nom du fichier. Renommez le fichier ou acceptez le titre dérivé.
• llms-full.txt n'a aucune limite de taille. Un espace de travail volumineux produit un fichier qui peut dépasser la fenêtre de contexte d'un agent ; il n'y a ni pagination ni troncature. Préférez llms.txt ainsi que des récupérations page par page au-delà de quelques dizaines de pages.
• Docsbook ne propose pas les variantes de page .md de la spécification. La proposition demande « une version Markdown épurée de ces pages à la même URL que la page originale… avec .md ajouté ». Docsbook propose à la place le Markdown brut à l'adresse /api/md/…, qui contient le même contenu à une adresse différente et ne correspond pas à ce qu'un client respectant la spécification rechercherait.
• Le cache d'une heure n'est pas configurable, pas plus que le contenu du fichier. C'est intentionnel — il n'existe pas de seconde copie lisible par machine de votre documentation susceptible de diverger — mais cela signifie que vous ne pouvez pas contrôler ce qu'un agent voit.
• Question en suspens : est-ce que tout cela est lu par les assistants qui comptent ? La documentation du robot du fournisseur décrit des robots d'exploration qui récupèrent des pages ; rien n'y décrit la récupération de llms.txt. Tant qu'un fournisseur ne documente pas cette utilisation, ou que quelqu'un ne publie pas de preuves issues des journaux du serveur contredisant la mesure d'Ahrefs ci-dessus, considérez ce fichier comme une simple mesure d'hygiène gratuite plutôt que comme un canal.

Contenu associé#

• GEO — les signaux au niveau de la page : bloc TL;DR, dates visibles, attribution à l’auteur.
• Signaux de citation — les règles rédactionnelles qui déterminent si un passage récupéré est cité.
• SEO — plan du site, URL canoniques, noindex.
• Serveur MCP — l’interface machine pour les agents qui écrivent aussi bien qu’ils lisent.
• Source de vérité — le graphe documentaire local, pour un agent disposant de votre dépôt sur le disque.