Un robot d'exploration classique et un robot de moteur génératif ne font pas le même travail sur votre page. Googlebot la télécharge, puis la remet dans une file d'attente où un navigateur sans interface exécute son JavaScript et produit une version finale du document. C'est le fonctionnement en deux vagues, connu depuis dix ans : le HTML d'abord, le rendu ensuite, avec un délai qui va de quelques heures à plusieurs semaines.

Les robots des moteurs génératifs, eux, n'ont pas de seconde vague. Ils demandent l'URL, prennent le HTML que votre serveur renvoie, et passent à la suivante. Ce qui n'est pas dans cette réponse-là n'existera jamais pour eux.

La conséquence circule sous une forme trop générale, « les IA ne voient pas votre site », qui est fausse pour la grande majorité des sites français, et qui masque le problème réel. Cet article détaille ce qui est réellement mesuré, les trois exceptions qui changent la carte, et le niveau auquel la perte se produit vraiment : rarement la page entière, presque toujours certains blocs.

Le seul jeu de mesures publiques, et il a bientôt deux ans

Tout le marché s'appuie sur une source unique. En décembre 2024, Vercel et MERJ ont publié une analyse des journaux de leur réseau, en observant le comportement des robots d'IA sur un mois de trafic. C'est, à notre connaissance, la seule mesure de terrain à grande échelle sur la question, et tout ce que vous lirez ailleurs en dérive.

Ses résultats tiennent en trois chiffres.

Robot Volume mensuel observé Fichiers JavaScript téléchargés JavaScript exécuté
GPTBot (OpenAI) 569 millions de requêtes 11,50 % des requêtes aucun
ClaudeBot (Anthropic) 370 millions de requêtes 23,84 % des requêtes aucun
Googlebot 4,5 milliards de requêtes 15,25 % des requêtes oui

Une précision de lecture sur la dernière colonne : l'étude teste l'exécution du JavaScript chez les robots d'IA, pas chez Googlebot, dont le rendu est établi par ailleurs, par l'architecture en deux vagues que Google documente lui-même. Il figure ici comme point de comparaison de volume, pas comme résultat de la mesure.

Le détail qui compte est dans la troisième colonne : ces robots téléchargent des fichiers JavaScript sans jamais les exécuter. Vos scripts partent dans le tuyau, consomment votre bande passante, et ne produisent rien. L'analyse conclut à l'absence de toute trace d'exécution côté OpenAI, Anthropic, Perplexity, Meta, ByteDance et Common Crawl.

Deux réserves d'usage, que le marché ne formule jamais. D'abord, cette mesure date : les éditeurs de modèles ont beaucoup changé d'infrastructure depuis, et personne n'a republié de vérification équivalente. Ensuite, elle porte sur le trafic d'un hébergeur, avec la population de sites qui va avec.

Un mot enfin sur le chiffre le plus repris du sujet, « 69 % des robots d'IA n'exécutent pas le JavaScript ». Il circule sans origine stable : les pages qui l'avancent renvoient les unes aux autres, avec des périmètres et des méthodes qui ne concordent pas. Nous ne l'employons pas, et pas seulement pour cette raison. Une proportion de robots ne vous apprend rien d'exploitable : ce qui compte n'est pas combien de robots existent, mais lesquels comptent pour votre marché. Un robot confidentiel y pèse autant que GPTBot dans un pourcentage, et rien du tout dans vos citations.

Trois exceptions qui redessinent la carte

« Les IA n'exécutent pas le JavaScript » décrit correctement Perplexity, Claude, Mistral et Meta. C'est faux, ou trop simple, pour les trois cas suivants, qui représentent une part considérable des réponses générées lues en France.

Gemini, les AI Overviews et l'AI Mode passent par Googlebot. Toute la surface générative de Google est adossée à l'index de la recherche, donc au rendu de Googlebot. La documentation de Google sur les fonctionnalités IA ne pose d'ailleurs aucune exigence technique supplémentaire : pour être citée, une page doit être indexée et éligible à l'affichage d'un extrait, point. Côté Google, le rendu JavaScript n'est donc pas un problème de GEO, c'est un problème de SEO classique, avec son défaut habituel : le décalage entre l'exploration et le rendu, qui rend vos mises à jour visibles plus tard que vous ne le croyez. Nous détaillons cette surface dans nos articles sur Gemini et sur l'AI Mode.

AppleBot exécute le JavaScript. Le robot d'Apple fonctionne sur une base navigateur et traite les ressources nécessaires au rendu complet d'une page. Il compte peu en France aujourd'hui, mais il alimente les fonctions de recherche d'Apple sur un parc d'appareils considérable.

