Les nouveaux indicateurs du GEO : ce que les LLM voient vraiment d’un site

Pendant longtemps, l’analyse technique du référencement reposait sur des questions relativement balisées : Googlebot peut-il accéder à la page ? Le serveur répond-il correctement ? Le contenu est-il indexable ? Le HTML contient-il les informations attendues ?

L’arrivée des moteurs génératifs ne supprime aucune de ces questions. Elle en ajoute de nouvelles, avec une difficulté supplémentaire : il n’existe pas un crawler LLM unique, doté d’un comportement stable et universel.

OpenAI distingue par exemple plusieurs agents : OAI-SearchBot pour la recherche dans ChatGPT, GPTBot pour les usages liés à l’amélioration des modèles et ChatGPT-User pour certaines actions déclenchées par un utilisateur. Ces agents ne répondent pas au même besoin et leur passage dans les logs ne doit pas être interprété de la même manière.

À cela s’ajoutent les navigateurs automatisés. Un agent IA peut ouvrir une page dans un environnement pilotant Chrome sans se présenter avec un user-agent explicite comme GPTBot ou ClaudeBot. Dans les logs, il devient alors un Headless Chrome parmi d’autres, impossible à attribuer avec certitude à un modèle ou à un fournisseur.

Le GEO fait donc émerger une nouvelle discipline de mesure : non plus seulement suivre les positions ou compter les crawlers déclarés, mais comprendre ce qui est réellement transmis, extrait et interprété. Ces indicateurs prolongent les transformations liées au GEO déjà évoquées dans la rubrique Intelligence artificielle.

Voir une page ne signifie pas forcément la comprendre

Une réponse HTTP 200 est une bonne nouvelle. Elle prouve que le serveur a répondu. Elle ne prouve pas que le contenu utile a été reçu, encore moins qu’il a été compris.

Une page peut répondre correctement tout en présentant plusieurs problèmes :

• un HTML initial presque vide
• un titre injecté tardivement par JavaScript
• un prix chargé après une requête vers une API
• une disponibilité affichée uniquement après interaction
• un contenu caché derrière un clic ou un défilement
• des données structurées absentes du HTML initial
• une version différente selon le user-agent, l’adresse IP ou le comportement détecté par le WAF

La question n’est donc pas seulement : « Le LLM exécute-t-il JavaScript ? »

La meilleure question est :

De quelle information dispose-t-il au moment où il doit sélectionner, comprendre et éventuellement citer cette page ?

Google exécute JavaScript grâce à son système de rendu. Mais Google précise également que le rendu peut être différé, que tous les bots n’exécutent pas JavaScript et que le rendu côté serveur, le rendu statique ou l’hydratation restent des solutions plus robustes.

Pour les moteurs génératifs, les comportements sont encore plus hétérogènes. Certains systèmes s’appuient sur leur propre crawler, d’autres sur un index de recherche, un fetch HTTP, une copie en cache ou un navigateur automatisé. Affirmer qu’un « LLM voit JavaScript » ou qu’il « ne voit pas JavaScript » est donc trop simplificateur.

Le cas concret d’un prix chargé en JavaScript

Prenons une page produit dont le prix est absent du HTML envoyé par le serveur. Le navigateur charge la page, exécute un script, interroge une API puis affiche le prix.

Pour l’utilisateur, tout semble fonctionner.

Pour un système qui se contente du HTML initial, le produit existe, mais son prix n’existe pas. Pour un moteur capable de rendre la page, le prix peut apparaître — à condition que le script fonctionne, que l’API réponde, que le rendu aille jusqu’au bout et qu’aucune interaction ne soit nécessaire.

Le problème n’est pas théorique. Google recommande lui-même de placer les données structurées Produit dans le HTML initial pour obtenir des résultats plus fiables, notamment lorsque le prix et la disponibilité évoluent rapidement.

En GEO, le prix visible par l’utilisateur ne suffit donc plus comme indicateur. Il faut aussi vérifier :

• sa présence dans le HTML initial
• sa présence après rendu
• sa cohérence avec le JSON-LD
• sa stabilité selon le user-agent
• sa disponibilité sans clic, scroll ou consentement préalable

Cette logique vaut aussi pour une adresse, un auteur, une date, un stock, une condition tarifaire, un tableau comparatif ou une information métier essentielle.

SSR, JavaScript et faux débat technique

Le SSR est souvent présenté comme la réponse absolue. Ce n’est pas tout à fait exact.

Une page rendue côté serveur peut être pauvre, mal structurée ou incohérente. À l’inverse, une application JavaScript peut être parfaitement accessible si elle fournit un HTML initial complet, des URL stables et un contenu sémantiquement clair.

Le véritable indicateur n’est donc pas la technologie employée. C’est le résultat obtenu.

Il faut mesurer la présence, dès la réponse initiale, des éléments nécessaires à la compréhension :

