Sommaire
1. Une nouvelle catégorie dans Lighthouse
Google a discrètement ajouté à Lighthouse / PageSpeed Insights une catégorie expérimentale baptisée « Navigation agentique » (Agentic Browsing en anglais). Son objet : mesurer à quel point un site est compréhensible et utilisable par les agents IA — pas seulement par un humain ou par le robot d'indexation classique.
C'est le prolongement logique du SEO. La recherche passe de plus en plus par des assistants qui lisent les pages à notre place, remplissent des formulaires, comparent des offres. Être « lisible » par eux devient une nouvelle forme de visibilité.
⚠️À relativiser : la catégorie est encore expérimentale. Google indique qu'elle est « en cours de développement et susceptible d'être modifiée ». À voir comme une bonne pratique d'anticipation, pas comme un critère de classement gravé dans le marbre.
2. Ce que mesure la navigation agentique
La catégorie repose sur trois vérifications. Voici à quoi elles correspondent, vulgarisées :
Arborescence d'accessibilité bien formée
Chaque élément interactif (champ, bouton, case à cocher) doit avoir un nom programmatique (label / aria-label), des rôles ARIA corrects, et ne pas être masqué. Un agent IA « lit » la page via cette arborescence : sans labels, il ne sait pas à quoi sert un champ.
Fichier llms.txt
Un fichier Markdown à la racine du domaine qui résume le site pour les modèles de langage — l'équivalent du robots.txt, mais pour les IA. Il doit contenir au moins un titre H1.
WebMCP
Un protocole très récent permettant d'exposer explicitement les formulaires et actions du site aux agents via une API. Nécessite l'Origin Trial de Chrome (≥ v150) et du JavaScript dédié.
À noter : dans Lighthouse, le CLS (stabilité visuelle, Cumulative Layout Shift) apparaît aussi parmi les audits réussis de cette section — une page qui « saute » au chargement perturbe autant un agent qu'un humain.
3. Pourquoi ça compte (déjà)
Un constat honnête d'abord : un site statique moderne (par exemple sous Astro) passe souvent ces tests d'emblée. Le HTML y est propre, sémantique, sans surcouche. À l'inverse, un WordPress avec page builder (Avada, Elementor…) génère un HTML beaucoup plus « chargé » et échoue plus facilement.
Ce site même — stephduma.dev, construit sous Astro — en est l'illustration : il passe les vérifications agentiques nativement (arborescence d'accessibilité ✓, CLS à 0,003 ✓), avec un quasi-sans-faute sur les autres catégories. À noter : WebMCP étant classé « non applicable », le maximum atteignable ici est 2/2.
La bonne nouvelle, et c'est tout le sujet de cet article : ça se corrige en quelques étapes. Pas besoin de quitter WordPress pour être prêt pour les agents. La démonstration ci-dessous a été menée sur un site réel — atelierimagesetcie.fr (WordPress + WooCommerce + Avada).
4. Cas pratique sur WordPress : nos 2 corrections
Au départ, le site était à 1/3 : deux audits en échec (accessibilité + llms.txt), le troisième (WebMCP) non applicable. Voici exactement ce qu'on a fait.
Correctif n°1 — Rendre les formulaires accessibles aux agents
Le problème : la case « J'accepte la politique de confidentialité » du formulaire d'inscription newsletter (plugin Brevo, ex-Sendinblue) était un <input type="checkbox"> sans aucun label. Un agent IA — ou un lecteur d'écran — ne peut pas nommer cette case.
💡Le point WordPress important : sur ces plugins de formulaire, le HTML n'est pas dans le thème — il est stocké en base de données / dans les réglages du plugin. On édite donc le formulaire là où il est défini (réglages Brevo), pas dans functions.php.
<input type="checkbox" name="terms" required>
J'accepte la politique de confidentialité<input type="checkbox" id="terms" name="terms" required
aria-label="J'accepte la politique de confidentialité">
<label for="terms">
J'accepte la <a href="…">politique de confidentialité</a>
</label>En bonus, on a ajouté un aria-label au champ e-mail, qui n'avait qu'un placeholder. Point pédagogique utile : un placeholder ne compte pas comme un label pour l'accessibilité — il disparaît dès qu'on tape, et n'est pas exposé de façon fiable dans l'arborescence.
Généralisable : passez en revue tous les formulaires du site (contact, recherche, filtres WooCommerce, newsletter) et vérifiez que chaque champ a un label associé.
Correctif n°2 — Créer un fichier llms.txt
Le problème : le site n'avait pas de /llms.txt. La correction : créer un fichier llms.txt à la racine du site (au même niveau que robots.txt), au format Markdown :
- un titre H1 avec le nom du site ;
- un résumé en blockquote (
>) : ce que fait l'entreprise, où, ses spécificités ; - des sections
##listant les pages clés avec des liens (services, contact, devis, FAQ…) ; - une section
## Optionalpour le secondaire (ex. le sitemap), que les IA peuvent ignorer si elles manquent de contexte.
# Atelier Images & Cie
> Atelier photo et boutique en ligne (tirages, encadrement,
> objets personnalisés). Basé en France, livraison Europe.
## Pages clés
- [Nos services](https://atelierimagesetcie.fr/services/)
- [Boutique](https://atelierimagesetcie.fr/boutique/)
- [Contact / Devis](https://atelierimagesetcie.fr/contact/)
- [FAQ](https://atelierimagesetcie.fr/faq/)
## Optional
- [Plan du site](https://atelierimagesetcie.fr/sitemap.xml)💡Astuce WordPress : un vrai fichier physique à la racine est servi avant la réécriture d'URL de WordPress (règle .htaccess !-f). Pas besoin de plugin ni de route custom : on dépose le fichier par FTP/SFTP. Plus simple et plus robuste qu'une génération dynamique.
Le format de référence est documenté sur llmstxt.org. Notre fichier final est visible en clair : atelierimagesetcie.fr/llms.txt.
5. Le piège des page builders
Si je devais résumer le vrai obstacle sur WordPress, ce n'est pas la difficulté technique — c'est de savoir où chercher. Avec un page builder, le HTML d'un même formulaire peut venir de trois endroits différents :
- →le thème / builder (Avada) pour les blocs éditoriaux ;
- →les réglages d'un plugin (Brevo, formulaires de contact) pour les champs — stockés en base, pas dans les fichiers ;
- →WooCommerce pour les filtres, le panier et le tunnel d'achat.
Modifier functions.php ne sert à rien si le champ fautif est défini dans l'interface d'un plugin. La méthode : inspecter l'élément en échec dans Lighthouse, repérer d'où sort son HTML, puis le corriger à la source.
6. Et WebMCP ? Prometteur mais expérimental
Le troisième audit, WebMCP, on l'a volontairement laissé de côté. Il exige de s'inscrire à un Origin Trial Chrome (≥ v150) et d'implémenter une API JavaScript expérimentale pour déclarer ses actions et formulaires aux agents. Trop instable et trop lourd pour un site en production aujourd'hui.
Bonne nouvelle : Lighthouse le classe en « Non applicable ». On atteint donc le 3/3 sans lui. À revoir quand le protocole sera stabilisé.
7. Le résultat : 1/3 → 3/3
Score Lighthouse « Navigation agentique » (mobile), avant et après, avec seulement deux corrections ciblées :
Le message à retenir : pas besoin de refondre le site. Quelques ajustements ciblés — des labels de formulaires et un fichier texte — suffisent à mettre un WordPress au niveau des attentes de l'ère agentique.
Conclusion
La navigation agentique n'est pas encore un critère de classement officiel, mais la direction est claire : nos sites devront bientôt parler aux machines aussi bien qu'aux humains. La bonne surprise, c'est que les fondamentaux — accessibilité propre et contenu structuré — sont exactement ceux qui rendent déjà un site meilleur pour ses visiteurs.
Autrement dit : optimiser pour les agents IA, c'est surtout faire de l'hygiène web qu'on aurait dû faire de toute façon. Et même un WordPress chargé de plugins peut s'y mettre en une après-midi. Pour aller plus loin sur la connexion entre LLMs et WordPress, voir aussi faire parler ChatGPT (ou Claude) à votre WordPress.
Site test : WordPress + WooCommerce + Avada · Outil : Lighthouse / PageSpeed Insights, onglet « Navigation agentique » · Format : llmstxt.org
Votre site est-il prêt pour les agents IA ?
J'audite la « lisibilité IA » de votre site (accessibilité, llms.txt, structure) et vous dis quoi corriger en priorité — chiffres à l'appui.
Demander un audit+10 ans d'expérience, 250+ projets livrés. Expert React, Next.js & WordPress. J'aide les entreprises à construire des expériences web performantes — et, désormais, lisibles par les IA.