ChatGPT ne dépend pas que de son propre robot. Sa recherche web combine l'index de Bing et les explorations d'OAI-SearchBot, complétées par une récupération à la demande quand un utilisateur pointe une URL précise. Or Bing exécute le JavaScript. Avec une réserve que Microsoft énonce lui-même : ses équipes reconnaissent depuis longtemps qu'il est difficile de traiter le JavaScript à l'échelle sur toutes les pages de tous les sites, et recommandent en conséquence de servir directement une version pré-rendue aux robots.

La conclusion pratique n'est donc pas « votre site est invisible », mais : un contenu qui dépend du JavaScript survit chez Google, survit peut-être chez ChatGPT via Bing, et disparaît partout ailleurs. C'est exactement le profil d'une entreprise qui constate de bonnes positions sur Google, quelques citations dans les réponses de ChatGPT, et une absence totale chez Perplexity et Claude, sans comprendre pourquoi.

Ce n'est presque jamais la page entière

Il faut désamorcer le scénario catastrophe, parce qu'il fait perdre du temps aux équipes. L'application React ou Vue sans rendu serveur, qui renvoie une coquille vide de dix lignes, existe : c'est le cas d'école, il est réel, et il concerne surtout des applications métier et des sites vitrines de start-up.

Le parc français, lui, tourne massivement sur WordPress, PrestaShop, Shopify et Webflow, qui servent tous un HTML complet. Pour ces sites, la question « mon site est-il visible » n'a pas d'intérêt : la réponse est oui. La bonne question est quelles parties de mes pages manquent à l'appel, et la réponse est presque toujours la même liste.

  • Les onglets et les accordéons qui chargent leur contenu à l'ouverture. C'est la forme la plus fréquente en France sur les FAQ, les spécifications techniques et les modalités de livraison.
  • Les avis clients servis par un widget tiers. Le bloc d'avis affiché sur votre fiche produit vient souvent d'un script externe. Pour un robot d'IA, cette section est vide.
  • Les prix, stocks et délais injectés après chargement, typiquement quand ils dépendent d'un appel à un système de gestion. La fiche existe, le prix n'y est pas.
  • Le défilement infini et les boutons « voir plus », qui ne livrent que la première fournée d'éléments.
  • Les tableaux comparatifs interactifs, filtres et configurateurs, dont les données arrivent en JSON après le chargement.
  • Le balisage JSON-LD injecté par un script. Il annule l'intégralité de l'effort de données structurées hors de Google.

Regardez cette liste avec l'œil d'un moteur génératif. Ce ne sont pas des ornements : ce sont les prix, les caractéristiques, les questions fréquentes et la preuve sociale, c'est-à-dire précisément les éléments qu'un assistant va chercher pour répondre à une question d'achat. Le contenu qui reste accessible est votre discours de marque ; celui qui disparaît est votre information factuelle. C'est l'inversion la plus coûteuse du sujet, et elle est parfaitement invisible depuis un navigateur.

La bonne distinction n'est pas visible ou masqué, c'est servi ou injecté

Une confusion tenace mérite d'être levée, parce qu'elle conduit des équipes à défaire des interfaces qui allaient très bien.

Un contenu présent dans le HTML servi mais masqué en CSS est lu par les robots. Une FAQ en accordéon dont les six réponses sont dans le code source, simplement repliées, est intégralement accessible. Vous pouvez la laisser telle quelle.

Un contenu absent du HTML servi et injecté au clic ne l'est pas. La même FAQ, avec des réponses récupérées en appel réseau au moment où l'utilisateur déplie, n'existe pour aucun robot d'IA.

À l'écran, ces deux implémentations sont rigoureusement identiques. C'est pour cette raison que le problème échappe aux relectures, aux recettes et aux comités : personne ne le voit, et le seul moyen de trancher est de regarder ce que le serveur envoie.

Le même raisonnement s'applique un cran plus loin dans la chaîne. Un bloc absent du HTML n'est pas seulement invisible : il n'atteint jamais l'étape de découpage décrite dans notre article sur le chunking. Il n'est jamais transformé en vecteur, donc jamais candidat à une citation. Il ne perd pas la comparaison avec vos concurrents, il ne s'y présente pas.

Vérifier chez vous, en trois commandes

Le contrôle prend cinq minutes par page et ne demande aucun outil payant. Il consiste à demander votre page comme le ferait un robot d'IA, puis à y chercher ce que vous croyez y avoir mis.

