SEO, IA, agents : ce qu’un site doit vraiment montrer aux machines en 2026

Pendant longtemps, un audit SEO pouvait se résumer à une série de questions assez connues : Google peut-il explorer les pages ? Les indexer ? Comprendre leur contenu ? Les faire remonter sur les bonnes requêtes ?

En 2026, ces questions n’ont pas disparu. Elles ont plutôt gagné des voisines. Les moteurs génératifs, les systèmes de réponse et les agents ajoutent de nouvelles surfaces de découverte, avec une conséquence simple : il ne suffit plus de se demander si une page peut être indexée. Il faut aussi regarder si elle est facilement récupérable, interprétable, attribuable et exploitable.

C’est l’idée défendue par Harry Clarkson-Bennett dans un récent guide consacré à l’audit des sites éditeurs. L’intérêt du sujet dépasse largement la presse : pour les marques, les agences et les sites de contenu, l’audit SEO commence à devenir un audit plus large de la découvrabilité.

Avant l’IA, il faut déjà que la page soit accessible

Le premier piège serait de traiter les moteurs IA comme une couche complètement séparée du Web traditionnel.

Chez Google, ce n’est clairement pas le cas. La documentation officielle rappelle que ses fonctionnalités génératives reposent toujours sur les systèmes de recherche existants. Pour qu’une page puisse apparaître comme source dans AI Overviews ou AI Mode, elle doit d’abord être indexée et éligible à un affichage avec extrait dans Google Search.

Google précise qu’une autre condition s’ajoute : le site doit aussi être inclus dans les fonctionnalités IA génératives via un réglage Search Console. Autrement dit, l’audit ne doit plus seulement vérifier l’indexabilité et les directives de crawl. Il faut aussi vérifier que le site n’a pas été exclu de ces expériences au niveau de la propriété.

La documentation du rapport de performance IA boucle d’ailleurs directement avec ce réglage : si le rapport reste vide, Google indique que l’une des causes possibles est précisément l’exclusion du site des fonctionnalités IA génératives. Ce n’est donc pas une curiosité administrative, mais un vrai item d’audit.

Pour les pages qui reposent sur JavaScript, la documentation Google décrit ensuite un traitement en plusieurs temps — exploration, rendu puis indexationInclusion d’une URL dans l’index d’un moteur, condition nécessaire (mais non suffisante) pour ranker.. Un contenu injecté trop tard, une mauvaise règle robots.txt, une canonique incohérente ou un rendu fragile restent donc des problèmes très classiques… y compris dans un monde où la réponse finale est générée par une IA.

Pour les agences, c’est presque rassurant : les fondamentaux n’ont pas été invalidés. Un site lent à rendre, difficile à crawler ou rempli d’URLs inutiles ne devient pas plus performant parce qu’on lui ajoute une couche “GEOGenerative Engine Optimization : stratégies pour apparaître dans les réponses génératives (AI Overviews, chatbots).” dans le reporting.

Être lisible par une machine ne veut pas dire écrire pour une machine

Le discours autour de l’optimisation pour les LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. a fait émerger beaucoup de recettes : découper tous les contenus en petits blocs, ajouter des fichiers spécifiques, reformuler les articles sous forme de réponses courtes ou multiplier les mentions de marque.

Google a pris le temps de répondre directement à plusieurs de ces idées en 2026. Sa position est assez nette : il n’est pas nécessaire de créer un fichier llms.txt, un balisage spécial ou une structure artificielle pour apparaître dans ses fonctionnalités génératives. Le moteur indique également qu’il n’est pas nécessaire de découper le contenu en petits fragments pour qu’il soit compris par ses systèmes.

La nuance compte : Google ne dit pas qu’un contenu bien structuré est inutile, ni qu’il faut éviter les blocs courts. Il dit simplement que le “chunkingDécoupage d’un document en segments indexables pour le RAG ; taille et chevauchement impactent le rappel.” n’est pas un prérequis technique pour ses fonctionnalités IA.

Cela permet de distinguer structure éditoriale claire et optimisation artificielle.

Des titres cohérents, des paragraphes identifiables, une hiérarchie compréhensible et un HTML raisonnablement sémantique restent utiles parce qu’ils servent plusieurs publics à la fois : lecteurs, moteurs de recherche, technologies d’assistance et agents capables d’analyser le DOM.

HTML sémantique : utile, mais pas magique

C’est ici qu’une tension intéressante apparaît entre les sources.

Clarkson-Bennett défend fortement le HTML sémantique comme élément d’un site plus lisible par les machines. Google adopte une position plus mesurée : un HTML parfaitement sémantique n’est pas requis pour être compris ou visible dans Search. Le Web réel est imparfait, et Google sait travailler avec cette imperfection.

Faut-il donc arrêter de se soucier des balises <article>, <nav>, <button> ou d’une hiérarchie propre ? Non.

L’arbitrage est plutôt le suivant : le HTML sémantique n’est pas un hack de ranking, mais un investissement de robustesse.

