Aller au contenu principalSkip to content

Audit Lighthouse llms.txt pour WordPress

La conversation autour de llms.txt a changé parce que deux surfaces liées à Google créent maintenant de la confusion :

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

Pour les équipes WordPress, la bonne conclusion n’est pas « llms.txt ranke ».

La bonne conclusion est :

llms.txt entre dans la conversation sur la préparation agentique, mais reste une surface de guidage, pas une garantie de classement ou un mécanisme d’enforcement.

Ce que la vérification Lighthouse signifie vraiment

La vérification Lighthouse est étroite.

Elle demande si le site expose un résumé lisible par machine à l’emplacement attendu. La documentation Chrome décrit llms.txt comme une convention émergente pour résumer le contenu d’un site à destination des LLMs et des agents IA.

Cela rend le fichier utile comme couche d’orientation et de routage.

Cela ne prouve pas :

  • que Google Search utilise le fichier pour classer les pages ;
  • que AI Overviews ou AI Mode consomment le fichier de manière spéciale ;
  • que ChatGPT, Claude, Perplexity, Gemini ou d’autres systèmes utilisent le fichier ;
  • qu’une réponse a changé parce que le fichier existe ;
  • que les crawlers obéissent au fichier ;
  • que le site est prêt pour les agents.

Le fichier peut être utile sans être magique.

Pourquoi les sites WordPress devraient s’en préoccuper

Les sites WordPress exposent souvent des surfaces publiques complexes :

  • page d’accueil ;
  • articles de blogue ;
  • catégories ;
  • étiquettes ;
  • archives auteurs ;
  • archives de dates ;
  • pages médias ;
  • pages de recherche interne ;
  • produits WooCommerce ;
  • panier et commande ;
  • chemins de traduction ;
  • pages générées par extensions ;
  • documentation et support.

Un crawler ou un agent peut explorer cette structure, mais le site ne rend pas toujours ses priorités évidentes. Un llms.txt bien maintenu peut compresser l’intention publique :

  • ce qu’est le site ;
  • le produit ou service offert ;
  • les pages principales ;
  • les surfaces de support et de politique ;
  • où trouver le meilleur contexte ;
  • ce que le fichier n’autorise pas et ne prouve pas.

C’est utile même si ce n’est pas un facteur de classement.

Structure utile de llms.txt pour WordPress

Un bon llms.txt WordPress doit éviter le remplissage générique. Il doit router les machines vers les meilleures sources publiques.

SectionFonctionExemple WordPress
Résumé du siteExpliquer le site en un court paragrapheProduit, service, média, commerce local, documentation
Pages principalesIdentifier les pages canoniquesAccueil, fonctionnalités, tarifs, hubs services, hubs docs
Surfaces de politiqueClarifier usage et gouvernancerobots.txt, politique d’usage IA, fichiers de gouvernance
Pages sourcesPointer vers les pages riches en preuvesComparaisons, checklists, guides, cas, définitions
Contact et supportFournir une route de correction ou d’escaladePage contact, courriel support, documentation
LimitesEmpêcher les surlectures« Ce fichier est du guidage, pas de l’enforcement. »

Pour Better Robots.txt lui-même, le fichier doit pointer vers la page produit, le téléchargement de l’extension, la documentation de l’audit, les pages de gouvernance, les pages par crawler et le cluster de préparation agentique.

L’erreur : traiter Lighthouse comme l’objectif

Une implémentation superficielle cherche à « passer Lighthouse » avec un fichier minimal :

txt
# Example.com

This is our website.

Cela peut satisfaire une vérification de présence, mais cela n’aide pas vraiment les machines à comprendre le site.

Une implémentation plus forte utilise llms.txt pour exprimer une structure de routage maintenue :

txt
# Example.com — machine-readable summary

Canonical site: https://example.com/
Primary product: https://example.com/product
AI usage policy: https://example.com/ai-usage-policy
Robots policy: https://example.com/robots.txt
Source pages:
- https://example.com/definition/topic
- https://example.com/compare/product-a-vs-product-b
- https://example.com/case-study/example