Récupérez d'abord le HTML servi, en vous annonçant sous l'identité du robot de recherche d'OpenAI. Ce qui compte est le jeton OAI-SearchBot ; OpenAI publie la chaîne complète et à jour sur sa page dédiée aux robots.

curl -sA "Mozilla/5.0 (compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot)" https://votre-site.fr/page/ -o brut.html

Comparez ensuite le volume de texte à ce que vous voyez à l'écran :

wc -w brut.html

Puis cherchez une phrase précise que vous savez présente sur la page : un prix, une réponse de FAQ, une caractéristique technique.

grep -c "votre phrase exacte" brut.html

Un résultat à 0 signifie que ce contenu n'atteint aucun robot d'IA. Deux précautions de lecture : cherchez une chaîne courte et sans apostrophe typographique ni accent, car le HTML les encode et ferait échouer une correspondance pourtant valide ; et sachez que certains CDN renvoient une réponse différente selon l'agent déclaré, ce qui fait partie de ce que vous testez.

Répétez l'opération sur cinq pages représentatives : une fiche produit ou service, une page à FAQ, une page à onglets, une page de listing, et votre page d'accueil. En pratique, c'est le listing et la page à onglets qui échouent le plus souvent.

Corriger, dans l'ordre

Le classement qui suit tient compte du coût réel des interventions, pas de leur élégance technique.

  1. Servir le contenu essentiel dans le HTML initial. Rendu serveur, génération statique ou pré-rendu à la publication : peu importe le moyen, le critère est que la réponse du serveur contienne le texte. Sur les sites propulsés par un CMS classique, cela se règle le plus souvent au niveau des composants fautifs, sans refonte.
  2. Remplacer les widgets tiers par une reprise côté serveur. Les avis, les notes et les données de tarif doivent exister en HTML sur votre domaine, quitte à être rafraîchis par tâche planifiée. C'est le chantier au meilleur rendement sur les fiches produit.
  3. Basculer les accordéons et onglets en contenu servi puis masqué. Modification de quelques lignes, sans effet sur l'interface.
  4. Ajouter une pagination réelle sous le défilement infini, avec des liens href que les robots peuvent suivre.
  5. Sortir le JSON-LD du JavaScript et le poser dans la source de la page.

Pour les applications qui ne peuvent pas être converties à court terme, le pré-rendu conditionnel adressé aux robots reste une solution acceptable, à une condition stricte : la version servie doit être identique à celle vue par l'utilisateur. Dès qu'elle diffère par le contenu, ce n'est plus du pré-rendu, c'est du cloaking, et vous ajoutez un risque de sanction à un problème de visibilité.

Un point d'hygiène pour terminer, dans la même famille. L'analyse de Vercel relève qu'environ un tiers des requêtes de ChatGPT et de Claude aboutissaient sur des pages 404 : 34,82 % et 34,16 %, contre 8,22 % pour Googlebot. Notre lecture est que ces robots travaillent en grande partie à partir de listes d'URL héritées plutôt que d'une navigation vivante dans vos menus. Cela renforce deux réflexes classiques : maintenir des redirections propres, et garder un sitemap à jour. Les questions d'accès en amont, elles, sont traitées dans notre article sur les crawlers IA et le robots.txt.

Ce que ce chantier ne réglera pas

Rendre une page lisible par une machine ne la rend pas citable. C'est une condition d'entrée, pas un levier de croissance, et il faut le dire aussi clairement que le reste : une marque que les modèles ne connaissent pas ne gagnera pas de citations parce que son HTML est propre. La sélection des marques nommées se joue d'abord sur la notoriété et sur les sources tierces, et la qualité des passages sur la granularité du texte.

Ce que ce chantier explique, en revanche, c'est un écart précis : celui d'un site correctement référencé sur Google, dont la marque est connue, et qui reste absent de Perplexity, de Claude et de Mistral. Quand ce profil apparaît, la cause est technique dans une majorité de cas, et elle se corrige en quelques jours pour un coût sans rapport avec celui d'une stratégie de contenu.

L'ordre de travail que nous recommandons est donc invariable : d'abord vérifier ce que le serveur envoie, ensuite seulement discuter d'éditorial. C'est le premier contrôle d'un audit GEO, dont nous publions les fourchettes de prix. Le cadre complet est décrit sur nos pages agence de référencement IA et agence SEO et GEO ; la façon dont ces vérifications se répètent dans le temps est détaillée dans notre article sur la mesure de la visibilité IA.