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

Aperçu du format

llms.txt est une ressource texte en CommonMark Markdown. Elle peut être placée à la racine ou sous un chemin plus précis comme https://example.com/docs/llms.txt. Le fichier applicable le plus spécifique décrit ce périmètre.

Les assistants de code, pipelines RAG et agents compatibles peuvent utiliser ce fichier comme carte curée. La publication ne prouve ni la découverte ni l'usage : déclarez-le avec rel="describedby" lorsque c'est pertinent et mesurez les clients réellement pris en charge.

La règle obligatoire et la structure optionnelle

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 optionnel peut suivre le H1 avec un résumé factuel en une ou deux phrases (> description).
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 optionnelle, chaque lien suit le format : - [Titre](https://url-absolue): courte note. Les URL absolues (https://) réduisent l'ambiguïté, sans être obligatoires dans la proposition.

# 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 :

# 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

Optional reste un libellé éditorial clair pour les liens secondaires comme le changelog, le blog ou les assets de marque. La v2 ne lui attribue aucune sémantique de traitement particulière.

Ne comptez pas sur le titre Optional pour déclencher un comportement client : utilisez-le uniquement pour rendre votre intention éditoriale compréhensible.

Checklist

• Fichier servi à la racine ou sous le chemin ciblé
• Type texte brut ou Markdown avec encodage UTF-8
• Commence par exactement un H1
• Blockquote et préambule optionnels sans titre
• Cibles de liens correctement résolues dans leur contexte de publication
• Notes de liens optionnelles, concises et factuelles
• Taille justifiée par les tâches et testée dans les clients visés
• 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, ce n'est pas une erreur de conformité en v2. Ajoutez-en un seulement s'il apporte un résumé utile.
• 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

• Comment créer llms.txt, pas à pas pour chaque stack.
• Format reference (EN), version anglaise de cette page.
• Validateur, vérifiez la conformité de votre fichier.
• Générateur, créez un fichier depuis un formulaire.
• Bonnes pratiques, ce qu’il faut inclure et éviter.