Pour prolonger cette lecture, vous pouvez comparer ce sujet avec Comment mesurer la visibilité dans la recherche IA quand l’attribution ne suffit plus, puis approfondir la logique avec Voir si des concurrents font de la pub dans les réponses ChatGPT.
LLMs.txt : ce que Google dit vraiment dans cette séquence
Le point de départ n’est pas un billet de blog officiel de Google, mais un échange relayé par Search Engine Journal le 2 juin 2026. Le débat part d’une question posée sur Reddit : faut-il lire la documentation Search Central, la mention de llms.txt dans Lighthouse/Chrome, ou les deux comme si elles décrivaient la même chose ? C’est précisément là que beaucoup de sites se trompent. Google ne parle pas d’un seul produit, mais de plusieurs couches documentaires qui ne répondent pas à la même question.
Dans ce contexte, John Mueller répond à propos de llms.txt que le sujet est « purely speculative for now ». C’est la formule utile à retenir, parce qu’elle ne dit ni que le fichier est interdit, ni qu’il serait déjà adopté. Elle dit autre chose : Google ne présente pas llms.txt comme une fonctionnalité en service, mais comme une hypothèse dont l’usage réel n’est pas établi dans l’échange relayé.
Le même article de SEJ précise aussi que la documentation Chrome/Lighthouse ne dit pas exactement ce que certains ont cru lire. Elle qualifie llms.txt d’« emerging convention » et indique que, sans ce fichier, des agents IA « may spend more time crawling » le site pour comprendre sa structure générale et son contenu principal. Il faut lire ce « may » comme une possibilité, pas comme une promesse. Autrement dit : Chrome suggère un cas d’usage possible, mais ne documente pas une adoption effective à ce stade.
La première décision à prendre est donc simple : ne mélangez pas une page d’aide Search Central, une note d’audit Chrome et une réponse Reddit comme s’il s’agissait d’un même signal produit. Le dossier parle d’un site, d’un agent, d’une convention émergente et d’une hypothèse d’usage. Ce n’est pas la même chose qu’une fonctionnalité Google Search, ni qu’un signal de classement, ni qu’un support officiel d’IA déjà en production.
Pourquoi Google parle de spéculation, pas d’un usage établi
Le mot « speculative » est central. Dans le sens où Mueller l’emploie dans l’échange relayé par SEJ, il sert à marquer l’absence de preuve d’usage observé et documenté, pas à nier qu’un standard puisse un jour émerger. En pratique, cela signifie qu’on ne peut pas transformer llms.txt en priorité de chantier sur la base d’une intuition ou d’un effet d’annonce.
Mueller va même plus loin dans sa logique : il souligne qu’aucun système d’IA ne semble utiliser llms.txt à ce jour, dans le cadre de cette discussion. Là encore, il faut rester précis. Il ne fournit pas une enquête exhaustive sur tout l’écosystème IA mondial. Il signale seulement qu’à l’état actuel du débat, aucun usage documenté ne justifie de traiter le fichier comme un levier opérationnel confirmé.
C’est là qu’il faut distinguer trois niveaux souvent confondus :
- une convention émergente mentionnée dans une documentation de navigateur
- une recommandation implicite de compatibilité pour des agents qui visiteraient déjà le site
- un usage réel et observé par des systèmes d’IA
Tant que ces trois niveaux ne convergent pas, llms.txt reste un objet de veille, pas un chantier prioritaire. Cela ne veut pas dire qu’il faille l’ignorer pour toujours. Cela veut dire qu’un fichier statique ne doit pas prendre la place d’un audit d’accessibilité réel, surtout si le site a déjà des problèmes de blocage, de rendu, de structure ou d’interprétation du contenu.
Ce que cela change pour la lecture des signaux Google
Pour les équipes SEO et content, la nuance compte. Un signal documentaire n’est pas un signal de visibilité. La question n’est pas « Google en parle-t-il ? », mais « que me dit Google sur l’usage concret et la priorité d’action ? ». Sur ce point, llms.txt n’apporte pas la même certitude qu’un élément de mesure dans Search Console, ou qu’un test officiel de reporting. Pour ce type de lecture, vous pouvez prolonger l’analyse avec <a href="https://laveritetoutecrue.fr/article/rapport-ai-search-google-search-console-mesurer-ia-sans-donnees">le rapport AI Search dans Search Console</a>, qui traite justement des signaux incomplets et de la façon de ne pas les surinterpréter.
LLMs.txt ne répond pas à la même question que la visibilité dans Google Search
C’est le second malentendu à corriger. Beaucoup de lecteurs entendent « visibilité IA » et pensent immédiatement à Google Search, aux AI Overviews ou à la présence dans les réponses génératives. Or llms.txt ne traite pas cette question-là. Il ne dit pas si une page peut être découverte, indexée, sélectionnée ou reprise dans un environnement de recherche. Il tente, au mieux, de décrire une surface lisible pour des agents qui arrivent déjà sur le site.
Cette différence change tout. Pour Google Search et les expériences de recherche IA, les sujets concrets restent l’indexabilité, la qualité des pages, la clarté des entités, la structure éditoriale, les données exploitables et la capacité de Google à comprendre le contenu. Pour l’usage agentique, la question est plutôt : un agent peut-il accéder au site, le charger, comprendre les étapes, accomplir une tâche et sortir avec un résultat fiable ?
Autrement dit, on ne résout pas un problème de visibilité Search avec un fichier pensé pour la lisibilité par agent. Et on ne résout pas un problème d’exécution par agent avec une simple promesse d’indexation. Les deux couches peuvent coexister, mais elles ne se substituent pas l’une à l’autre.
Mini cas 1 : site éditorial
Un média ou un site de contenu veut générer un llms.txt « pour mieux parler aux IA ». Sur le papier, l’idée rassure. En pratique, le vrai problème peut être ailleurs : pages rendues en JavaScript, ressources bloquées, navigation confuse, balises incohérentes, contenu principal mal isolé. Dans ce cas, produire un fichier supplémentaire avant d’avoir vérifié l’accessibilité réelle revient à décorer une porte que les agents n’ouvrent peut-être même pas.
La bonne hiérarchie est donc : d’abord vérifier ce qui bloque l’accès, ensuite seulement réfléchir à un fichier annexe si une plateforme le demande explicitement. Pour un éditeur, la question utile n’est pas « ai-je un llms.txt ? », mais « mes pages sont-elles lisibles, récupérables et interprétables par les systèmes qui vont les visiter ? »
WebMCP : pourquoi Mueller le met en avant à la place
Dans sa réponse relayée par SEJ, Mueller dit apprécier l’approche WebMCP. Le statut de WebMCP mérite, lui aussi, de la prudence : il s’agit d’une proposition technique liée au Model Context Protocol, et la mention de SEJ indique qu’elle est actuellement supportée dans Chrome. Ce que l’échange met en avant n’est pas un slogan, mais un objectif très concret : permettre à un agent de faire quelque chose de précis sur le site une fois qu’il y est déjà.
C’est le point décisif. WebMCP ne cherche pas seulement à résumer une structure pour un lecteur machine. Il vise des interactions plus opérationnelles : comprendre un prix final, comparer des produits, remplir un formulaire, poursuivre un parcours, exécuter une tâche. Mueller cite d’ailleurs des exemples de ce type dans la discussion relayée : déterminer le prix final d’un produit, avec frais et remises, ou accomplir une action utile sur le site.
Le contraste avec llms.txt est clair. Le premier décrit une tâche réalisable ; le second reste un fichier déclaratif dont l’utilité effective n’est pas démontrée dans la séquence citée. Pour un responsable SEO ou content, cela ne veut pas dire qu’il faut tout miser sur WebMCP demain matin. Cela veut dire que, si l’objectif est l’exécution de tâches par des agents, cette piste répond à une question plus concrète que celle d’un simple inventaire textuel.
Mini cas 2 : e-commerce ou services
Un site e-commerce se demande si llms.txt pourrait aider à faire comprendre les gammes, les prix ou le parcours d’achat. Dans le cadre de Mueller, le vrai sujet n’est pas de livrer un fichier qui résume la boutique, mais de faire en sorte qu’un agent puisse, si besoin, naviguer, comparer, ajouter au panier et lire le prix réel. La même logique vaut pour un site de services : le point utile n’est pas de décrire une prestation en langage machine, mais de permettre de trouver une offre, comprendre les conditions, identifier les étapes et contacter l’entreprise.
Cela change aussi la manière d’arbitrer les priorités. Si votre tunnel est cassé, si un agent ne peut pas charger les pages de catalogue, si les boutons ne sont pas accessibles ou si les parcours sont ambigus, llms.txt n’apporte rien d’immédiat. WebMCP, ou toute approche orientée tâche, sera plus pertinente à surveiller que la création d’un fichier statique sans usage documenté.
Le vrai point d’attention pour la plupart des sites : les agents sont-ils bloqués ?
Mueller termine son raisonnement par un point que l’article de SEJ présente comme probablement le plus important : le premier niveau d’optimisation agentique consiste à ne pas bloquer les agents. Il le formule comme une appréciation, pas comme une loi générale du web. Mais pour la plupart des sites, cette observation est plus utile qu’un débat abstrait sur un fichier de plus.
Concrètement, cela veut dire vérifier les couches qui empêchent un agent d’entrer, de lire ou d’agir. Robots mal configurés, restrictions involontaires, pages qui s’effondrent sans JavaScript, formulaires qui refusent l’automatisation, pages critiques rendues illisibles par des dépendances trop lourdes : ce sont des problèmes réels, observables, et souvent plus coûteux qu’un éventuel manque de llms.txt.
Avant de se demander si un fichier est « compatible IA », il faut donc répondre à une question plus brutale : un agent peut-il accéder à vos contenus et y accomplir une tâche simple sans se heurter à un mur technique ? Si la réponse est non, le chantier est là.
Checklist courte de priorité
- vérifier si des robots, agents ou systèmes d’IA sont bloqués par des règles techniques
- tester si les pages utiles s’affichent correctement sans dépendre d’un rendu fragile
- contrôler si les parcours clés sont lisibles et utilisables par une machine
- mesurer ce que Google expose déjà sur la visibilité IA avant d’ajouter une couche théorique
- ne créer un llms.txt que s’il existe une demande explicite d’une plateforme, d’un agent ou d’un cadre technique établi
Si vous cherchez une manière plus structurée de vérifier ce que Google laisse voir sur la présence IA, un second repère utile est <a href="https://laveritetoutecrue.fr/article/google-teste-rapport-ai-search-search-console-ce-que-ca-change">l’article sur les rapports dédiés à la visibilité IA dans Search Console</a>. Il aide à distinguer ce qui relève de la mesure, de la présence et de l’accessibilité.
Ce que cela change pour un éditeur, un e-commerce ou une marque de services
Pour un éditeur, la décision à court terme est claire : ne pas lancer un chantier llms.txt sur la seule base d’une mode éditoriale ou d’un post LinkedIn. Si le site est déjà bien structuré, indexable et lisible, la vraie valeur se trouve d’abord dans le contrôle des accès, de la qualité de rendu et de la clarté des pages. Si le site est fragile, llms.txt est un contournement symbolique, pas une correction.
Pour un e-commerce, la priorité n’est pas d’écrire un manifeste lisible par machine, mais de vérifier si un agent peut réellement parcourir l’offre, lire les prix, comprendre les variantes et exécuter une action sans blocage. Dans le cadre décrit par Mueller, c’est là que se joue l’intérêt des approches agentiques, pas dans la publication d’un fichier déclaratif à vocation encore hypothétique.
Pour une marque de services, le tri est similaire. Un llms.txt n’améliorera pas magiquement la compréhension d’une promesse commerciale, d’un devis ou d’un tunnel de conversion. En revanche, un site qui expose mal ses formulaires, masque ses conditions ou empêche l’accès automatisé à ses pages utiles crée un problème plus immédiat que l’absence de fichier. Dans ce cas, la question est d’abord technique et documentaire, pas philosophique.
La seule situation où il devient rationnel d’investir dans llms.txt dès maintenant est assez étroite : une plateforme ou un agent clairement identifié le demande, ou votre équipe veut tester ce format dans un cadre où l’usage est explicitement recherché. En dehors de ce cas, le statut « purely speculative for now » reste le meilleur résumé du moment.
Autrement dit, si votre enjeu est la visibilité dans Google Search ou dans les surfaces de recherche IA, vous devez traiter la mesure et l’interprétation des signaux existants. Si votre enjeu est l’usage par des agents, vous devez d’abord leur ouvrir la porte. llms.txt peut rester en veille tant qu’aucun système ne le réclame vraiment.