Notice: this file provides guidance. It does not override robots.txt, authentication, legal terms, or runtime access controls.

La différence n’est pas la mise en forme. La différence est la qualité de la gouvernance.

Comment Better Robots.txt aide

Better Robots.txt donne aux équipes WordPress un workflow plus sûr, parce que llms.txt ne devrait pas être traité comme un fichier texte isolé.

Le fichier doit être aligné avec :

  • robots.txt ;
  • les règles par crawler IA ;
  • les déclarations de sitemaps ;
  • les signaux d’usage IA ;
  • les fichiers de gouvernance ;
  • les pages publiques de politique ;
  • l’architecture des pages sources ;
  • le vrai périmètre du produit ou de l’édition.

Lorsque ces couches se contredisent, les lecteurs machine peuvent surinterpréter, sous-interpréter ou router vers les mauvaises pages.

Better Robots.txt aide en intégrant llms.txt au même workflow de gouvernance du crawl que robots.txt, plutôt qu’en le traitant comme une pièce ajoutée après coup.

Ce que Better Robots.txt ne peut pas prouver

Une extension WordPress ne peut pas prouver que tous les systèmes IA externes vont :

  • récupérer llms.txt ;
  • respecter le fichier ;
  • le traiter comme autoritaire ;
  • modifier leurs réponses grâce au fichier ;
  • mieux classer le site ;
  • éviter les affirmations non soutenues.

Ces comportements sont externes. Certains exigent des logs, des tests de prompts, le suivi des URLs surfacées et des observations directes.

Le rôle de l’extension est plus étroit et plus solide :

publier une couche de guidage WordPress cohérente, inspectable et lisible par machine.

Séquence recommandée

1. Auditer le fichier actuel

Utilisez le vérificateur llms.txt et l’audit gratuit du site. Vérifiez si le fichier existe, s’il est accessible, s’il contient un vrai guidage et s’il contredit le reste de la politique de crawl.

2. Cartographier les pages sources

Avant de rédiger le fichier, décidez quelles pages méritent d’être listées :

  • hub produit ;
  • page de tarifs ou de plans ;
  • hub de documentation ;
  • hub visibilité IA ;
  • guides par crawler ;
  • pages de politique et de gouvernance ;
  • preuves ou études de cas ;
  • page de support.

3. Retirer les routes faibles

Ne listez pas les archives de faible valeur, pages utilitaires, doublons, étiquettes minces, recherches internes ou pages instables.

4. Aligner avec robots.txt

Ne pointez pas les machines vers des pages que vous bloquez aussi, sauf si la raison est claire. Une contradiction entre llms.txt et robots.txt est pire qu’un fichier court.

5. Maintenir le fichier

Un llms.txt obsolète peut induire les machines en erreur. Révisez-le lorsque vous modifiez vos services, tarifs, capacités produit, posture crawler, routes de documentation ou fichiers de gouvernance.

FAQ

llms.txt est-il obligatoire pour WordPress ?

Non. Il est optionnel. Il est utile lorsqu’il est exact et maintenu.

La vérification Lighthouse transforme-t-elle llms.txt en facteur SEO ?

Non. Lighthouse peut inspecter un signal de lisibilité machine côté navigateur. Cela ne transforme pas le fichier en facteur de classement Google Search.

Faut-il ajouter llms.txt seulement pour éviter un avertissement d’audit ?

Non. Ajoutez-le lorsqu’il améliore le routage lisible par machine du site. Évitez les placeholders vides.

llms.txt doit-il contenir toutes les URLs ?

Non. Il doit lister les surfaces prioritaires, pas dupliquer le sitemap.

llms.txt remplace-t-il robots.txt ?

Non. Lisez robots.txt vs llms.txt pour WordPress et robots.txt, llms.txt et WebMCP.

À lire ensuite

Références officielles

Pour vérifier les sources, partir de :