Google Search, Lighthouse, llms.txt et WordPress

Le débat actuel sur llms.txt est facile à mal lire.

Un camp dira :

Google dit que llms.txt n’est pas nécessaire, donc c’est inutile.

L’autre dira :

Lighthouse vérifie llms.txt, donc c’est sûrement un facteur de classement.

Les deux lectures sont trop faibles.

La meilleure interprétation est que la visibilité Search et la préparation à la navigation agentique sont deux couches différentes.

Le guide Google Search indique qu’un site n’a pas besoin de créer llms.txt, des fichiers IA spéciaux, des versions Markdown ou du balisage IA particulier pour apparaître dans les fonctionnalités génératives de Search. La documentation expérimentale Agentic Browsing de Chrome Lighthouse vérifie toutefois llms.txt comme résumé lisible par machine à la racine du domaine.

Ce n’est pas une contradiction simple. C’est une distinction de produit et d’audit :

• Search demande si Google peut crawler, indexer, récupérer, classer et afficher du contenu utile.
• Agentic Browsing demande si un site est structuré pour l’interaction machine.

Les équipes WordPress doivent comprendre les deux.

Ce que Google Search dit

Google Search repousse les raccourcis superficiels d’« optimisation IA ».

Le message est essentiellement :

• n’inventez pas de balisage IA spécial pour apparaître dans les fonctionnalités génératives de Search ;
• ne supposez pas que llms.txt donne un traitement spécial ;
• ne réécrivez pas du contenu seulement pour les systèmes IA ;
• continuez à faire un vrai travail SEO ;
• rendez les pages crawlables, utiles, bien structurées et accessibles.

Ce guide est important parce qu’il limite le marché des faux raccourcis.

Un site WordPress ne devrait pas ajouter llms.txt parce qu’un vendeur promet des gains directs dans AI Overviews.

Ce que Chrome Lighthouse dit

Chrome Lighthouse pose une autre question.

Sa catégorie Agentic Browsing n’est pas un document de classement Search classique. C’est une surface expérimentale d’audit qui vérifie si un site possède des propriétés utiles pour l’interaction machine.

L’une de ces propriétés est un résumé lisible par machine, souvent exposé avec llms.txt.

Cela ne veut pas dire :

• que le fichier classe les pages ;
• que le fichier force le comportement des crawlers ;
• que tous les systèmes IA le consomment ;
• que tous les sites WordPress doivent l’avoir ;
• que réussir la vérification signifie que le site est prêt pour les agents.

Cela veut dire que le fichier devient visible dans un contexte d’audit développeur mainstream.

Et cela compte.

Le problème WordPress

WordPress est précisément l’endroit où cette distinction devient opérationnelle.

Plusieurs sites WordPress ont :

• des métadonnées générées par extensions ;
• plusieurs extensions SEO accumulées au fil du temps ;
• des archives automatiques ;
• des pages d’étiquettes désordonnées ;
• des alternates multilingues ;
• des transformations cache et CDN ;
• des constructeurs qui produisent un balisage complexe ;
• des formulaires difficiles à interpréter par machine ;
• des distinctions floues entre bots Search, bots d’entraînement et fetchers déclenchés par l’utilisateur.

Search peut quand même crawler le site. Cela ne veut pas dire que le site est facile à interpréter ou à utiliser par des agents.

Un bon robots.txt aide l’accès. Un bon llms.txt aide l’orientation. Une politique aide l’interprétation. Les pages sources aident la récupération. L’accessibilité et la stabilité d’interface aident l’interaction.

Aucune de ces couches ne remplace les autres.

Comment positionner Better Robots.txt

Better Robots.txt ne devrait pas être positionné ainsi :

Installez cette extension et classez-vous mieux dans l’IA parce que Lighthouse vérifie llms.txt.

Ce serait une surpromesse.

Le positionnement plus fort est :

