Bonnes pratiques

Dix règles

1. Curez. Une liste courte de pages à fort signal vaut mieux qu'une liste longue de pages médiocres. Visez 10 à 30 liens dans le fichier racine.
2. Utilisez des URLs absolues. Toujours https://votredomaine.com/.... Les URLs relatives sont techniquement autorisées mais fragiles.
3. Groupez par surface produit. Des sections comme Produit, Tarifs, Développeurs reflètent la manière dont un utilisateur (et un LLM) pense. Évitez les buckets blog/doc/guide sauf s'ils correspondent à votre vraie navigation.
4. Gardez le résumé factuel. Le blockquote après le H1 doit se lire comme un ouverture Wikipedia, pas comme un hero de landing.
5. Une phrase par item. La note après les deux-points sert à désambiguïser, pas à vendre.
6. Utilisez la section Optional avec parcimonie. C'est l'endroit pour communiqués, assets de marque et archives. N'y déversez pas la moitié de votre sitemap.
7. Reflétez vos URLs stables. Si une page de llms.txt bouge, mettez-la à jour ou redirigez. Les URLs périmées polluent la réputation du fichier.
8. Publiez llms-full.txt si le contenu est textuel. Documentation, tutoriels et référence en bénéficient. Galeries, outils interactifs et contenu principalement visuel non.
9. Lancez le validateur en CI. Une migration de contenu qui casse votre fichier doit faire échouer le build.
10. Datez votre fichier. Une note courte comme « Dernière revue 2026-04-01 » dans le corps est utile pour humains et crawlers.

Erreurs courantes

• Pas de H1. Le H1 est le seul élément strictement obligatoire. Sans lui, le fichier est invalide.
• Plusieurs H1. Utilisez des H2 pour les sections. Il doit y avoir exactement un H1.
• Front-matter custom. Pas de YAML, pas d'en-tête JSON. La spec est stricte ; les clients ne liront pas les extras.
• Tableaux / images Markdown collés. Restez sur heading + blockquote + listes. Tableaux et images n'apportent rien à un LLM.
• URLs derrière un login. Si une page nécessite auth, ne la listez pas — le LLM heurtera un mur.
• Descriptions trop longues. « La plateforme la plus avancée au monde propulsée par IA pour la transformation synergique next-gen » n'aide personne. Gardez les notes sous 15 mots.
• Lister 500 URLs. Si vous en avez besoin, vous avez besoin de llms-full.txt, de variantes par produit, ou des deux.
• Oublier de mettre à jour robots.txt. Assurez-vous que /llms.txt n'est pas bloqué.

Sites multilingues

La spec est silencieuse sur l'internationalisation. Deux patterns fonctionnent :

1. Un seul fichier anglais à la racine. Le plus simple. La plupart des clients LLM traduisent à la volée. Suffisant pour la plupart des sites.
2. Variantes par locale. Servez /llms.txt (défaut), /fr/llms.txt, /es/llms.txt. Liez-les depuis le corps du fichier racine ou sous une section Optional.

Peu importe le pattern choisi, ne dupliquez pas les ensembles d'URLs entre locales : chaque variante doit pointer vers la version localisée de chaque page.

Sécurité et vie privée

• Tout ce qui est dans llms.txt est public. Traitez le fichier comme une diffusion.
• Ne listez jamais d'URLs de staging ou preview. Elles seront récupérées par tout ce qui télécharge le fichier.
• Pas d'URLs avec secrets dans les query strings. Ça semble évident ; on l'a vu en production.
• Si la page expose des données utilisateur derrière auth, elle n'a rien à faire ici.
• Auditez le fichier à chaque release. Une URL de draft fuitée est l'erreur de sécurité la plus courante.

Automatisation en CI

Traitez llms.txt comme n'importe quel artefact : générez, validez, et conditionnez les releases sur son statut.

• Générez-le depuis votre source de contenu (CMS, collection MDX, base).
• Lancez le validateur en CI ; échec du build sur toute erreur.
• Diff du fichier entre releases ; alerte au docs owner sur les grosses suppressions.
• Smoke-test de l'URL prod après déploiement : curl -fsS https://votredomaine.com/llms.txt | head -1.

Continuer

• Bénéfices et limites — ce à quoi s'attendre.
• Exemples réels — copier ce qui marche.
• Validateur.