Score « Navigation agentique » de Lighthouse : ce qu’il mesure et comment l’améliorer sur WordPress/WooCommerce

Depuis début mai 2026, un nouvel encart est apparu dans les rapports Lighthouse : Agentic Browsing, traduit en français par « Navigation agentique ». Pas de note sur 100, pas de couleur verte ou rouge familière. Juste une fraction : « 2 audits réussis sur 4 ». De quoi dérouter la première fois qu'on le voit.

Cet article explique concrètement ce que mesure ce score. D'où il vient, où Google l'emmène, et surtout quelles règles appliquer sur un site WordPress ou WooCommerce. L'objectif : l'améliorer sans perdre de temps sur ce qui ne compte pas encore.

1. Que mesure concrètement le score « Navigation agentique » ?

Le score ne juge pas votre site pour un humain ou pour un moteur de recherche classique. Il le juge du point de vue d'un agent IA autonome. Un assistant capable de naviguer, comprendre et agir à la place de l'utilisateur.

Les catégories historiques de Lighthouse (Performance, Accessibilité, Bonnes pratiques, SEO) donnent une moyenne pondérée sur 100. Agentic Browsing fonctionne différemment. Chaque audit est binaire : réussi ou échoué, sans demi-mesure. Le score global est une fraction, du type « 3 audits sur 4 ». Google l'assume : les standards du web agentique bougent encore trop pour prétendre à une notation fiable.

Quatre zones sont évaluées :

1. L'arbre d'accessibilité (accessibility tree) — la carte structurée que les navigateurs construisent pour décrire chaque élément cliquable d'une page. Les agents IA s'appuient dessus en priorité. L'audit vérifie que chaque bouton, lien ou champ a un nom explicite. Il vérifie aussi la cohérence de la hiérarchie de rôles.
2. La stabilité de la mise en page (CLS) — le même Cumulative Layout Shift que vous suivez déjà pour les Core Web Vitals. Une image sans dimension ou une bannière tardive peut faire cliquer un agent au mauvais endroit.
3. La présence d'un fichier llms.txt — la même brique dont on parlait dans notre article dédié au llms.txt et à la stratégie GEO.
4. L'intégration WebMCP — un protocole encore très récent. Il permet à un site de déclarer des « outils » (rechercher, ajouter au panier, réserver) qu'un agent peut appeler directement. Plus besoin de deviner à partir de captures d'écran.

2. D’où vient cet audit ?

L'audit Agentic Browsing a été ajouté dans Lighthouse 13.3, publié le 7 mai 2026. Il fait désormais partie de la configuration par défaut. Concrètement, il apparaît automatiquement dans tout rapport Lighthouse. Que ce soit depuis Chrome DevTools, la CLI, ou tout outil qui s'appuie sur Lighthouse en coulisses (PageSpeed Insights, avec un léger décalage de disponibilité).

Google le classe encore comme « expérimental ». Ce n'est pas un standard figé, mais une direction. Les audits précis peuvent évoluer dans les mois qui viennent.

Cet audit ne sort pas de nulle part. Il s'inscrit dans une série de mouvements de Google amorcés depuis fin 2025 :

• Un rapport de performance IA dans Google Merchant Center, pour les sites e-commerce.
• Un canal dédié « AI Assistant » dans Google Analytics 4. Il distingue le trafic amené par des agents IA.
• Une identité de crawler spécifique, Google-Agent, ajoutée à la documentation officielle en mars 2026.
• L'Universal Commerce Protocol (UCP). Un standard qui permet à des agents IA de finaliser un achat sans quitter l'interface de Google.

Ce faisceau d'annonces dessine une intention claire. Préparer un web où les visites ne viennent plus seulement d'humains ou de robots d'indexation, mais aussi d'agents qui agissent pour le compte d'un utilisateur.

📙 Lire : Doc officielle de Google sur son score de navigation agentique Lighthouse

3. Vers quoi cela évolue-t-il ?

Trois tendances se dégagent pour la suite.

Le passage en CI/CD. Lighthouse s'intègre déjà dans de nombreux pipelines d'intégration continue. Une fois la catégorie stabilisée, elle deviendra probablement une exigence technique suivie en continu. Un peu comme les Core Web Vitals depuis 2020.

Des signaux contradictoires côté Google lui-même. John Mueller, porte-parole historique de Google Search, a publiquement comparé le llms.txt au tristement célèbre attribut meta keywords des années 2000. Un fichier que Google Search n'utilise pas pour le classement. Pourtant Lighthouse continue de l'auditer. Ce paradoxe illustre une réalité utile à retenir : l'audit vise la lisibilité pour les agents IA en général (ChatGPT, Claude, Gemini, Perplexity). Pas uniquement pour les propres systèmes de Google.