• le title et la meta description
• le canonical
• le H1
• la description de l’activité ou du sujet
• les informations critiques
• les liens internes principaux
• l’auteur et les dates
• les données structurées
• un contenu éditorial minimal et autonome

Le SSR, le rendu statique et l’hydratation sont surtout des moyens de réduire la dépendance à une étape de rendu incertaine. Ils ne remplacent ni la qualité du contenu ni la cohérence des entités.

Le retour du cloaking sous une forme plus subtile

Le cloaking consiste traditionnellement à présenter aux moteurs une version différente de celle proposée aux utilisateurs afin d’influencer leur compréhension ou leur classement.

Avec les LLM, le sujet réapparaît de manière moins évidente. Un CDN, un WAF ou une règle anti-bot peut servir des réponses différentes sans volonté explicite de manipuler quoi que ce soit. Le bot peut recevoir une page simplifiée, un challenge, une erreur 403 ou un HTML incomplet alors que l’utilisateur voit la page normale.

À l’inverse, certains sites pourraient être tentés de construire une version spécialement enrichie pour les bots IA. Cette approche devient risquée dès que les faits, les offres ou les promesses diffèrent de la page réellement accessible aux utilisateurs.

Le bon indicateur n’est pas « servons-nous exactement les mêmes octets ? », mais plutôt :

Les utilisateurs et les agents reçoivent-ils les mêmes informations essentielles, avec la même signification ?

Google considère le rendu dynamique comme une solution de contournement, pas comme une solution durable. Il recommande plutôt le rendu côté serveur, le rendu statique ou l’hydratation. Le rendu dynamique n’est pas nécessairement du cloaking lorsque le contenu reste équivalent, mais il ajoute une complexité dont il faut mesurer les effets.

Bot Vision : comparer les versions réellement servies

C’est précisément pour explorer cette zone que j’ai créé Bot Vision, un outil interne que j’utilise dans mes analyses.

L’outil compare le HTML obtenu en émulant plusieurs user-agents :

• OAI-SearchBot
• GPTBot
• ChatGPT-User
• Googlebot
• Bingbot
• ClaudeBot
• PerplexityBot
• Chrome

Il mesure notamment le statut HTTP, les redirections, le temps de réponse, la taille du HTML, les titres, le H1, le texte utile, les liens, les données structurées et la parité avec Chrome.

Sur la page d’accueil de Market-Cheese, le diagnostic approfondi obtient un accès homogène pour les différentes familles testées : HTTP 200, absence de redirection, contenu textuel comparable et robots autorisés. C’est rassurant, mais cela ne prouve pas qu’un véritable crawler OpenAI a effectué la visite.

L’outil émule un user-agent. Il ne reproduit ni l’adresse IP officielle du fournisseur, ni toutes les décisions du CDN, du WAF ou du système distant. C’est un test de parité HTTP, pas une simulation parfaite de ChatGPT.

Cette limite n’affaiblit pas le diagnostic. Elle définit précisément ce qu’il mesure.

Diagnostiquer par couches plutôt que produire un verdict unique

La représentation la plus utile dans Bot Vision est probablement le pipeline de diagnostic par bot.

Pour chaque user-agent testé, l’analyse traverse successivement plusieurs couches :

Cette lecture par couches change la nature du diagnostic.

Si GPTBot reçoit une erreur 403, il est inutile de commencer par réécrire les H2. Si le serveur répond correctement mais que le HTML initial ne contient qu’un conteneur id="root", le problème se situe probablement dans la stratégie de rendu. Si le texte est présent mais que le prix, l’auteur ou les conditions restent absents, l’accès est réussi mais l’information métier est incomplète.

Le pipeline permet aussi de distinguer une cause d’un symptôme. Une page vide dans l’analyse peut provenir de l’application, d’un script qui échoue, d’une API bloquée, d’une règle WAF ou d’un contenu déclenché uniquement après interaction. Le constat final est identique — l’information manque — mais la correction ne se situe pas au même endroit.

Il faut toutefois rester précis sur le statut de chaque couche. Un test HTTP peut vérifier la présence des scripts et comparer le HTML initial. Il ne prouve pas automatiquement qu’un véritable bot distant exécutera tout le JavaScript, attendra les mêmes requêtes réseau ou interagira avec la page. Dans un diagnostic GEO, chaque voyant doit correspondre à une preuve explicitement mesurée.

Cette matrice devient particulièrement intéressante dans le temps. Après une modification du CDN, du WAF, du framework JavaScript ou du système de données structurées, une régression peut être localisée sans attendre une baisse de trafic ou de citations.

Les nouveaux indicateurs techniques du GEO

Je regroupe désormais les indicateurs GEO en six niveaux.

1L’accessibilité

Le premier niveau reste le plus classique :

