Se connecter S'abonner

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

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

Une page peut parfaitement se classer sur Google, renvoyer un code 200 et ne présenter aucun problème. Cependant, cela ne veut pas dire que les robots IA peuvent parfaitement l'explorer et récupérer son contenu.

En SEO, le JavaScript est sorti de notre checklist d'audit car Google interprète le JavaScript même quand le site fonctionne intégralement avec et n'expose pas son code source au serveur comme avec un Framework de type React ou Angular. Avec cette capacité, l'usage du JavaScript a cessé d'être un frein majeur au référencement.

Cependant, maintenant que nous basculons en AI Search, les choses changent et les robots IA ne sont pas tous en mesure de faire un rendu du JavaScript. Que ce soit un composant isolé ou bien une page entière. De nombreux tests ont été fait pour le confirmer et nous allons avoir le exemples les plus parlant.

Le sujet du JavaScript redevient donc une préoccupation tant que les robots restent limités par ce niveau d'interprétation.

Pour ma part je l'ai déjà constaté lorsque je demande à ChatGPT ou Claude de résumer une page et qu'il ne parvient pas à tout voir de la page, c'est souvent le cas pour des composants de navigation qui fonctionnent exclusivement en JavaScript et qui limitent la navigation des bots IA.

Sommaire

  1. Une URL, deux lectures différentes
  2. Aucun chemin d'accès ne rend le JavaScript
  3. Une page récupérée ne veut pas dire qu'elle a été lue
  4. Où votre contenu est assemblé
  5. Ce qui bloque avant même le rendu
  6. Le premier réflexe : comparer la source avec ce que la page affiche dans le navigateur
  7. Une stratégie d'AI Search doit anticiper ces freins

Une URL, deux lecture différentes

Si on prend un site fonctionnant intégralement en JavaScript par le biais d'un framework de type React, Vue ou Angular, le serveur renvoie ici une coquille vide sans aucun contenu visible. La construction se fait directement dans le navigateur. Ce processus est entièrement invisible pour l'utilisateur comme pour Googlebot qui désormais prend en charge ce mode de fonctionnement.

On est donc ici face à un cas où le blocage concerne les bots IA qui ne peuvent rien voir et donc rien récupérer. Les pages sont donc éligibles par leur code de réponse 200 mais complètement vide aux yeux des robots.

Ce problème n'est remonté nulle part à ce jour, ni sur la search console ni sur aucun suivi de visibilité IA. La proactivité est de mise sur ce sujet qui porte une responsabilité majeure et sur laquelle on peut complètement passer à côté.

Aucun chemin d'accès ne rend le JavaScript

Quelle que soit l'origine de l'exploration par le bot IA, à savoir une exploration par la navigation ou une demande de récupération par un utilisateur sollicitant un résumé ou une analyse, le blocage du JavaScript reste confirmé.

Aucun cas ne fait figure d'exception face à ce problème et la récupération reste impossible.

Les crawlers téléchargent sans faire de rendu

Cette limitation des bots IA a été confirmée par une étude de Vercel et MERJ fin 2024 et elle reste aujourd'hui encore confirmée. Aucun des crawlers de cette catégorie n'exécute le JavaScript, il se contente simplement de télécharger les fichiers et de les collecter comme des ressources textes. On confirme qu'aucune exécution permettant le rendu de la page n'est possible par ces bots.

La seule exception à la règle est Gemini qui explore par le biais de Googlebot.

C'est une problématique majeure sachant que ChatGPT reste le modèle le plus utilisé à ce jour.

La récupération à la demande : de la mesure au leurre

