Sous-chemins llms.txt : benchmark de 113 sites
Les fichiers par chemin sont au cœur de llms.txt v2. Un crawl reproductible montre qu’ils existent déjà, mais le résultat doit être interprété avec précision.
Dernière mise à jour:
Un fichier llms.txt par chemin peut offrir à un agent une carte plus petite et plus pertinente qu’un fichier unique pour tout le domaine. Notre premier benchmark a trouvé au moins un fichier distinct sur un sous-chemin courant pour 21 des 113 hôtes qui servaient déjà un fichier racine vérifié.
À retenir
- 21 hôtes ont répondu avec un fichier H1 distinct sur au moins un chemin testé.
- Le test couvre quatre chemins courants, pas toutes les localisations possibles.
- Un fichier secondaire n’est utile que s’il correspond à une vraie frontière de contenu.
Quel est le résultat du benchmark ?
Le 12 août 2026, 21 des 113 hôtes vérifiés ont aussi renvoyé un fichier texte distinct commençant par un H1 sur au moins une de ces URL : /docs/llms.txt, /documentation/llms.txt, /help/llms.txt ou /api/llms.txt. Le test exclut les redirections, les pages de secours HTML, les réponses sans H1 et les corps identiques au fichier racine.
Ce nombre n’est pas un taux d’adoption mondial. Le dénominateur contient uniquement les hôtes de notre annuaire vérifié, et le numérateur uniquement les quatre chemins testés. Un fichier placé ailleurs échappe au test.
Comment le test a été réalisé
Le script part d’un snapshot fixe, pas d’un échantillon fourni par un moteur. Pour chaque origine, il demande quatre chemins, suit les redirections et ne compte que les réponses valides contenant un H1 Markdown.
Le contrôle du H1 réduit les faux positifs provenant des pages 404 personnalisées et des fallbacks d’applications. Il ne certifie pas toute la structure. Utilisez le validateur et examinez la réponse avant de vous y fier.
L’agrégat est publié dans v2-adoption-stats.json. Le panel fixe et la méthodologie restent publics afin de comparer les prochaines exécutions sur la même base.
Quand un fichier de sous-chemin est utile
Un fichier séparé se justifie quand le contenu possède son propre public, vocabulaire ou cycle de publication. Documentation, API, centre d’aide ou cours sont de bons candidats. Un agent travaillant sous /docs/ peut alors sélectionner /docs/llms.txt au lieu de charger une carte générale.
Ne multipliez pas les fichiers uniquement parce que la proposition le permet. Les duplications augmentent la maintenance et créent des descriptions contradictoires. Définissez un propriétaire, générez les liens depuis la même source et conservez un fichier racine capable d’orienter vers la carte spécialisée.
La checklist de migration v2 explique le déploiement. Les bonnes pratiques couvrent ensuite la curation.
Limites et checklist
Le benchmark ne dit pas si un agent a découvert ou utilisé les fichiers. Il ne teste pas tous les chemins, les zones authentifiées ni la qualité sémantique. Il ne permet pas non plus d’attribuer une performance Search à ces fichiers.
- Choisissez un chemin représentant une frontière stable.
- Limitez les liens au contenu réellement couvert.
- Ajoutez
rel="describedby"aux pages concernées si possible. - Testez la règle du fichier le plus spécifique.
- Mesurez les requêtes dans les logs.
Peut-on publier seulement /docs/llms.txt ?
Oui. V2 autorise les fichiers sous la racine. Leur découverte dépend du client et des signaux publiés.
Faut-il répéter la liste racine ?
Généralement non. La répétition annule l’avantage contextuel. La racine oriente, le sous-chemin détaille.
Cela aide-t-il Google à indexer la section ?
Google dit ne pas utiliser llms.txt comme signal spécial. Pour Search, utilisez sitemap, liens internes, crawlabilité et contenu utile.