• autorisation dans robots.txt
• statut HTTP
• redirections
• temps de réponse
• stabilité de l’URL finale
• blocage par le CDN ou le WAF
• type de contenu reçu

Un agent qui reçoit une erreur ou un challenge ne peut pas exploiter la page.

2La parité de contenu

Il faut ensuite comparer ce que reçoivent Chrome, Googlebot et les user-agents LLM :

• parité du texte utile
• parité des titres
• parité des liens
• parité du canonical
• parité du JSON-LD
• parité des informations critiques
• différence de taille du HTML

Une différence n’est pas automatiquement un problème. Elle doit toutefois être expliquée.

3L’exposition des données critiques

Certaines informations méritent un contrôle spécifique :

• prix
• disponibilité
• auteur
• date de publication et de modification
• adresse
• caractéristiques d’un produit ou d’un service
• conditions et limites
• preuves et sources

Pour chacune, il faut vérifier sa présence dans le HTML initial, après rendu et dans les données structurées.

4L’extractibilité sémantique

Un contenu présent peut rester difficile à exploiter. Une page extractible propose notamment :

• une réponse claire dès l’introduction
• une hiérarchie H1-H2-H3 cohérente
• des paragraphes autonomes
• des listes et tableaux lorsque le sujet s’y prête
• des entités identifiables
• un auteur relié à une page de référence
• des sources accessibles
• un JSON-LD cohérent avec le contenu visible

Le volume de texte n’est pas une preuve de compréhension. Mille cinq cents caractères ambigus peuvent être moins utiles que trois cents caractères précis.

5Les passages réellement observés

L’émulation doit être complétée par les logs :

• crawlers LLM vérifiés
• crawlers probables
• navigateurs automatisés
• trafic cloud non attribué
• pages visitées
• fréquence de passage
• nombre de requêtes et nombre de sessions

Cette distinction est essentielle. Quinze requêtes Headless Chrome en dix minutes peuvent représenter une seule session agentique, un outil de test ou un scraper. Elles ne prouvent pas quinze visites de ChatGPT.

6La visibilité obtenue

Le crawl n’est enfin qu’un moyen. Le véritable résultat reste la présence dans les réponses :

• marque mentionnée
• page citée
• lien affiché
• part de voix sur un panel de questions
• sources concurrentes sélectionnées
• stabilité des citations dans le temps

Un site peut être parfaitement accessible et ne jamais être cité. À l’inverse, une page peut être citée à partir d’un index ou d’une source tierce sans passage identifiable au moment de la requête.

Du score unique au faisceau d’indices

La tentation naturelle consiste à résumer tout cela dans une note sur 100. Cette note est utile pour comparer des tests et détecter une régression. Elle devient dangereuse lorsqu’elle masque la nature des problèmes.

Un score d’accès élevé ne compense pas un prix absent. Une excellente parité HTML ne garantit pas l’autorité de la source. Un crawler identifié dans les logs ne garantit aucune citation.

Le GEO doit donc être suivi comme un faisceau d’indices :

1. l’agent peut accéder à la page
2. il reçoit les informations importantes
3. ces informations sont cohérentes avec celles visibles par l’utilisateur
4. elles sont structurées de manière compréhensible
5. le site est réellement parcouru
6. il est finalement mentionné ou cité

Ce que le GEO change vraiment

Le SEO nous a appris à ne pas confondre crawl, indexation et positionnement. Le GEO nous oblige à ajouter plusieurs étapes : extraction, interprétation, sélection et citation.

La question du JavaScript reste importante, mais elle n’est qu’un morceau du problème. La vraie question est moins de savoir si un LLM « voit » JavaScript que de vérifier s’il dispose, au bon moment, d’une version complète, stable et intelligible de l’information.

Ce changement impose de rapprocher trois métiers qui travaillent encore trop souvent séparément : la technique, l’éditorial et la mesure.

Les logs montrent qui passe. Les tests de parité montrent ce qui est servi. L’analyse du contenu montre ce qui peut être compris. Le suivi des réponses montre ce qui est finalement retenu.

C’est probablement là que se trouvent les nouveaux indicateurs du GEO.

Sources et références

• OpenAI — Overview of OpenAI Crawlers (lien externe)
• Google Search Central — Comprendre les bases du SEO JavaScript (lien externe)
• Google Search Central — Le rendu dynamique comme solution de contournement (lien externe)
• Google Search Central — Générer des données structurées avec JavaScript (lien externe)
• Google Search Central — Données structurées pour les fiches produit (lien externe)

Note méthodologique

Bot Vision compare des réponses HTTP obtenues avec différents user-agents. Il ne reproduit pas parfaitement les conditions d’un passage réel des services concernés. L’adresse IP source, les règles du CDN, le WAF, la localisation, les headers et les décisions propres à chaque fournisseur peuvent modifier la réponse réellement obtenue.