Google recommande lui-même de l’utiliser quand c’est possible, notamment pour aider les lecteurs d’écran. Et son guide consacré aux sites “agent-friendly” va plus loin : les agents de navigation peuvent inspecter le DOM, lire l’arbre d’accessibilité et croiser ces informations avec le rendu visuel.

Une page bourrée de <div> rendues interactives uniquement en CSS et JavaScript pourra fonctionner pour un humain tout en étant plus ambiguë pour un agent ou une technologie d’assistance. Une vraie balise <button>, un lien explicite ou un label correctement associé à un champ donnent au contraire un signal fonctionnel plus clair.

Les agents rendent l’accessibilité beaucoup plus concrète

C’est probablement la nouveauté la plus tangible de 2026.

Google explique que les agents navigateurs peuvent analyser une page de trois manières complémentaires : par son rendu visuel, par le DOM et par son arbre d’accessibilité. Ce dernier condense notamment les rôles, noms et états des éléments interactifs.

OpenAILaboratoire d’IA américain à l’origine des modèles GPT et de ChatGPT, accessibles par API et non téléchargeables. documente une logique très proche pour ChatGPT Atlas. Son agent s’appuie sur les balises et rôles ARIA — les mêmes mécanismes qui servent aux lecteurs d’écran — pour comprendre la structure d’une page et identifier ce que font un bouton, un menu ou un formulaire.

C’est important parce que l’accessibilité cesse ici d’être un simple argument indirect de qualité. Elle devient aussi une interface machine.

Pour un audit, cela ouvre une couche nouvelle : vérifier la qualité de l’arbre d’accessibilité, les noms accessibles des contrôles, les rôles ARIA, les associations label/champ et la présence de vrais éléments interactifs plutôt que de faux boutons construits avec des <div>.

Le guide web.dev ajoute des critères très concrets : conserver un layout stable, éviter les overlays “fantômes” qui masquent des éléments interactifs, utiliser cursor: pointer comme signal d’actionnabilité et s’assurer que les éléments nécessaires au parcours disposent d’une zone visible suffisante — le guide fixe un seuil supérieur à 8 pixels carrés pour éviter leur filtrage par l’analyse visuelle.

Les bonnes pratiques restent d’abord destinées aux humains. Mais pour une fois, améliorer l’accessibilité améliore directement la capacité de certains agents à comprendre et manipuler le site.

Et demain : déclarer directement des actions aux agents ?

Une autre piste apparaît déjà : ne plus obliger l’agent à déduire entièrement ce qu’il peut faire à partir de l’interface.

Chrome expérimente WebMCP, un standard Web proposé qui permet à un site d’exposer des outils structurés aux agents — par exemple rechercher, filtrer ou remplir un formulaire — via JavaScript ou des annotations déclaratives sur les formulaires HTML. L’APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). est encore expérimentale et disponible via un origin trial : ce n’est donc pas un prérequis d’audit aujourd’hui, mais c’est un signal intéressant sur l’évolution du Web agentique.

Dans le commerce, Google pousse en parallèle UCP, Universal Commerce Protocol, un standard destiné aux interactions entre plateformes, agents et marchands, notamment pour permettre des actions agentiques dans AI Mode et Gemini jusqu’au checkout.

Ces protocoles ne remplacent pas un DOM propre ou une bonne accessibilité. Ils montrent plutôt la direction : après avoir rendu les pages compréhensibles aux machines, le Web pourrait progressivement leur déclarer explicitement ce qu’elles peuvent y faire.

Auteurs, marque et données structurées : réduire l’ambiguïté

Cette logique devient particulièrement visible sur les sites éditoriaux.

Qui a écrit l’article ? Pour quelle organisation ? Quand a-t-il été publié ? S’agit-il d’un article, d’une fiche produit ou d’une page institutionnelle ? Les réponses peuvent être évidentes à l’œil humain, beaucoup moins dans le code d’un site mal structuré.

Les données structuréesVocabulaire de données structurées pour expliciter entités et contenus aux moteurs (souvent via JSON-LD). servent précisément à fournir ce type d’indices explicites. Google recommande par exemple, pour le balisage Article, d’identifier correctement les auteurs et de relier leur nom à une URL ou à une propriété sameAs lorsqu’elle existe. Le moteur conseille aussi de distinguer clairement auteur et éditeur.

Il faut toutefois éviter de transformer Schema.org en baguette magique. Google précise que les données structurées ne sont pas obligatoires pour ses fonctions de recherche générative et qu’il n’existe pas de schéma spécial pour y apparaître.

Leur intérêt est plus sobre : décrire proprement ce qui existe déjà sur la page.

Une page auteur complète, un nom cohérent, une organisation identifiable et un balisage qui correspond au contenu visible rendent l’écosystème plus facile à interpréter. C’est moins spectaculaire qu’un nouveau “hack IA”, mais probablement beaucoup plus durable.

OpenAI introduit une autre variable : quels bots voulez-vous laisser entrer ?

Avec les moteurs IA, l’audit doit également regarder de plus près la politique de crawl.

OpenAI distingue par exemple OAI-SearchBot, utilisé pour permettre la découverte de contenus dans ChatGPT Search, et GPTBot, associé à l’utilisation potentielle de contenus pour l’entraînement. Un éditeur peut donc vouloir autoriser l’un tout en bloquant l’autre.