Better Robots.txt aide les équipes WordPress à publier une couche cohérente de gouvernance du crawl et de guidage machine : robots.txt, segmentation des crawlers IA, llms.txt optionnel, signaux de politique et interprétation d’audit. Cette couche contribue à la préparation agentique, sans remplacer la qualité des pages sources, l’accessibilité, la stabilité d’interface, les logs ou l’enforcement runtime.

C’est plus exact et plus défendable.

Le modèle par couches

Couche	Question principale	Rôle de Better Robots.txt
Crawl Search	Les crawlers Search peuvent-ils atteindre les bonnes pages ?	Support fort avec robots.txt, sitemaps et hygiène de crawl
Posture crawlers IA	Les finalités des crawlers sont-elles séparées ?	Support fort avec règles IA et guidage d’audit
Résumé machine	Les machines peuvent-elles trouver rapidement les pages prioritaires ?	Support avec llms.txt et les pages de vérification
Gouvernance	La politique du site est-elle cohérente ?	Support avec signaux d’usage IA et fichiers de gouvernance
Qualité des pages sources	Existe-t-il des pages stables dignes d’être citées ?	Support indirect par le routage et la documentation, pas par la création de contenu
Préparation à l’interaction	Les agents peuvent-ils utiliser formulaires, boutons et workflows ?	Support limité ; exige accessibilité, UX, front-end et QA

Ce que les équipes WordPress devraient faire maintenant

1. Ne pas ajouter llms.txt dans la panique

Un fichier placeholder est faible. Ajoutez llms.txt seulement s’il est exact, maintenu et connecté à de vraies pages sources.

Lire : Audit Lighthouse llms.txt pour WordPress.

2. Ne pas bloquer l’IA à l’aveugle

Bloquer tous les crawlers à allure IA peut nuire à la découverte Search ou à la récupération déclenchée par l’utilisateur sans créer l’enforcement recherché.

Lire : Crawlers d’entraînement IA vs crawlers de recherche IA.

3. Corriger d’abord la base de crawl

Avant la préparation agentique, assurez-vous que le site ne brise pas la crawlabilité classique.

Lire : Vérificateur robots.txt pour crawlers IA.

4. Construire de vraies pages sources

Le meilleur fichier llms.txt ne rendra pas des pages faibles utiles. Si le site veut être cité, il lui faut des pages qui répondent à des questions concrètes.

Lire : Visibilité IA.

5. Auditer séparément la préparation à l’interaction

Un site peut réussir les vérifications robots.txt et llms.txt, mais rester difficile à utiliser pour des agents.

Lire : Lighthouse Agentic Browsing pour WordPress et Checklist de préparation agentique WordPress.

Conclusion stratégique

llms.txt n’est pas la révolution à lui seul.

Le signal important, c’est que la lisibilité machine passe de la théorie aux outils développeurs.

Les sites WordPress devront de plus en plus répondre à quatre questions distinctes :

1. Sommes-nous visibles dans Search ?
2. Sommes-nous clairs pour les systèmes de récupération IA ?
3. Sommes-nous gouvernés pour l’accès et l’usage machine ?
4. Sommes-nous utilisables par des agents ?

Better Robots.txt doit posséder la couche WordPress de gouvernance du crawl et de guidage machine dans cette pile.

C’est beaucoup plus fort que de prétendre qu’un fichier contrôle l’avenir de la recherche IA.

À lire ensuite

• Préparation agentique WordPress
• Lighthouse Agentic Browsing pour WordPress
• Audit Lighthouse llms.txt pour WordPress
• robots.txt, llms.txt et WebMCP
• La pile de fichiers de gouvernance machine

Références officielles

Cette interprétation s’appuie sur trois sources publiques :

• guide Google Search sur l’optimisation pour les fonctionnalités IA génératives : https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
• documentation Chrome Lighthouse sur l’audit llms.txt : https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt
• documentation Chrome Lighthouse sur le scoring Agentic Browsing : https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring