Ce que l'IA ne voit pas de votre page : le piège du JavaScript

Votre page s'affiche parfaitement dans le navigateur. Elle est bien classée sur Google, elle reçoit du trafic, la Search Console est au vert. Et pourtant elle n'apparaît jamais dans une réponse de ChatGPT, de Claude ou de Perplexity. Non pas parce qu'un robot la bloque : parce que, pour eux, elle est vide.

Dans mon article sur le grounding, j'ai posé qu'avant d'être sélectionnée, une page doit d'abord être récupérable. J'y notais en passant une condition : que son contenu soit lisible sans JavaScript. Cette phrase d'une ligne recouvre l'un des pièges les plus contre-intuitifs de l'AI search.

Ce piège mérite qu'on s'y arrête, car il a deux étages : le robot doit recevoir votre contenu, et la réponse doit s'en servir. Ce sont deux questions différentes.

Résumé exécutif

• Les robots qui alimentent ChatGPT, Claude et Perplexity lisent le HTML brut envoyé par le serveur. Tout contenu construit par JavaScript dans le navigateur leur est invisible.
• Deux chemins d'accès, deux mesures indépendantes : les crawlers d'indexation (étude Vercel et MERJ) comme le fetch à la demande (test d'Andre Alpar sur 12 assistants) échouent au rendu côté US. Mistral et les quatre assistants chinois testés, eux, exécutent le script.
• Chez Google, les deux chemins divergent : Googlebot rend le JavaScript pour l'indexation, le fetch de Gemini ne le rend pas.
• Récupéré n'est pas lu : Grok exécute le script et sa réponse l'ignore. Vos logs disent qu'un robot est passé, jamais que la réponse s'est servie de ce qu'il a trouvé.
• Le correctif ne change pas : le contenu qui compte doit être présent dans le HTML envoyé par le serveur, en rendu côté serveur ou en génération statique, au moins sur les pages que vous voulez voir citées.

Sommaire

1. Une URL, deux lecteurs
2. Aucun chemin d'accès ne rend le JavaScript
3. Récupéré n'est pas lu
4. Ce n'est pas React, c'est l'endroit du rendu
5. Ce qui bloque avant même le rendu
6. Vérifier, puis corriger
7. Voir avant d'être retenu

Une URL, deux lecteurs

Le cas typique est celui d'un site bâti comme une application : React, Vue ou Angular. La page envoyée par le serveur n'y est qu'une coquille, un conteneur vide accompagné d'un script qui va chercher le contenu pour le construire dans le navigateur. Pour un visiteur humain, tout se passe bien : le script s'exécute, les données arrivent, la page s'affiche en une seconde. Pour Googlebot aussi, qui sait exécuter ce script et indexe le résultat.

La page se positionne, elle reçoit des visites : tout dit qu'elle fonctionne. Mais les robots qui alimentent ChatGPT, Claude et Perplexity ne procèdent pas ainsi. Ils demandent la page, lisent le HTML brut tel que le serveur le renvoie, et repartent. Ce qu'ils reçoivent, c'est la coquille, pas le contenu.

Une seule et même URL, deux lecteurs, deux résultats opposés. Et le piège tient justement là : aucun de vos indicateurs habituels ne le révèle.

Aucun chemin d'accès ne rend le JavaScript

La raison tient à la façon dont ces systèmes accèdent au web : par deux chemins distincts. Le premier est le crawl d'indexation, où un robot parcourt les pages en continu pour alimenter un index. Le second est le fetch à la demande : une récupération ponctuelle, déclenchée quand un utilisateur colle une URL dans la conversation ou que la réponse exige une lecture en direct. Les deux ont été mesurés séparément, par deux méthodes indépendantes, et côté américain aucun des deux ne rend le JavaScript.

Dans les deux cas, c'est un problème de récupération, pas de génération. Pour reprendre le cadre des deux mécanismes : tout se joue en amont de la phase où l'IA recompose sa réponse, et même en amont de ce qu'elle retient d'une page. Si le contenu n'est pas dans le HTML reçu, il n'entre jamais dans le périmètre. Rien à sélectionner, rien à citer.

Le crawl d'indexation : télécharger sans exécuter

C'est le versant documenté à grande échelle. Une étude conjointe de Vercel et MERJ, menée fin 2024 et que les analyses de mi-2026 confirment toujours, a passé au crible des centaines de millions de requêtes. Verdict : aucun des grands crawlers IA n'exécute le JavaScript. Ni GPTBot et OAI-SearchBot du côté d'OpenAI, ni ClaudeBot chez Anthropic, ni PerplexityBot.

Le détail le plus parlant n'a pas changé : ces robots téléchargent bien les fichiers JavaScript de vos pages, mais ne les exécutent jamais. Ces téléchargements représentent environ 11,5 % des requêtes côté ChatGPT et 23,8 % côté Claude. Les robots les collectent comme du texte, sans rien produire du contenu qu'ils sont censés construire.

Sur ce chemin, une exception existe : le crawl qui alimente Gemini s'adosse à l'infrastructure de rendu de Googlebot, et sait donc exécuter le JavaScript. Retenez la précision qui suit, car elle ne vaut que pour ce chemin-là.

Le fetch à la demande : la mesure au leurre

Le versant fetch restait une zone grise. Andre Alpar l'a mesuré en juin 2026, avec un protocole qui ne laisse aucune place à l'interprétation. Il construit une page dont le HTML brut affiche un numéro de référence leurre, une valeur fausse posée là pour les bots IA. Une ligne de JavaScript externe va chercher le vrai numéro sur un second point d'accès et le substitue dans la page.

Le point décisif : le vrai numéro n'existe ni dans le HTML, ni dans le code source du script. On ne peut l'obtenir qu'en exécutant le programme. Alpar colle ensuite une URL secrète à chacun de douze assistants, puis lit ses journaux serveur. Trois questions, trois traces : la page a-t-elle été demandée, le fichier JavaScript a-t-il été téléchargé, le second point d'accès a-t-il été appelé.

Le partage est net, et personne dans son équipe ne l'avait prédit. Les sept assistants américains rapportent le leurre : ChatGPT, Claude, Gemini, Perplexity, Meta AI, Copilot et Grok. Les quatre assistants chinois, DeepSeek, ERNIE, Qwen et Kimi, rapportent le vrai numéro. Et Mistral aussi.

Autrement dit, les assistants qui verraient votre contenu JavaScript ne sont pas nécessairement ceux que votre audience utilise au quotidien.

Le dénominateur mérite d'être posé : douze assistants, un seul prompt chacun, un passage unique. Alpar l'assume, car la question n'a que deux réponses possibles, et un passage propre suffit à la trancher. Un marqueur témoin confirme d'ailleurs que chaque lecture rapportée est réelle : les réponses au leurre ne sont pas des hallucinations, ce sont des lectures fidèles d'un HTML brut.

Deux chemins chez le même acteur

Le résultat le plus contre-intuitif du test est celui de Google : Googlebot rend le JavaScript, le fetch de Gemini ne le rend pas. Deux chemins, deux comportements, chez le même acteur. L'équipe d'Alpar s'est d'ailleurs trompée deux fois avant de mesurer : d'abord « Gemini rendra, c'est Google », puis « personne ne rend ». Seuls les logs ont tranché.

Ce constat impose sa propre limite, et elle compte. Alpar n'a mesuré que le fetch déclenché par l'utilisateur, et il écrit lui-même que les crawlers d'indexation en arrière-plan peuvent très bien se comporter autrement. Les deux corpus ne se fondent donc jamais : l'étude Vercel et MERJ parle du crawl, le test d'Alpar parle du fetch, et aucun des deux ne parle pour l'autre.

La conclusion honnête n'est donc pas « les robots IA ne rendent pas le JavaScript ». C'est : sur chacun des deux chemins mesurés, les systèmes américains lisent le HTML brut. Pour votre contenu injecté côté client, la conséquence pratique est la même.

Récupéré n'est pas lu

Le test d'Alpar réserve deux cas qui cassent une lecture trop simple, et ils valent qu'on s'y arrête. Copilot est le seul assistant américain à avoir téléchargé le fichier JavaScript, par l'intermédiaire de Diffbot, son fournisseur de récupération. Mais télécharger n'est pas exécuter : aucun appel de suivi n'apparaît dans les journaux, et Copilot rapporte le leurre.

Grok va un cran plus loin, puis pose le résultat. Un nœud de son infrastructure a réellement exécuté le script : l'appel vers le second point d'accès figure dans les logs. Et sa réponse cite quand même le leurre. La mécanique a tourné, la réponse l'a ignorée.

Un troisième détail complète le tableau : Perplexity déclare dans la conversation ne pas avoir pu accéder à la page, alors que les journaux montrent que son robot l'a récupérée avec un code 200. Ce qu'un assistant raconte de sa propre récupération ne décrit pas ce qui s'est passé côté serveur.

Il faut donc séparer deux questions qu'on confond presque toujours. « Un robot a-t-il touché ma page ? » et « la réponse s'est-elle servie de ce qu'il a trouvé ? » sont deux questions différentes. Vos journaux serveur répondent à la première. Rien, dans vos outils, ne répond à la seconde.

Ce n'est pas React, c'est l'endroit du rendu

Ces mesures écartent une conclusion fausse, « il faut abandonner React », et désignent le vrai problème. Le coupable n'est pas le framework, c'est l'endroit où le contenu est produit.

Si votre page est rendue côté serveur, autrement dit si le serveur assemble le contenu et l'envoie déjà complet dans le HTML, les robots IA la lisent sans difficulté, quel que soit l'outil employé. React, Vue ou Angular conviennent parfaitement dès lors qu'ils s'exécutent côté serveur (le rendu côté serveur, ou SSR) ou produisent des pages figées à la construction (la génération statique). Ce qui est invisible, ce n'est pas React : c'est tout ce qui n'apparaît qu'après l'exécution du JavaScript dans le navigateur du visiteur. Le critère n'est donc pas « quel framework », mais « où le contenu est-il assemblé : sur le serveur, ou dans le navigateur ? ».

Pendant des années, faire lire le JavaScript aux moteurs a été le problème du référencement technique, et Google l'a résolu. Googlebot exécute le JavaScript depuis longtemps, au point que Google a retiré de sa documentation, le 4 mars 2026, la section qui recommandait de concevoir des pages lisibles sans JavaScript. La justification donnée au changelog est explicite : l'information était périmée, Google Search rend le JavaScript depuis plusieurs années.

Le réflexe est donc naturel : « le JavaScript, c'est réglé. » Sauf que ce constat ne vaut que pour Google. La même documentation continue d'ailleurs de recommander le rendu côté serveur, précisément parce que tous les robots ne savent pas rendre le JavaScript. Un site qui « marche » pour Google peut très bien rester muet pour l'IA, justement parce qu'on a cru le problème derrière soi.

Ce qui bloque avant même le rendu

Le rendu n'est pas le seul étage où une page peut disparaître. Deux blocages interviennent en amont, avant même que la question du JavaScript se pose. Et un canal fait exactement l'inverse : il livre la page déjà rendue.

Le firewall décide avant le robots.txt

Suganthan Mohanadasan documente le cas sur un site client, logs à l'appui. Les trois premières requêtes reçoivent la page complète. À partir de la quatrième, le pare-feu applicatif, réglé sur une limite de débit trop stricte, cesse de servir le contenu. Il renvoie à la place un challenge JavaScript, une page de vérification qui exige d'exécuter du script, avec un code HTTP 202.

Dans un navigateur, personne ne le remarque : le challenge se résout tout seul en arrière-plan. Pour un robot IA, qui n'exécute pas de JavaScript, c'est un mur.

La conséquence dépasse la page bloquée. Pour construire une réponse, un agent tire plusieurs de vos pages dans une même session. Verrouillé au bout de trois, il ne renonce pas : il se rabat sur un tiers qui parle de vous.

Vous perdez la page, et vous perdez le récit qu'on fait de vous.

Une seconde signature complète la première : le code HTTP 499, celui des pages abandonnées parce qu'elles répondent trop lentement pour une récupération en temps réel.

Indexé ne veut pas dire récupérable

Dan Petrovic apporte le deuxième blocage, par un test simple. Il supprime une page de son site, constate qu'AI Mode la voit en 404, puis la remet en ligne. La recherche classique la retrouve, indexée et positionnée. AI Mode, lui, continue de se comporter comme si elle n'existait pas.

Son explication : pendant la récupération, AI Mode ne lit pas le web en direct, il puise dans un magasin de contenu distinct de l'index de recherche. L'observation converge avec FastSearch, l'infrastructure de grounding révélée par les pièces du procès antitrust de Google. La conséquence : être indexé et bien positionné ne garantit pas d'être récupérable par la couche IA.

Le contrepoint : le canal Chrome livre la page rendue

Un chemin fait exception. Quand un utilisateur partage un onglet avec Gemini, Chrome ne transmet pas le HTML de la page. Il transmet une représentation structurée de la page telle qu'elle est rendue dans la session, convertie en Markdown.

Dan Petrovic l'a reconstitué à partir du code source de Chromium, puis confirmé par des tests directs. Ce que l'utilisateur voit à l'écran, l'IA le voit, y compris derrière une authentification.

Sur ce canal, le JavaScript n'est plus un obstacle : la page arrive déjà rendue, exécutée par le navigateur de l'utilisateur. Le même Gemini qui lit votre HTML brut au fetch reçoit ici votre page complète. Le régime d'accès n'est pas une propriété du moteur : c'est une propriété du chemin emprunté.

Reste la question pratique : savoir si votre site est concerné, et corriger. La vérification est plus simple qu'on ne le croit.

Vérifier, puis corriger

Le test le plus rapide ne demande aucun outil. Affichez le code source de la page (clic droit, « afficher le code source »), ou désactivez le JavaScript dans votre navigateur puis rechargez. Vous voyez alors la page telle qu'un robot IA la reçoit. Si le texte, les prix, les descriptions, les réponses de votre FAQ ou vos tableaux comparatifs disparaissent, c'est qu'ils dépendent du JavaScript : ces robots ne les verront pas.

Une précision s'impose, car Google a justement retiré ce test de sa documentation en mars 2026. Il ne reflète plus ce que voit Googlebot, c'est exact. Mais Il ne reflète plus ce que voit Googlebot, c'est exact, mais il reflète précisément ce que reçoivent les robots IA. Les pages les plus exposées sont souvent les pages produit et les comparatifs, justement celles que l'IA cite le plus en e-commerce.

Une vérification plus fine passe par vos logs serveur, avec deux contrôles. Le premier : GPTBot, ClaudeBot ou OAI-SearchBot repartent-ils avec une vraie page, un code 200 et du HTML, ou avec une coquille vide ? Le second : voyez-vous des codes 202 ou 499 sur leurs requêtes ? Ce sont les signatures d'un pare-feu ou d'un délai qui bloquent la récupération avant même la question du rendu.

Gardez toutefois la limite en tête : ces logs disent ce qu'un robot a reçu, jamais ce que la réponse en a fait.

Le contenu qui compte doit être présent dans le HTML envoyé par le serveur. Concrètement, on bascule les pages importantes en rendu côté serveur ou en génération statique, ce que des outils comme Next.js ou Nuxt font nativement. Le rendu côté navigateur reste tout à fait valable pour ce qui n'est pas essentiel : un compteur de vues, un widget interactif, un fil de discussion. Et il n'est pas nécessaire de refondre tout le site : il suffit le plus souvent de traiter les quelques pages que vous voulez voir citées.

Voir avant d'être retenu

La visibilité dans l'AI search commence plus tôt qu'on ne l'imagine. Avant les facteurs de citation, avant même ce que l'IA retient d'une page, il y a une condition que rien ne signale dans vos tableaux de bord habituels : que le robot reçoive quelque chose. Une coquille vide n'est pas une page mal optimisée : c'est une page absente.

Cette condition se vérifie chemin par chemin. Le crawl d'indexation et le fetch à la demande ne lisent pas votre page de la même façon, et ce qu'un robot a reçu ne dit pas encore ce que la réponse en a fait. Le correctif, lui, est unique : servir le contenu dans le HTML couvre les deux chemins à la fois.

Ce n'est pas un nouveau levier réservé à l'AI search. C'est une exigence technique de base, du même ordre que rendre un site accessible aux moteurs. Une fois cette condition remplie, la page est visible. La vraie question redevient alors celle que je traitais dans l'article sur le grounding : non plus « l'IA voit-elle votre page ? », mais « qu'en retient-elle ? ».