Bonnes pratiques

Dix règles

1. Curez. Une liste courte de pages à fort signal vaut mieux qu'une liste longue de pages médiocres. Dix à trente liens peuvent servir de point de départ, mais les tâches visées doivent déterminer le nombre.
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 une notice 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 le libellé Optional avec parcimonie. C'est un repère éditorial clair pour les communiqués, assets de marque et archives, mais la v2 ne lui attribue aucune sémantique machine particulière.
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 pour un besoin d'ingestion défini. Un corpus documentaire consolidé peut aider un consommateur connu, mais augmente aussi les coûts de taille, de fraîcheur et de sécurité.
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. Les en-têtes YAML ou JSON sont hors de la grammaire publiée et peuvent conduire un parseur conforme à rejeter ou mal lire le fichier.
• Tableaux ou images Markdown collés. Gardez un préambule ciblé et utilisez des listes de liens dans les sections H2. Les structures supplémentaires compliquent le parsing et dupliquent souvent les pages liées.
• 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 chaque note seulement assez longue pour distinguer sa destination.
• Lister 500 URLs sans périmètre. Reprenez les tâches visées, séparez les vraies frontières de contenu dans des fichiers de chemin, ou fournissez une ressource complète à un consommateur identifié.
• Bloquer involontairement la ressource. Vérifiez que chaque fichier déclaré, racine ou propre à un chemin, reste joignable selon la politique de crawl voulue.

Sites multilingues

La proposition n'impose aucune architecture d'internationalisation. Deux choix sont courants :

1. Un fichier dans la langue par défaut à la racine. Le choix le plus simple lorsque les ressources listées et les consommateurs visés partagent une langue.
2. Variantes par locale. Servez /llms.txt (défaut), /fr/llms.txt, /es/llms.txt. Liez-les depuis le corps du fichier racine, sous une section Optional, ou déclarez le fichier applicable avec rel="describedby" sur les pages localisées.

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. Tout client qui récupère le fichier public peut les voir.
• 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.

Traitez le fichier comme une configuration externe, sans supposer que les agents lui obéissent. Dans l'analyse Ahrefs de 137 210 domaines, la chaîne de user-agent la plus présente dans la catégorie recherche était prompt-injection-survey/1.0. Ce libellé ne prouve ni une attaque ni son opérateur, mais rappelle l'intérêt d'un contenu factuel, d'une revue des changements et d'un agent contraint.

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.