Depuis des années, PageSpeed Insights note les performances, l'accessibilité, les bonnes pratiques et le SEO. En 2026, un cinquième élément a discrètement rejoint cette ligne : Agentic Browsing. Il répond à une question que les quatre autres catégories ignorent : un agent d'IA peut-il réellement travailler avec cette page ?
Ce guide explique comment mettre cette vérification au travail sur votre site : la lancer, comprendre ce que dit vraiment chaque audit et repartir avec une liste de correctifs.
Ce que vous aurez à la fin
À qui cela s'adresse : aux équipes SEO, aux développeurs et aux responsables de sites qui veulent savoir comment leurs pages se comportent lorsqu'un agent les parcourt à la place d'un humain.
Ce que vous aurez au terme de l'exercice : un résultat Agentic Browsing réel pour votre site, une lecture audit par audit de ce qui passe, échoue ou ne s'applique pas, et une liste de correctifs classée par priorité.
Prérequis : une URL accessible publiquement, une dizaine de minutes pour le premier lancement et un accès au code si vous prévoyez de corriger le jour même.
Critère de réussite : vous savez expliquer votre score fractionnaire audit par audit et distinguer les échecs qui empêchent vraiment un agent d'accomplir une tâche sur votre page.
D'où vient cette vérification et pourquoi maintenant
La catégorie Agentic Browsing n'existait pas il y a un an. Le déploiement s'est fait en trois étapes, toutes documentées par Google :
- 7 mai 2026 : Lighthouse 13.3 ajoute la catégorie à sa configuration par défaut, qui devient donc partie intégrante d'une exécution standard.
- 22 juin 2026 : le blog Chrome for Developers l'annonce dans un article consacré à la boîte à outils pour rendre un site prêt pour les agents, aux côtés des DevTools pour agents et des recommandations WebMCP.
- 20 juillet 2026 : Lighthouse 13.4.1 active la catégorie sur le chemin API de PageSpeed Insights et indique que la version devrait arriver dans PageSpeed Insights sous deux semaines. Le déploiement public se situe donc début août 2026.
Quand j'ai lancé la vérification le 11 septembre 2026, le pied du rapport indiquait une exécution émulée avec Lighthouse 13.4.1, et Agentic Browsing se trouvait juste à côté de SEO. La fonctionnalité est donc bien en production, pas réservée à un canal expérimental. Elle est aussi explicitement inachevée : la description de la catégorie dans le rapport le dit sans détour, elle est encore en cours de développement et susceptible de changer.
Une remarque pratique avant de commencer : PSI exécute la catégorie pour vous, côté Google. Aucun Chrome 150 ni origin trial n'est nécessaire pour les vérifications au niveau de la page. Les contraintes de version concernent l'exécution locale dans Chrome DevTools.
Lancez la vérification sur votre propre site
- Ouvrez pagespeed.web.dev et collez votre URL. Lancez d'abord la version mobile, puis répétez pour ordinateur, car les deux exécutions en laboratoire sont notées séparément.
- Attendez la fin des données de laboratoire. Les données de terrain en haut de page viennent du Chrome UX Report et se chargent vite. L'exécution Lighthouse en dessous prend plus de temps, et c'est là que se trouvent les catégories.
- Repérez la ligne des scores. Vous verrez Performances, Accessibilité, Bonnes pratiques, SEO, puis Agentic Browsing sous forme de fraction plutôt que d'un score de 0 à 100.
- Dépliez la catégorie. La liste d'audits se répartit entre Agent Accessibility, WebMCP et les blocs habituels de vérifications réussies et non applicables.
- Ouvrez chaque audit en échec. Chaque ligne se déplie et montre la règle, l'élément ou le fichier précis à l'origine de l'échec, exactement ce qu'il faut pour ouvrir un ticket de correction.
La cinquième catégorie se trouve dans la même ligne que les scores que les équipes SEO consultent chaque jour. Capturé dans PageSpeed Insights le 11 septembre 2026.
Contrôle qualité : vérifiez la version de Lighthouse dans les détails de l'exécution avant de comparer vos résultats avec un collègue. PSI met à jour Lighthouse selon son propre calendrier, et la catégorie continue de changer d'une version à l'autre.
En cas d'échec : PSI renvoie parfois un délai d'attente RPC sur les pages lourdes. Cela m'est arrivé sur un grand site en pleine recherche. Relancez, ou testez la page avec Lighthouse en local.
Lisez correctement le score fractionnaire
Agentic Browsing n'a pas de score pondéré de 0 à 100, et c'est délibéré. La documentation de Lighthouse explique que les standards du web agentique sont encore en construction, d'où l'accent mis sur des signaux actionnables plutôt que sur un classement.
Voici l'arithmétique qui compte vraiment :
Affichage | Signification |
|---|---|
3/3 | Toutes les vérifications notées sont réussies. Les vérifications non applicables sont exclues. |
1/3 | Une réussie, deux échouées. Le dénominateur ne compte que les audits réussis et échoués. |
0/3 | Aucune vérification notée n'a encore réussi. Fréquent au premier lancement sur une page lourde et chargée en publicité. |
Pas de fraction | Tous les audits étaient non applicables ou la catégorie ne s'est pas exécutée. Consultez les détails de l'exécution. |
Le piège consiste à lire 1/3 comme « 33 % prêt pour les agents ». Ce n'est le pourcentage de rien du tout. C'est un décompte : sur les trois vérifications qui pouvaient être notées sur cette page, une a réussi, et les audits non applicables ont été entièrement sortis du calcul. Dans le rapport que j'ai capturé, six audits se sont exécutés, trois étaient non applicables et les trois restants ont produit le 1/3.
Les scores bougent aussi d'une exécution à l'autre sur la même page. Lighthouse cite trois causes : l'enregistrement dynamique d'outils (les outils WebMCP enregistrés en JavaScript peuvent être captés ou manqués selon le moment), les modifications du DOM qui reconfigurent l'arbre d'accessibilité et les décalages de mise en page dus à la publicité, aux images sans dimensions ou au contenu injecté. Si votre chiffre oscille, c'est généralement la raison.
Parcourez les six audits
La version actuelle de PSI exécute six audits. Un septième arrive : la branche de développement de Lighthouse ajoute déjà une vérification ai-catalog.json (Agent Resource Discovery) dans un nouveau groupe Agent Discoverability, donc considérez cette liste comme dépendante de la version.
Audit | Ce qu'il vérifie | Ce que signifie « non applicable » |
|---|---|---|
L'arbre d'accessibilité est incorrect | Un sous-ensemble de règles d'accessibilité centrées sur les agents : noms et libellés programmatiques, structure ARIA valide et éléments qui restent interactifs tout en étant masqués de l'arbre | Jamais ; celui-ci est toujours noté |
llms.txt ne suit pas les recommandations | Que | Le fichier a renvoyé un 404. L'absence de llms.txt est traitée comme facultative, pas comme un échec |
Décalage de mise en page cumulé | La stabilité visuelle, pour que les agents qui agissent selon la position des éléments ne cliquent pas au mauvais endroit pendant un décalage | Jamais ; celui-ci est toujours noté |
Outils WebMCP enregistrés | Si la page enregistre des outils WebMCP via l'API déclarative ou impérative | Aucun outillage WebMCP n'a été détecté |
Couverture des formulaires WebMCP | Les formulaires déclaratifs auxquels il manque des annotations d'outils | Identique ci-dessus |
Validité des schémas WebMCP | Si les outils enregistrés publient des schémas d'entrée et de sortie valides | Identique ci-dessus |
Vue dépliée de la catégorie : deux échecs, une réussite et trois vérifications non applicables. La liste des échecs est la liste de tâches la plus courte.
Que les trois audits WebMCP apparaissent « non applicables » est normal en 2026. WebMCP est un standard proposé, en origin trial et en aperçu précoce, avec deux API : une déclarative qui annote les formulaires HTML standard et une impérative qui enregistre des outils depuis JavaScript. La plupart des sites n'ont encore implémenté ni l'une ni l'autre, donc la plupart des rapports affichent trois cercles gris à cet endroit. Le gris n'est pas du rouge. Ne le traitez pas comme un échec.
Corrigez ce que la vérification signale
Quatre thèmes de correction couvrent les six audits. Les trois lignes WebMCP ne demandent votre attention que si vous publiez réellement des outils pour agents.
Rendez l'arbre d'accessibilité lisible pour les agents
Les agents s'appuient sur l'arbre d'accessibilité comme carte principale de votre page. Il liste les rôles, les noms et les états. Un bouton sans nom accessible est une impasse pour eux, et pour les utilisateurs de lecteurs d'écran.
Action : parcourez les règles en échec de l'audit déplié. Les suspects habituels sont les boutons à icône seule, les champs de formulaire sans libellé, les liens dont le texte se limite à « cliquez ici », les combinaisons de rôles ARIA invalides et les identifiants dupliqués référencés par ARIA. Privilégiez le HTML sémantique, ajoutez des attributs for aux libellés et donnez aux composants personnalisés un rôle et un tabindex explicites quand un élément natif n'est pas possible.
Résultat attendu : l'audit passe en réussite, et votre score d'accessibilité habituel progresse souvent en même temps, car la version Agentic Browsing est un sous-ensemble ciblé des mêmes vérifications.
Si vous êtes bloqué : quand la liste de corrections atteint des centaines d'éléments, ne les traitez pas un par un. Corrigez le composant partagé, comme le bouton à icône seule de l'en-tête, puis relancez. Un seul composant efface souvent des dizaines de lignes.
Publiez un llms.txt qui passe le contrôle de format
Il y a ici un piège qui attrape les gens méticuleux. L'audit ne vérifie pas seulement que /llms.txt existe. Il contrôle le contenu du fichier, et un fichier qui liste des URL brutes échoue, car le contrôle cherche des liens au format Markdown.
Action : créez /llms.txt à la racine de votre domaine, avec un titre H1 et de vrais liens Markdown :
# Nom de l'entreprise
Brève description de ce que couvre le site et de la façon dont il doit être utilisé.
## Pages clés
- [Présentation du produit](https://example.com/product)
- [Tarifs](https://example.com/pricing)
- [Documentation](https://example.com/docs)Résultat attendu : l'audit passe au vert. Un 404, en revanche, apparaît comme non applicable, ce qui est acceptable aujourd'hui. Une réponse de la série 500 ou une erreur de récupération est un vrai échec, qui demande une correction côté serveur.
Contrôle qualité : récupérez votre propre /llms.txt dans un terminal et comptez les liens. S'ils ressemblent à https://example.com/pricing sans crochets, l'audit échouera même si le fichier est en ligne et lisible par des humains.
Une réserve honnête : Google Search n'utilise pas llms.txt. Le guide d'optimisation pour l'IA de Google indique que le fichier « ne nuira ni n'aidera à la visibilité ou au classement de votre site dans Google Search, puisque Google Search les ignore ». Écrivez-le pour les outils d'agents qui lisent cette convention, pas pour le classement.
Stabilisez la mise en page pour que les agents puissent viser
Les décalages de mise en page comptent plus qu'avant. Un agent qui localise un bouton puis clique sur ses coordonnées le manquera si une publicité, une bannière ou une image tardive décale ce bouton de 200 pixels vers le bas entre ces deux instants.
Action : définissez une largeur et une hauteur explicites (ou un aspect-ratio) sur les images et les intégrations, réservez un espace fixe pour les emplacements publicitaires et les bannières de consentement, évitez d'insérer du contenu au-dessus du contenu existant après le chargement, et animez avec transform plutôt qu'avec des propriétés qui déclenchent un recalcul de mise en page.
Résultat attendu : un décalage de mise en page cumulé inférieur à 0,1 lors de l'exécution en laboratoire, soit le même seuil que celui des Core Web Vitals.
Contrôle qualité : la section du rapport consacrée aux causes du décalage de mise en page, dans la partie Performances, nomme les éléments exacts. Commencez par là plutôt que de deviner.
Décidez pour WebMCP plus tard
Les trois audits WebMCP ne sont notés que si votre site enregistre des outils. Si vous avez un parcours de réservation, un paiement, un formulaire d'assistance ou toute tâche structurée qu'un agent pourrait accomplir, WebMCP mérite un prototype : il indique à l'agent quel outil appeler au lieu de le laisser deviner à partir du DOM. Chrome propose cette fonctionnalité derrière un origin trial et un indicateur de test local, c'est donc une option réelle et non une expérience de pensée.
Si vous n'avez aucune tâche digne d'être automatisée, laissez WebMCP de côté. Trois cercles gris ne posent aucun problème. La seule chose à ne pas faire est d'enregistrer un outil décoratif juste pour embellir la fraction. La catégorie est un signal de préparation, et la tromper lui fait perdre son sens.
Vérifiez la correction
Relancez la même URL dans PSI et comparez trois choses, pas une : la fraction, le statut précis de chaque audit et le type d'appareil. Une correction peut déplacer la fraction sans régler ce qui vous importait, et mobile et ordinateur produisent des résultats de laboratoire distincts.
Pour itérer plus vite, exécutez Lighthouse en local plutôt que d'attendre PSI. La catégorie est présente depuis Lighthouse 13.3, donc une installation locale la prend en compte. Si vous voulez la version du panneau DevTools, la documentation de Google précise que tester la catégorie nécessite Chrome 150 ou plus récent, et que les audits WebMCP exigent en plus l'enregistrement à l'origin trial.
Tenez un court relevé avant/après. Une ligne datée comme « 2026-09-11 : mobile 1/3, échec de l'arbre d'accessibilité et de llms.txt » suffit. Elle vous dira si une régression ultérieure est réelle ou simplement une oscillation entre deux exécutions.
Ce que cette vérification n'est pas
Trois choses qu'elle ne fait pas, car la confusion est répandue :
- Ce n'est pas un facteur de classement. L'annonce de Chrome qualifie la catégorie d'informative et non intégrée aux référentiels comparatifs. Le classement dans Google Search n'est pas affecté par votre fraction Agentic Browsing.
- Ce n'est pas un score de visibilité IA. Elle mesure si un agent peut manipuler votre page et ne dit rien de votre présence dans les réponses de ChatGPT ou Perplexity.
- Ce n'est pas un verdict de réussite ou d'échec sur votre site. Une fraction basse sur une page marketing simple signifie généralement qu'il y avait peu de choses à noter, pas que les agents sont bloqués.
La bonne grille de lecture : cette catégorie vérifie si votre site tient la route quand le visiteur n'est pas humain. Tout ce qu'elle récompense vaut la peine d'être fait de toute façon : HTML sémantique, mises en page stables, contrôles étiquetés. Le guide de Google sur les sites adaptés aux agents se termine sur la même idée : ce qui rend un site prêt pour les agents le rend aussi meilleur pour les humains.
Gardez-la dans votre cycle de revue
La préparation aux agents fait partie de ces domaines où la plateforme évolue plus vite que la liste de contrôle. Deux habitudes vous maintiennent à jour sans en faire un projet :
- Relancez la vérification après toute modification de gabarit, de navigation, de formulaire ou de parcours d'achat. Ce sont ces changements qui déplacent l'arbre d'accessibilité et la stabilité de la mise en page.
- Suivez la fraction par gabarit, pas par URL. Dix pages produit notées de la même façon sont un problème de gabarit, et une seule correction les règle toutes.
La vérification PSI est volontairement étroite : six audits, une page à la fois. Si vous voulez la vue d'ensemble, notamment la présence des règles robots, des cartes de serveurs MCP, de la découverte OAuth et des signaux de commerce pour agents, Auspia propose une vérification gratuite Agent Readiness qui analyse une URL au regard de ces standards protocolaires et affiche un tableau comparatif.
Questions fréquentes
Le score Agentic Browsing influence-t-il le classement Google ? Non. Google décrit la catégorie comme informative, et elle ne fait pas partie des systèmes de classement de la recherche. Traitez-la comme une vérification de préparation aux agents, pas comme un score SEO.
Pourquoi ma fraction a-t-elle changé entre deux exécutions sur la même page ? L'enregistrement dynamique d'outils, les modifications du DOM qui altèrent l'arbre d'accessibilité et les décalages tardifs de mise en page provoquent des variations d'une exécution à l'autre. Retestez et comparez la liste des audits, pas seulement la fraction.
Pourquoi les trois audits WebMCP sont-ils tous non applicables ? Parce que votre page n'enregistre pas d'outils WebMCP. C'est l'état attendu pour la plupart des sites en 2026, et ce n'est pas un échec.
Un llms.txt manquant est-il un problème ? Pour cet audit, non. Un 404 est traité comme non applicable. Un fichier qui existe mais est mal formé échoue, donc si vous en publiez un, publiez-le correctement.
Puis-je exécuter cela en CI ? Oui, dès que la catégorie figure dans votre version de Lighthouse. Les audits sont déterministes par conception, ce qui les rend adaptés aux contrôles de pipeline. Gardez à l'esprit que les parties WebMCP dépendent du support du navigateur et de l'inscription à l'origin trial, donc attendez-vous à les voir non applicables dans la plupart des environnements de CI.
Ai-je besoin de Chrome 150 pour utiliser tout cela ? Non. PageSpeed Insights l'exécute côté serveur. L'exigence de Chrome 150 concerne l'exécution locale de la catégorie dans les DevTools.
Autrice : Alice Monroe, analyste des outils AI SEO chez Auspia, où elle couvre plus de 150 outils. Elle écrit sur le SEO et les outils de recherche IA, sur les vérifications qui méritent votre temps et sur la façon de les intégrer à une routine de travail.