Ce détail montre pourquoi le simple contrôle de Googlebot ne suffit plus. La question devient : quelles machines peuvent accéder à quelles parties du site, et dans quel but ?

Il faut toutefois éviter une conclusion trop simple : bloquer OAI-SearchBot ne garantit pas qu’une URL disparaisse totalement de ChatGPT Atlas. OpenAI indique que si l’URL d’une page bloquée est obtenue via un fournisseur de recherche tiers ou par d’autres pages, Atlas peut encore afficher le lien et le titre uniquement.

Pour empêcher également cet affichage, OpenAI recommande une directive noindex. Avec une subtilité importante : le crawler doit pouvoir accéder à la page pour lire cette directive.

Pour une agence ou une équipe technique, l’audit doit donc vérifier ensemble robots.txt, directives noindex, règles CDNContent Delivery Network : réseau de caches géodistribués pour servir assets et parfois HTML au plus près. et éventuels blocages réseau, plutôt que de traiter chaque mécanisme isolément.

L’audit moderne ressemble davantage à un audit de découvrabilité

C’est probablement le changement le plus important.

Un audit SEO traditionnel vérifie surtout la capacité d’un site à être trouvé dans un moteur de recherche. Un audit de découvrabilité élargit la question : le contenu peut-il circuler correctement entre les différentes surfaces qui le trouvent, le résument, le recommandent, le citent ou interagissent avec lui ?

La liste suivante n’est pas celle des quatre piliers proposés par Clarkson-Bennett : c’est notre synthèse opérationnelle pour un audit 2026.

Pour un site éditorial ou une marque qui produit beaucoup de contenu, cela revient à regarder ensemble six éléments :

• l’accès technique aux pages et les réglages d’éligibilité, notamment dans Search Console ;
• la qualité du rendu, de l’indexation et de la canonicalisation ;
• la clarté de la structure éditoriale et du HTML ;
• l’identification des auteurs, de la marque et des entités ;
• la capacité des agents à comprendre les éléments interactifs et l’arbre d’accessibilité ;
• la politique d’accès accordée aux différents crawlers.

Ce n’est pas une nouvelle checklist à ajouter au-dessus de l’ancienne. C’est surtout une nouvelle manière de la lire.

La mesure change elle aussi

La découvrabilité IA n’est plus complètement invisible dans les outils.

Le 3 juin 2026, Google a annoncé de nouveaux rapports dédiés aux fonctionnalités d’IA générative dans Search Console. Le déploiement concerne d’abord un sous-ensemble de propriétaires de sites afin de tester le dispositif avant un élargissement.

Ces rapports restent encore limités : le rapport dédié à Search expose les impressions dans AI Overviews et AI Mode, avec des dimensions comme la page, le pays, l’appareil ou la date. Il ne fournit pas encore les clics ni les requêtes dans cette vue dédiée. Discover dispose d’un rapport distinct : il ne faut donc pas mélanger les deux surfaces dans l’analyse.

Autre détail très utile pour un audit : la plupart des données de performance sont attribuées à l’URL canoniqueURL de référence déclarée pour regrouper les doublons et concentrer signaux / indexation., pas à une URL dupliquée. Une canonicalisation bancale ne pose donc pas seulement un problème d’indexation ; elle peut aussi brouiller directement la lecture du reporting IA.

Et si le rapport Search reste vide, Google invite notamment à vérifier que le site n’a pas été exclu des fonctionnalités IA génératives. La mesure devient ainsi un moyen de contrôler la configuration évoquée au début de l’audit.

Côté ChatGPT, OpenAI fournit un signal beaucoup plus classique : les liens sortants de ChatGPT Search incluent automatiquement utm_source=chatgpt.com. Pour les équipes analytics, c’est un point d’audit très concret : vérifier que ce trafic est bien capté, correctement attribué et distingué du reste du referral.

La mesure reste incomplète, mais elle commence à sortir du bricolage.

Le “GEO” est peut-être moins nouveau qu’il n’en a l’air

Il existe bien de nouvelles questions à poser : visibilité dans les réponses génératives, citations, trafic venant de ChatGPT, comportement des agents, réglages d’éligibilité ou nouveaux rapports Search Console.

Mais la rupture est moins nette que le vocabulaire du marché pourrait le laisser croire. Google présente explicitement l’optimisation pour ses expériences génératives comme une continuité du SEO et recommande de privilégier le contenu original, utile et difficilement interchangeable plutôt que les tactiques créées uniquement pour les moteurs IA.

Pour les professionnels, c’est sans doute le meilleur filtre à garder : avant d’ajouter une nouvelle recommandation “AI ready” dans un audit, demander ce qu’elle améliore réellement.

Si la réponse est meilleure accessibilité, meilleure compréhension, meilleure attribution, meilleur contrôle du crawl ou meilleure mesure, elle a probablement du sens.

Si la réponse est seulement “parce que les LLM aiment ça”, il est peut-être encore temps de demander une preuve.