Google a lancé Auto Browse en janvier 2026 sur Chrome : Gemini clique et remplit les formulaires à la place de l’internaute. Si votre site ne répond pas correctement à cet agent, qui va lire ou acheter à votre place ? Un site actionnable par un agent IA expose des données structurées complètes (schema.org, prix, disponibilité, actions) et des parcours utilisables sans rendu visuel. Sans ça, l’agent contourne la page ou abandonne avant la conversion. Les AI Overviews captent déjà une partie du trafic informationnel, la longue traîne s’évapore avant le clic. Avec Auto Browse, l’enjeu change de nature : l’agent filtre la page avant même que l’utilisateur ne la voie et une page mal structurée ne passe pas ce filtre.
Chrome Auto Browse redistribue les cartes du clic
Auto Browse s’appuie sur Gemini 3 et permet à l’utilisateur de déléguer une tâche entière : comparer des vols et réserver un billet selon un budget fixé. L’agent ouvre les sites, clique, compare les options et valide les étapes. Pour l’instant, la fonction reste réservée aux États-Unis et aux abonnés payants Google AI Pro et AI Ultra, avec un déploiement plus large annoncé pour la fin de l’été 2026 (Siècle Digital, janvier 2026). L’utilisateur garde la main sur les opérations critiques, en particulier le paiement final. Ce détail compte, car l’agent prépare tout sans jamais conclure la transaction lui-même.
Pour un site qui vit du trafic organique, une question s’ajoute désormais au classement pur : l’agent qui navigue à la place du lecteur peut-il lire, comprendre et parfois agir sur cette page ? Un contenu qui rank sans être exploitable par un agent perd une partie de sa valeur dès que ce mode de navigation se généralise.
Le robots.txt bloque encore la porte d’entrée
Avant de discuter schema.org ou WebMCP, une question plus basique se pose : votre robots.txt laisse-t-il seulement GPTBot, ClaudeBot ou PerplexityBot accéder à vos pages ? Un audit Capston AI du premier trimestre 2026 recense que 41% des sites B2B bloquent encore au moins un robot IA majeur, un réglage souvent hérité de la vague de blocages généralisés de 2023-2024. Ce blocage ferme la porte à Auto Browse et aux agents concurrents avant même qu’ils ne lisent une ligne de balisage.
Vérifiez le fichier à la racine du domaine. Une règle Disallow générique sur l’ensemble du site, ou une ligne oubliée visant un ancien crawler, suffit à exclure ces agents. Autorisez explicitement les user-agents utiles à votre activité et retirez les blocages hérités qui ne servaient qu’à limiter la charge d’un crawler devenu, entre-temps, un canal de découverte et d’action pour vos visiteurs.
Le llms.txt ne coche pas la vraie case
Avant d’écarter ce sujet comme un énième guide qui vulgarise la topical authority à la Koray Tugberk, un chiffre mérite le détour : Ahrefs a analysé 137 000 domaines en 2026 et conclu que 97% des fichiers llms.txt ne reçoivent jamais une seule requête d’un agent IA. L’étude ne trouve aucune corrélation entre la présence d’un llms.txt et la fréquence de citation d’un domaine par les modèles de langage. Ni statistique, ni par apprentissage automatique. L’adoption grimpe pourtant vite : de 1,04% à 5,61% du top 10 000 sites mondiaux en 12 mois, un rythme multiplié par 5,4 (analyse des données HTTP Archive, 2026). SE Ranking situe de son côté l’adoption globale à 10,13% sur 300 000 domaines analysés.
Le fichier documente une structure et garde une utilité d’inventaire. Il ne remplace ni le balisage schema.org, ni une architecture de données réellement exploitable. Ajouter un llms.txt en 10 minutes donne l’impression d’avoir traité le sujet des agents IA. La suite du chantier se joue sur le balisage schema.org, nettement plus déterminant pour un agent IA que ce fichier texte.
Le schema.org complet prime sur le schema.org présent
Réponse directe : un agent IA priorise les pages où le balisage schema.org couvre l’intégralité des propriétés utiles à sa tâche, prix, disponibilité, avis, spécifications, plutôt que les pages où un balisage minimal est disséminé sur tout le site.
Un balisage schema.org complet sur les pages stratégiques prime sur un balisage superficiel étendu à l’ensemble du site : les agents IA priorisent les propriétés qui répondent directement à la requête utilisateur plutôt que la simple présence d’un balisage minimal. (Search Engine Land, 2026)
Parser du HTML brut coûte cher en ressources de calcul. Un site qui structure ses entités, ses produits, ses offres et ses questions-réponses devient le chemin de moindre résistance pour l’agent qui doit décider s’il recommande cette page ou une autre. C’est un raisonnement d’entity SEO plus que de mots-clés : l’agent construit un knowledge graph local à partir de ce que votre balisage lui donne. Un schema.org incomplet envoie un signal d’incertitude à l’agent, qui privilégie la page où la couverture est complète.
Concrètement, une fiche produit qui se limite à Product et au nom de l’article ne dit rien d’exploitable à un agent chargé de comparer des offres. Ajoutez price, priceValidUntil, availability et aggregateRating et la même page devient une réponse complète que l’agent peut citer sans revenir consulter le HTML brut. Le type SearchAction, moins connu, mérite aussi l’attention : il indique à un agent comment interroger directement le moteur de recherche interne d’un site plutôt que de deviner l’URL d’une page de résultats. Peu de sites français l’utilisent alors qu’il coûte quelques lignes de JSON-LD. Une page d’articles de blog gagne à baliser Article avec datePublished et dateModified à jour : un agent qui doit juger de la fraîcheur d’une information regarde ces deux dates avant de lire le corps du texte.
Cette priorisation ne se confond pas avec la fréquence de citation dans les IA génératives, deux mécanismes distincts. Une étude Ahrefs sur 1 885 pages ayant ajouté du JSON-LD entre août 2025 et mars 2026 montre qu’un balisage posé a posteriori sur des pages déjà bien citées ne fait pas progresser leurs citations dans Google AI Overviews. Le schema.org sert avant tout à rendre une page exploitable pour une tâche, comparer un prix, vérifier une disponibilité, pas à gagner artificiellement en visibilité générative.
WebMCP donne aux agents un accès direct à vos actions
Le 10 février 2026, le groupe Web Machine Learning du W3C a publié un brouillon de spécification baptisé WebMCP, porté par des ingénieurs de Google et de Microsoft. Le principe : une API navigateur, navigator.modelContext, qui permet à un site d’exposer ses propres fonctionnalités comme des outils structurés et appelables par un agent. Sans WebMCP, l’agent capture l’écran et laisse un modèle de vision deviner où cliquer. Avec WebMCP, le site déclare directement ce qu’il sait faire et les paramètres attendus pour l’appeler.
Le standard n’est encore disponible qu’en aperçu dans Chrome 146 Canary, derrière un flag. Firefox et Safari n’ont annoncé aucun plan de support à ce stade, ce qui invite à suivre l’évolution plutôt qu’à tout miser dessus dès maintenant. L’avantage de sécurité est réel malgré tout : les outils WebMCP héritent de la session déjà ouverte par l’utilisateur. Si un visiteur est connecté à son espace client, l’agent agit dans cette session authentifiée sans négociation OAuth supplémentaire.
Des parcours que l’agent peut suivre sans capture d’écran
Un formulaire encodé uniquement en JavaScript côté client, sans attribut accessible ni libellé clair, ralentit un agent autant qu’il gêne un lecteur d’écran. Nommez chaque champ. Donnez un id ou un name explicite aux boutons d’action. Évitez les parcours qui exigent un scroll infini ou un clic sur un élément généré dynamiquement sans ancre stable dans le DOM.
La logique rejoint celle de la semantic search et des embeddings : un agent qui interprète une page cherche du sens au-delà du texte brut. Une fiche produit qui affiche son prix dans une image plutôt qu’en texte structuré reste invisible pour lui. Une FAQ rédigée en HTML sémantique (question en titre, réponse en paragraphe direct) se prête bien mieux à l’extraction qu’un accordéon chargé en JavaScript sans texte présent dans le DOM initial.
Le piège du rendu JavaScript et du contenu cadenassé
Vérifiez le rendu côté serveur. Un contenu injecté après le chargement, sans fallback HTML, peut rester invisible à un agent pressé qui ne déclenche pas systématiquement l’exécution complète du JavaScript. Testez avec l’outil d’inspection d’URL de Search Console : ce que Google voit au rendu est un bon indicateur de ce qu’un agent Gemini verra aussi.
Les murs de cookies bloquants et les CAPTCHA systématiques posent un autre problème. Un agent qui doit résoudre un CAPTCHA à chaque page abandonne la tâche ou la signale comme non fiable. Réservez ces barrières aux actions sensibles comme le paiement ou la création de compte, plutôt qu’à la simple lecture d’une fiche produit ou d’un article.
Prioriser le chantier plutôt que la checklist
Auditez d’abord vos pages à plus fort trafic informationnel ou commercial. Vérifiez le schema.org en place avec l’outil de test de résultats enrichis de Google. Complétez les propriétés manquantes avant d’en ajouter de nouvelles ailleurs. Gardez un œil sur WebMCP sans migrer votre architecture dès aujourd’hui : le standard reste en phase de brouillon. Une fois ces bases posées, vérifiez si les moteurs de réponse citent déjà votre site avec cette checklist d’audit AEO en 7 étapes.
Les agents ne liront jamais un site qui ne leur parle pas leur langage.