Une maturation progressive de WebMCP. Ce protocole reste en aperçu précoce, limité à Chrome. Son adoption reste encore marginale côté agents. Mais WordPress a déjà bougé : la version 7.0, sortie le 20 mai 2026, embarque nativement une Abilities API en JavaScript. Elle pose les bases pour que les plugins déclarent des capacités (create_order, list_products...). Ces capacités deviennent consommables par des agents, via WebMCP ou en REST.

4. Comment lire ce score sans paniquer

Le point le plus important à comprendre : ce n'est pas un facteur de classement confirmé. Google ne l'a jamais présenté comme tel. C'est un signal de préparation, pas un levier SEO direct.

Trois des quatre audits recoupent des chantiers que vous devriez déjà mener pour d'autres raisons. L'accessibilité, pour les technologies d'assistance. La stabilité visuelle, pour l'expérience utilisateur et les Core Web Vitals. La clarté du HTML, pour le référencement classique. Optimiser pour les humains profite donc presque toujours aux agents IA par la même occasion.

Seul WebMCP est réellement tourné vers les agents et rien d'autre. C'est aussi le plus jeune et le moins urgent des quatre.

5. Les règles fondamentales à respecter sur WordPress / WooCommerce

Priorité 1 — Nettoyer l'arbre d'accessibilité

C'est le chantier le plus rentable. Il sert à la fois les humains et les agents.

• Donnez un nom explicite à chaque bouton et champ de formulaire. Sur WooCommerce, vérifiez particulièrement le tunnel de commande. Bouton d'ajout au panier, sélecteurs de variantes, champs d'adresse.
• Utilisez du HTML sémantique (<nav>, <main>, <button>) plutôt que des <div> cliquables en JavaScript. Ces derniers sont plus fragiles à interpréter pour une machine.
• Passez un audit d'accessibilité classique (Lighthouse, WAVE, ou un plugin dédié). Corrigez les alertes de rôles ARIA mal formés.

Priorité 2 — Traquer les décalages de mise en page (CLS)

Rien de nouveau si vous suivez déjà vos Core Web Vitals :

• Réservez toujours une largeur et une hauteur à vos images de produits.
• Évitez les bannières promotionnelles ou pop-ups qui s'injectent après le chargement initial.
• Testez en particulier vos pages produit et votre tunnel de commande WooCommerce. Ce sont les plus sensibles à ce type d'incident.

Priorité 3 — Publier un llms.txt propre

Coût de mise en œuvre très faible, comme détaillé dans notre article sur le sujet. Sur WooCommerce, veillez à exclure les produits masqués ou en rupture. Gardez aussi le fichier synchronisé avec votre catalogue.

Priorité 4 — Garder un œil sur WebMCP, sans se précipiter

Pour la majorité des boutiques WooCommerce, ce n'est pas encore urgent. Si vous voulez explorer le sujet :

• WooCommerce propose déjà une intégration MCP native, activable via le flag mcp_integration.
• Plusieurs extensions WordPress commencent à exposer des outils WebMCP prêts à l'emploi. Recherche produit, panier, application de codes promo.
• Mieux vaut prototyper sur un seul parcours à forte valeur (recherche ou ajout au panier). Évitez d'essayer de tout instrumenter d'un coup.

Comment lancer l'audit vous-même

Ouvrez Chrome DevTools, onglet Lighthouse, lancez une analyse. La carte « Navigation agentique » apparaît en tête de rapport. Une version récente de Chrome est nécessaire (150 ou plus pour un affichage complet). L'audit WebMCP, lui, nécessite une inscription à l'origin trial pour remonter un résultat exploitable. Sans ce jeton, il restera simplement neutre, même si votre implémentation est correcte.

6. Ce qu’il faut retenir

Le score « Navigation agentique » n'est pas un nouvel algorithme de classement à courtiser à tout prix. C'est une checklist officielle, encore expérimentale. Elle rend visible un angle mort : la plupart des sites ont été construits pour des yeux humains et des robots d'indexation. Pas pour des agents qui doivent cliquer, remplir et acheter à votre place.

Sur WordPress et WooCommerce, la bonne stratégie reste raisonnable. Corrigez l'accessibilité et la stabilité visuelle parce qu'elles comptent de toute façon. Ajoutez un llms.txt parce que ça ne coûte rien. Et observez WebMCP sans vous précipiter sur une implémentation que la spécification peut encore faire évoluer.