Si vous envisagez de créer un fichier llms.txt pour améliorer votre position dans Google, il ne devrait pas passer avant les véritables problèmes de votre site. La documentation de la recherche Google indique que ce fichier n’améliore ni ne pénalise la visibilité dans les résultats, y compris dans ses fonctionnalités d’IA générative. Fournir un index utile à un agent qui consulte votre documentation est une autre question : il peut alors y avoir une raison concrète de faire un essai.
La question se complique parce que Lighthouse propose lui aussi un audit appelé llms.txt. Cela paraît contradictoire tant que l’on ne distingue pas ce que chaque produit évalue. Une vérification liée à la navigation par des agents ne fait pas de ce fichier une exigence SEO.
Qu’est-ce que llms.txt ?
C’est un fichier Markdown qui présente un site ou un projet et organise des liens vers les informations pertinentes. Il ressemble à un index commenté de documentation : il propose un parcours de lecture, tandis que les détails restent dans les pages vers lesquelles il renvoie.
La proposition maintenue par Jeremy Howard, disponible en anglais, a été publiée en septembre 2024 et révisée en août 2026. Elle reste une proposition, pas une obligation universelle pour les sites web.
Il faut savoir à qui ce fichier est destiné. Le publier n’oblige pas un assistant à le consulter, à suivre ses liens ou à citer votre entreprise. Avant d’installer un générateur, posez-vous cette question : quel système utilisera cet index, et pour quelle tâche ?
Pourquoi Google Search et Lighthouse semblent se contredire
Le guide de Google sur les fonctionnalités d’IA générative limite ses recommandations à la recherche Google. Dans sa section consacrée aux idées reçues sur l’optimisation pour l’IA, il explique que la recherche ignore ces fichiers. En maintenir un pour un autre système est tout à fait possible, mais cela n’apporte aucun avantage de classement dans Google.
La documentation de l’audit llms.txt de Lighthouse relève, elle, de la navigation par des agents, c’est-à-dire de leur interaction avec les sites web. Elle décrit deux comportements importants : une erreur serveur lors de la récupération du fichier est signalée ; une réponse 404, lorsque le fichier n’existe pas, est considérée comme non applicable, puisque sa présence est facultative.
Il faut donc interpréter une alerte de cet audit dans son périmètre. Elle ne démontre pas une baisse de classement et ne prouve pas que la publication du fichier incitera une IA à recommander l’entreprise.
Comparer les documents pour éclairer la décision
Cette analyse compare les deux documentations officielles et la proposition du format, consultées le 31 octobre 2026. La même question a été posée à chaque source : que permet-elle de conclure sur la nécessité du fichier ?
| Source examinée | Constat | Décision étayée |
|---|---|---|
| Google Search Central | La recherche Google ignore le fichier. | Ne pas justifier sa mise en place par un gain de classement dans Google. |
| Lighthouse, navigation par des agents | L’absence avec une réponse 404 est non applicable ; une erreur serveur est signalée. | Examiner un problème de mise à disposition du fichier séparément de la décision de le proposer. |
| Proposition llms.txt v2 | Un index peut orienter les agents vers des contenus pertinents. | Évaluer le format lorsqu’un système utilisateur et une tâche sont clairement définis. |
Cette comparaison évite deux erreurs de priorité. La première consiste à transformer toute alerte d’un outil en urgence SEO. La seconde est d’écarter une ressource documentaire uniquement parce qu’elle n’influence pas Google. L’objectif du travail détermine la manière de l’évaluer.
Un exemple public : l’index de la documentation FastHTML
Le fichier public de FastHTML, en anglais, montre une utilisation de la proposition. Lors de la consultation, il présentait le projet, indiquait des précautions d’utilisation et regroupait les liens en sections : documentation, API, exemples et ressources facultatives.
Un détail est particulièrement utile : avant les liens, le texte prévient que la bibliothèque n’est pas compatible avec la syntaxe de FastAPI. Cette indication vise à éviter une erreur précise d’implémentation. La valeur proposée consiste à aider une personne ou un agent à utiliser correctement un outil.
Le fichier contient aussi un lien vers un guide concis en Markdown. Il sert de point d’entrée vers cette ressource, au lieu de réunir toute la documentation dans un seul bloc.
Cette inspection permet de constater l’organisation du fichier public. Elle ne mesure ni le nombre d’agents qui le consultent, ni une éventuelle diminution de leurs erreurs, ni un gain de trafic pour FastHTML. Ces résultats nécessiteraient une autre étude. L’auteur n’a aucune relation professionnelle avec le projet analysé.
Quand ajouter ce fichier aux travaux à prévoir
Si vous gérez un petit site vitrine dont certaines pages importantes sont difficiles à trouver, dont les informations sont obsolètes ou dont la navigation présente des problèmes, commencez par ces points. Un index supplémentaire devrait suivre les mêmes évolutions et pourrait devenir une autre source d’informations contradictoires.
Pour une documentation technique volumineuse, la décision peut être différente. Si l’équipe utilise déjà des agents pour consulter des références, il peut être utile de tester un index court sur une tâche délimitée : trouver les bonnes instructions d’authentification, par exemple. Définissez qui maintiendra le fichier et comment les liens seront vérifiés après les modifications.
La priorité dépend de l’objectif. Synthèse des sources officielles consultées le 31/10/2026 ; les critères sont détaillés dans le texte.
Pour décider de lancer un essai pilote, je poserais trois questions :
- Un système utilisateur est-il identifié ? Nommez l’agent, l’intégration ou le processus qui doit lire l’index. « Les IA » est trop vague pour guider un test.
- Existe-t-il un problème observable ? Consignez la difficulté actuelle, par exemple la consultation d’une ancienne version d’une référence ou l’impossibilité de trouver une instruction nécessaire.
- La maintenance est-elle réalisable ? Désignez un responsable et prévoyez une méthode pour actualiser les liens et les descriptions en même temps que la documentation.
Si les réponses manquent encore, gardez la mise en place à l’état d’hypothèse. Vous pourrez y revenir lorsqu’un besoin concret se présentera.
llms.txt, robots.txt et sitemap ont des rôles différents
Le robots.txt donne des consignes d’exploration. Il ne protège pas les informations privées et, à lui seul, ne garantit pas qu’une URL soit absente des résultats de Google.
Le sitemap aide les moteurs de recherche à découvrir les URL et fournit des informations sur les fichiers du site. Sa présence ne garantit pas que tous les éléments seront explorés ou indexés.
Le llms.txt fournit du contexte et une sélection de liens aux systèmes qui choisissent de l’utiliser. Il ne remplace pas ces mécanismes. Ne l’utilisez pas non plus comme contrôle d’accès : publier une instruction pour un agent ne protège pas le contenu vers lequel elle renvoie.
Tester sans confondre accès et résultat
Un essai pilote utile commence par une tâche et une réponse vérifiable. Choisissez une question dont la solution figure dans la documentation, consignez la version de l’agent et comparez des exécutions équivalentes avec et sans index. Si le processus permet de fournir le fichier manuellement, précisez-le : remettre l’index à l’agent ne démontre pas qu’il le découvre automatiquement.
Conservez les pages consultées, la réponse finale et les erreurs relevées. Répétez la tâche, car une exécution isolée peut varier. Une requête vers le fichier dans les journaux du serveur atteste d’une requête, pas d’une lecture utile, d’une citation ou d’une vente. Une hausse du trafic après publication ne permet pas non plus d’isoler l’effet de ce changement.
Cet article présente une analyse documentaire et une procédure d’évaluation proposée. Aucune expérience sur un gain de classement ou sur les performances des agents n’a été réalisée. Les recommandations et la proposition peuvent évoluer ; consultez de nouveau les sources avant de faire de cette conclusion une exigence permanente.
Ce sujet relève de la catégorie SEO technique et international, consacrée à l’exploration, à l’indexation et à l’architecture des sites.
Pour découvrir mon travail en développement web, SEO technique et données, consultez ma présentation professionnelle. Si votre équipe cherche à définir les priorités de son site, échangeons sur WhatsApp.
Analyse documentaire réalisée avec l’aide de l’IA. Sources consultées le 31/10/2026. La couverture est un montage illustratif.