/ llmtxt.info
English

Format llms.txt — référence complète

Référence complète du format llms.txt : les 4 règles fondamentales, exemples annotés, syntaxe des liens, section Optional, checklist et erreurs courantes.

Dernière mise à jour:

Aperçu du format

llms.txt est un fichier texte brut en CommonMark Markdown placé à la racine d’un domaine (https://example.com/llms.txt). Il sert de carte curée pour les modèles de langage IA — analogue au robots.txt pour les crawlers, mais centré sur ce qu’il faut lire, pas sur ce qu’il faut éviter.

Les assistants IA, pipelines RAG et agents de recherche utilisent ce fichier pour comprendre rapidement ce qu’un site propose et quelles URL contiennent la documentation de référence. Un llms.txt bien structuré est bien plus utile que de laisser un modèle crawler des pages arbitraires.

Les 4 règles fondamentales

  1. Un seul H1 en tête — la première ligne doit être un H1 (# Nom du site). Un seul H1, en tout premier, avant tout autre contenu.
  2. Un blockquote immédiatement après — juste après le H1, un résumé factuel en une ou deux phrases (> description). Pas de marketing, pas de mots-clés — une description utile pour un LLM.
  3. Sections en H2 — les rubriques suivantes sont des H2 (## : Produit, Docs, Intégrations…). Pas de H1 supplémentaire.
  4. Liens en liste avec note — chaque lien suit le format : - [Titre](https://url-absolue): courte note. Les URL doivent être absolues (https://).
llms.txt — exemple minimal valide 
# Nom de votre projet

> Une phrase décrivant ce que fait votre projet et à qui il s'adresse.

## Documentation

- [Démarrage rapide](https://example.com/docs/demarrage): Installation et premiers pas.
- [Référence API](https://example.com/api): Catalogue complet des endpoints.

## Optional

- [Changelog](https://example.com/changelog): Historique des versions.

Exemple annoté complet

Un SaaS ou une plateforme développeur veut généralement une structure plus complète avec plusieurs sections et une section Optional dédiée :

llms.txt — exemple complet 
# Acme SaaS

> Acme SaaS aide les équipes à automatiser leurs workflows de facturation grâce
> à un tableau de bord sans code et une API REST compatible avec 40+ prestataires.

## Produit

- [Présentation](https://acme.com/product): Capacités clés et cas d'usage.
- [Tarifs](https://acme.com/pricing): Plans, limites et options entreprise.
- [Statut](https://status.acme.com/): Disponibilité et historique des incidents.

## Documentation

- [Démarrage rapide](https://acme.com/docs/quickstart): Configuration en moins de 5 minutes.
- [Référence API](https://acme.com/docs/api): Endpoints REST, auth, rate limits.
- [SDK](https://acme.com/docs/sdks): Clients Node, Python, Ruby, Go.
- [Webhooks](https://acme.com/docs/webhooks): Payloads d'événements et politique de retry.

## Exemples

- [Intégration Node.js](https://acme.com/examples/node): Flux de paiement complet.
- [Intégration Python](https://acme.com/examples/python): Gestion des abonnements.

## Optional

- [Changelog](https://acme.com/changelog): Historique des versions.
- [Blog](https://acme.com/blog): Mises à jour produit et tutoriels.
- [GitHub](https://github.com/acme/acme-oss): Composants open source.

Sections optionnelles

Les sections sont des H2 (##) suivis de listes non ordonnées de liens Markdown. Noms de sections courants :

  • Documentation — docs principales, guides, références.
  • Produit — pages marketing, tarifs, statut.
  • Exemples — extraits de code, tutoriels, démos.
  • Intégrations — partenaires et SDK, une ligne chacun.
  • API — section dédiée à la référence API.
  • Optional — changelog, blog, GitHub — priorité basse pour l’IA.

Syntaxe des liens

Chaque lien suit la syntaxe Markdown : - [Titre](URL): description courte.

  • Utilisez des URL absolues avec le schéma (https://).
  • La description après les deux-points est du texte brut — gardez-la sous ~120 caractères et rendez-la informative pour un LLM, pas bourrée de mots-clés.
  • Un lien par item de liste — pas de puces imbriquées.
  • Préférez les URL canoniques (avec slash final si c’est votre convention).

La section ##Optional

La section nommée Optional a une signification particulière dans la spec : les systèmes IA peuvent ignorer les liens qu’elle contient quand le contexte est contraint. Utilisez-la pour les liens utiles mais non essentiels : changelog, blog, assets de marque, communiqués de presse.

Ne mettez pas votre documentation principale dans Optional — elle risque d’être ignorée par les parseurs IA les plus conservateurs.

Checklist

  • Fichier servi à /llms.txt (chemin racine, pas un sous-répertoire)
  • Content-Type: text/plain; charset=utf-8
  • Commence par exactement un H1
  • Blockquote résumé sur la ligne immédiatement après le H1
  • Toutes les URL sont absolues (https://)
  • Chaque lien a une description concise après les deux-points
  • Fichier sous 20 Ko
  • Aucune balise HTML, aucune liste imbriquée
  • Validé avec le validateur llms.txt

Erreurs courantes

  • URL relatives — - [Docs](/docs) ne se résoudra pas correctement quand le fichier est récupéré par un crawler IA. Utilisez toujours des URL absolues.
  • Blockquote manquant — sauter le > résumé rend le fichier plus difficile à parser et non conforme à la spec.
  • Content-Type incorrect — servir avec text/html ou sans content-type fait rejeter le fichier par certains parseurs.
  • Bourrage de mots-clés dans les descriptions — les LLM lisent ces descriptions littéralement. Le bourrage de mots-clés dégrade la qualité du signal.
  • Lister toutes les pages — curez vos 10 à 30 liens les plus importants. Le sitemap exhaustif va dans llms-full.txt, pas dans l’index.

Guides associés

Sources