Une étude très intéressante a été menée par Andre Alpar et ce test a consisté à servir une information clé (on parle ici d'un numéro de référence) accompagné d'un leurre. Le test a été réalisé sur 12 assistants, un seul site et un prompt chacun.

Le leurre est accessible à tous alors que le bon numéro lui est conditionné par du JavaScript. Je pense que vous avez compris l'idée du test et c'est clairement la meilleure méthode.

Le résultat est assez surprenant :

Une majorité des assistants IA américains (ceux que nous utilisons le plus) sont tous tombés dans le leurre et l'ont remonté. Les assistants chinois et français (Mistral) sont en revanche parvenus à trouver la bonne information.

Le constat n'est pas moindre et va même jusqu'à montrer que les assistants IA américains n'ont pas interagi avec les ressources JavaScript, ils les ont tout simplement ignorées.

Une dernière nuance, qui n'est pas anodine. La capacité d'interprétation du JavaScript peut aussi dépendre de la méthode d'exploration, un crawl du site classique vs une exploration à la demande d'une url par un utilisateur peut générer des comportements différents. Dans le cas d'une exploration à la demande, Alpar a constaté des limitations même chez Gemini, normalement en mesure d'exécuter le JavaScript.

Tableau à deux panneaux comparant deux études indépendantes. À gauche, le crawl d'indexation mesuré par Vercel et MERJ : GPTBot, OAI-SearchBot, ClaudeBot et PerplexityBot n'exécutent pas le JavaScript, seul Googlebot l'exécute. À droite, le fetch à la demande mesuré par Andre Alpar sur douze assistants : sept rapportent le leurre inscrit dans le HTML, dont Gemini, cinq rapportent le vrai numéro, dont Mistral. Le même acteur se comporte différemment selon le chemin : Googlebot exécute le JavaScript, le fetch de Gemini ne l'exécute pas.

Une page récupérée ne veut pas dire qu'elle a été lue

Le test d'Alpar ne confirme cependant pas certains aspects.

Avec Grok par exemple qui a remonté le leurre, il s'est avéré que ce dernier avait bien pourtant pu exécuter la ressource JavaScript. Il a néanmoins décidé de remonter le leurre plutôt que la bonne information.

Perplexity a quant à lui récupérée la page avec un code HTTP 200 mais affirme n'avoir pas eu accès à la page.

Une mauvaise lecture de la page ne signifie donc pas que la page n'est pas intégralement visible au robots, il faut faire particulièrement attention à cette association qui peut être trompeuse.

On peut donc utiliser les logs serveur pour savoir si un bot a trouvé une page, on ne peut par contre pas savoir s'il l'a correctement analysée.

Trois cas du test d'Andre Alpar présentés en deux colonnes, ce que disent les journaux serveur face à ce que dit la réponse de l'assistant. Copilot télécharge le fichier JavaScript via Diffbot sans l'exécuter et rapporte le leurre. Grok exécute le script, l'appel figure dans les journaux, et rapporte quand même le leurre. Perplexity récupère la page avec un code HTTP 200 puis déclare ne pas avoir pu y accéder. Savoir qu'un robot est passé et savoir ce que la réponse en a fait sont deux questions différentes.

Où votre contenu est-il assemblé ?

Pour en revenir aux framework utilisant du JavaScript, tels que React, une question se pose souvent : faut-il envisager une migration et abandonner React ?

La réponse n'est pas nécessairement "oui", la question à se poser avant d'envisager ce type de solution est de savoir à quel moment votre page est assemblée en HTML.

Si l'assemblage se fait au niveau du serveur et que le contenu est envoyé ensuite en HTML avant même qu'il n'atteigne le navigateur, alors tout est bon et les robots IA pourront parfaitement lire la page. Quel que soit le framework utilisé, le constat est le même dès lors que le contenu est assemblé côté serveur.

Ce qui reste invisible, c'est lorsque l'exécution du JavaScript se fait dans le navigateur du visiteur. Un framework ne constitue pas un frein par défaut et il est important de prendre la bonne décision avant d'engager une refonte d'urgence potentiellement non nécessaire.

Google a historiquement connu la même évolution, le JavaScript a longtemps été un frein de la même façon jusqu'à ce qu'il soit intégralement pris en charge, quel que soit le moment où le contenu est assemblé.

Avec l'AI Search, on fait un retour en arrière à cette période que l'on a connue avec Google.

On peut imaginer que les choses vont évoluer.

Ce qui bloque avant même le rendu

Nous allons maintenant voir une autre situation mais qui cette fois ne fait pas référence directement au JavaScript. On sort donc un peu du sujet de base mais cela vaut la peine d'en parler car c'est un sujet qui peut représenter un frein majeur.

Suganthan Mohanadasan documente un test très intéressant qui ouvre un débat. Sur des logs serveur, une page de son site reçoit 3 hits positifs avec des pages complètement chargées. Mais à partir du 4ème hit, la page est bloquée, un pare-feu applicatif renvoie une page de vérification qui exige d'exécuter du JavaScript avec un code HTTP 202. L'origine de ce problème provient d'une limitation de débit fixée à 3 requêtes par adresse IP.

Cette page de test, qui ne pose aucun souci côté navigateur pour un utilisateur constitue un blocage pour un robot qui n'exécute pas le JavaScript.

Cloudflare affirme avoir mis en place depuis le 1er Juillet 2026, un système de blocage équivalent. Un bot de type agent ou d'entrainement peut se retrouver bloqué sur une page affichant de la publicité. Ce changement sera un choix par défaut à partir du 15 Septembre.

Ce sont donc des choix majeurs qui ont un impact mais que vous n'avez pas nécessairement décidés. Ce sont donc des points de vigilance à suivre côté hébergeur car le blocage peut provenir même à cette étape.

Une recommandation majeure est donc de chercher les codes de réponse dans vos logs qui peuvent induire ces problèmes, les codes 202 et 499 sont les plus révélateurs de ce genre de problème.

Schéma en trois étages entre votre page et la réponse de l'IA. Un, le pare-feu : une limite de trois requêtes par adresse IP renvoie une page de vérification en code 202, et Cloudflare en fait un réglage par défaut au 15 septembre 2026 sur les nouveaux domaines. Deux, l'index : AI Mode puise dans un magasin de contenu distinct de l'index de recherche, donc indexé ne veut pas dire récupérable. Trois, le rendu : le robot lit le HTML brut et la coquille arrive vide. En contrepoint, le canal Chrome livre la page déjà rendue, mais il suppose qu'un humain ait déjà trouvé la page.

Indexé ne veut pas dire récupérable

Dan Petrovic effectue un autre test et ici rien à voir avec le JavaScript.

Son test consiste à mettre en 404 une page de son site initialement connue d'AI Mode. Quand la page passe en 404, le statut est constaté puis quand Petrovic la remet en ligne plus tard, AI Mode persiste à la voir en erreur malgré son retour dans l'index.

Son analyse montre qu'AI mode de fait pas une lecture du web en direct, il puise d'abord dans un magasin de contenu non rattachée directement à l'index de recherche.

Cela remet aussi en question le lien entre la bonne position sur Google et son impact direct sur la récupération des contenus de vos pages.

Un cas d'exception qu'il faut connaitre

On a souvent constaté que le contexte d'exploration influençait la capacité des modèles a pouvoir lire un contenu comme c'est le cas des images, qui peuvent être lues en pleine conversation mais pas lors d'une exploration de page.

On retrouve cette situation lorsque l'on partage un onglet de son navigateur à un modèle. Cette fonctionnalité s'est répandue et existe sur Chrome, Comet ou même Edge.

Dan Petrovic a réalisé un test sur cette fonctionnalité afin de voir si le JavaScript constituait un frein dans ce mode de navigation très spécifique. Il s'avère qu'ici le fonctionnement est très différent, la page n'est pas restituée à l'assistant IA en HTML mais elle est convertie en Markdown structuré. Dans ce cas particulier, le JavaScript n'est plus un frein direct à l'exploration de la page.

Il ne faut donc pas comparer ces 2 cas et porter une conclusion hâtive. Le problème d'exploration de base reste et ce cas spécifique ne résout rien au problème de base.

Le premier réflexe : comparer la source avec ce que la page affiche dans le navigateur

Le code source d'une page que vous pouvez récupérer d'un crawl comparé directement à ce que vous voyez en réel est le comparatif qui peut révéler un élément non visible aux assistants IA.

Attention au piège de la fonction qui désactive le JavaScript qui ne détermine pas si un contenu est absent du HTML, il peut simplement être masqué par un élément d'interactivité utilisant du JavaScript.

Une comparaison minutieuse de vos sources HTML avec la page réellement affichée est un moyen efficace. Il faut chercher dans la source les informations essentielles que le navigateur rend et qui n'y figurent pas.

Le contenu qui compte pour votre site doit être accessible aux assistants IA et vous devez vous assurer que ceux-ci sont chargés en rendu serveur ou génération statique. La refonte n'est pas l'option à privilégier, il est préférable de privilégier une intervention ciblée qui ne remet pas en question l'ensemble de l'architecture du site.

Une stratégie d'AI Search doit anticiper ces freins

Ces freins, moins fréquents en SEO, doivent s'anticiper davantage en AI Search. La phase d'éligibilité et d'accès aux contenus y est plus difficile. La barrière qui peut bloquer un assistant IA à votre contenu est potentiellement plus grande.

Tous ces sujets doivent donc s'anticiper très rapidement dans l'approche stratégique. Un frein à ce niveau détecté trop tardivement peut avoir un impact lourd sur le reste. Sans oublier que les outils à ce jour qui alertent de ces problèmes ne sont pas systématisés.

Bibliographie