Migration llms.txt v2 : checklist pratique

La version 2 ne transforme pas llms.txt en facteur de classement Google. Elle étend la proposition d’un fichier racine vers un système de découverte par chemin destiné aux agents. Migrez seulement si les agents compatibles font partie de votre usage, tout en conservant le fichier existant pendant les tests.

À retenir

• Le H1 reste le seul élément obligatoire du fichier.
• Un fichier plus spécifique peut décrire uniquement les pages sous son chemin.
• Les versions Markdown et describedby facilitent la découverte, pas le ranking.

Que change llms.txt v2 ?

La proposition autorise désormais un llms.txt à la racine ou sous n’importe quel chemin. /docs/llms.txt peut décrire /docs/, tandis que le fichier racine décrit le site dans son ensemble. Si plusieurs fichiers s’appliquent, l’agent doit choisir le plus spécifique.

V2 propose aussi des versions Markdown propres des pages. Une page peut les annoncer avec rel="alternate" type="text/markdown" et identifier le fichier applicable avec rel="describedby". Ces relations peuvent être envoyées dans le HTML ou dans un en-tête HTTP Link.

Le format reste volontairement simple. Le H1 est obligatoire. Le résumé, le préambule, les sections H2 et les descriptions de liens sont optionnels. Optional reste un libellé éditorial utile, mais la v2 ne lui attribue aucune sémantique de traitement particulière. Consultez la référence du format avant de rendre un validateur plus strict que la proposition.

Faire l’inventaire avant de modifier

Relevez chaque fichier actuel, redirection, type de contenu et consommateur connu. Un fichier racine qui répond déjà en HTTP 200 doit continuer à le faire. Déplacer son URL uniquement pour adopter v2 casserait les clients qui connaissent la convention racine.

Découpez le site selon de vraies frontières. Une documentation dense peut justifier /docs/llms.txt; un petit site marketing, probablement pas. Les fichiers de chemin doivent retirer le contexte inutile, pas recopier le fichier racine.

Vérifiez que les versions Markdown sont réellement propres. N’annoncez pas une conversion vide, une page d’erreur ou un contenu obsolète. La page HTML reste canonique pour Search ; la ressource Markdown représente le même contenu pour les clients compatibles.

La séquence de migration

1. Validez le fichier racine avec le validateur llms.txt.
2. Conservez son URL et corrigez uniquement les erreurs réelles.
3. Définissez chaque portée avant de créer un fichier secondaire.
4. Générez HTML et Markdown depuis la même source.
5. Ajoutez alternate et describedby dans le template HTML.
6. Testez statuts HTTP, types MIME, redirections et liens dans la CI.
7. Publiez sur un périmètre limité, observez les logs, puis élargissez.

Le guide des bonnes pratiques traite la curation et la sécurité. Comparez aussi les exemples vérifiés sans confondre publication et utilisation.

Vérification et limites

Notre benchmark du 12 août 2026 a contrôlé 294 pages liées depuis 113 réponses racine commençant par un H1. Trente et une des 286 pages joignables annonçaient une version Markdown et quatre exposaient rel="describedby". C’est une mesure d’implémentation, pas une preuve de préférence des agents.

Google indique que Search n’utilise pas llms.txt ni les fichiers texte IA spéciaux. Une migration réussie produit donc des ressources stables, bien délimitées et mesurables. Elle ne garantit aucun gain de classement.

Faut-il remplacer le fichier racine ?

Non. V2 conserve la racine et ajoute des options par chemin. Préservez les URL stables sauf défaut documenté.

Chaque page doit-elle avoir une version Markdown ?

Non. L’alternative est utile pour les pages textuelles. Une page visuelle ou interactive peut ne pas avoir d’équivalent pertinent.

Google doit-il indexer le Markdown ?

Google peut crawler plusieurs types de fichiers, sans traitement spécial. Gardez le HTML canonique et ne promettez aucun effet SEO.