Le SEO JavaScript se décide dans le HTML que votre serveur envoie. Google exécute le JavaScript depuis des années, mais en différé, avec un navigateur qui ne se comporte pas comme le vôtre.
Les robots d’OpenAI, d’Anthropic et de Perplexity testés en 2024 par Vercel et MERJ ne l’exécutent pas. Nous avons recoupé la documentation de Google, leur étude et nos propres journaux serveur de septembre 2026 pour montrer ce que chaque robot peut lire de vos pages, et comment le vérifier.
Qu’est-ce que le SEO JavaScript ?
Le SEO JavaScript regroupe les réglages qui permettent aux moteurs d’explorer, de rendre et d’indexer un site dont le contenu passe par JavaScript : React, Vue, Angular, Next.js, Nuxt. Son diagnostic compare deux états de chaque page : le HTML envoyé par le serveur et la page obtenue une fois le JavaScript exécuté.
Un visiteur voit la page une fois tous les scripts exécutés. Un robot reçoit d’abord le HTML brut.
Si ce HTML ne contient qu’un conteneur vide et l’appel d’un fichier JavaScript, le moteur doit rendre la page pour trouver le texte et les liens. Google le fait, en différé ; la plupart des robots d’IA étudiés par Vercel ne le font pas.
Comment Google traite-t-il le JavaScript ?
Selon sa documentation, Google explore la page, la rend, puis l’indexe. Googlebot met en file d’attente de rendu toute page qui répond 200, sauf si une balise ou un en-tête robots interdit l’indexation. Elle y reste quelques secondes, parfois plus, puis un Chromium sans interface exécute le JavaScript.
Une fois la page rendue, Googlebot relit le HTML obtenu pour y trouver de nouveaux liens, et Google indexe ce HTML rendu.
Le 4 mars 2026, Google a retiré de sa documentation sur le SEO JavaScript un passage daté sur JavaScript et l’accessibilité. Son explication : « Google Search has been rendering JavaScript for multiple years now, so using JavaScript to load content is not “making it harder for Google Search” ».
Trois précisions publiées en décembre 2025 visent les sites JavaScript. Google peut sauter le rendu d’une page qui ne répond pas 200. Une page dont le code d’origine porte un noindex peut ne pas être rendue du tout : retirer cette balise par script ne fonctionne pas de façon fiable.
Pour ce noindex retiré par script, Google prévient que le comportement « is not well defined and might change ». Google détermine aussi l’URL canonique avant et après le rendu : gardez la même URL dans le HTML d’origine et après exécution, ou laissez-la hors du HTML d’origine.
Pour les liens, la règle ne bouge pas : Google ne découvre que les éléments a dotés d’un attribut href. Une application monopage doit changer d’URL avec l’API History ; un fragment (#/page) ne charge pas une page distincte aux yeux de Google.
Ce que le moteur de rendu de Google fait autrement qu’un navigateur
Le service de rendu de Google, le Web Rendering Service (WRS), ressemble à Chrome, avec des contraintes qu’un navigateur n’a pas. Le tableau distingue ce que Google documente de ce que des tests publics ont mesuré.
| Ce que fait le robot | Conséquence pour vos pages | Qui l’établit |
|---|---|---|
| Garde en cache JavaScript et CSS jusqu’à 30 jours, sans tenir compte de vos en-têtes HTTP | Après une mise en production, Google peut rendre le nouveau HTML avec l’ancien script. Nommez vos fichiers d’après leur contenu (main.2bb85551.js) pour que chaque version porte un nom neuf. | Google : blog Search Central (décembre 2024) et documentation |
| Ne conserve rien d’une page à l’autre : Local Storage, Session Storage et cookies sont vidés | Un contenu qui dépend d’une préférence enregistrée ou d’un cookie s’affiche pour Google dans son état par défaut. | Google : documentation (décembre 2025) |
| Refuse les demandes d’autorisation et n’ouvre ni WebSocket ni WebRTC | Un contenu livré par WebSocket ou derrière une autorisation (la caméra, par exemple) reste invisible sans requête HTTP de repli. | Google : même documentation |
| N’interagit pas avec la page : ni défilement, ni clic | Un contenu ou une image chargée au défilement, sur l’événement scroll, n’existe pas pour Google. Le chargement différé natif (attribut loading) ou par IntersectionObserver, que Google recommande, ne pose pas ce problème. Un défilement infini doit exposer chaque tranche sous une URL propre. | Google : documentation sur le chargement différé |
| Arrête le rendu quand la page ne fait plus rien, sans limite fixe de 5 secondes | Deux appels de 3 à 6 secondes chacun ont été rendus et indexés. Le risque vient d’une page qui ne se tait jamais : en indexation, une boucle de requêtes sans fin a été coupée vers 30 secondes, avec des écarts d’un test à l’autre. | Tests publics de Dave Smart (juillet 2026), mécanisme expliqué par Martin Splitt, de Google |
| En indexation, fait partir son horloge de minuit UTC et renvoie toujours la même suite de nombres « aléatoires » | Un test A/B, une rotation d’avis ou un « ouvert maintenant » calculé en JavaScript montre à Google la même version, à chaque passage. | Tests publics de Tony McCreath (janvier 2025) et de Dave Smart |
Une page qui livre son texte et ses liens dans le HTML du serveur échappe à la plupart de ces pièges : ce qui doit être indexé ne dépend plus du rendu.
Nous avons appliqué ces règles à getknown.fr en septembre 2026. Lenis, le script qui anime le défilement vers les ancres, faisait tourner sa boucle d’animation 60 fois par seconde sur une page immobile.
Par prudence, cette boucle ne démarre plus qu’au clic sur une ancre. Le fichier porte aussi l’empreinte de son contenu (lenis.b2958f14.min.js), et l’ancien reste en ligne au moins 30 jours pour les pages encore en cache qui l’appellent.
Les robots des IA exécutent-ils le JavaScript ?
Les robots d’OpenAI, d’Anthropic et de Perplexity n’exécutent pas le JavaScript, d’après l’étude publiée par Vercel et MERJ en décembre 2024. Gemini, adossé à l’infrastructure de Googlebot, et Applebot rendent les pages. Un texte ajouté par script échappe donc aux robots testés de ChatGPT, Claude et Perplexity.
L’étude de Vercel repose sur le trafic de nextjs.org et du réseau de Vercel, recoupé sur deux sites d’offres d’emploi. Les volumes sont élevés : en un mois, 569 millions de requêtes de GPTBot et 370 millions de Claude, contre 4,5 milliards pour Googlebot.
Les robots de ChatGPT et de Claude téléchargent bien des fichiers JavaScript (11,50 % et 23,84 % de leurs requêtes), sans les exécuter. Vercel note une nuance : des données présentes dans la réponse HTML initiale, un bloc JSON par exemple, peuvent quand même être prises en compte.
Ce que montrent nos journaux serveur
Nous avons fait le même relevé sur getknown.fr, dans le journal Apache du 31 août au 28 septembre 2026. Nous n’avons gardé que les requêtes venues des adresses IP publiées par l’éditeur de chaque robot.
N’importe quel outil peut se présenter comme un robot : 1 738 des 2 780 requêtes signées Googlebot venaient d’adresses absentes des listes de Google. Au moins 1 480 d’entre elles sont parties de notre propre connexion les 17 et 18 septembre, lors de nos audits.
| Robot | Éditeur | Requêtes vérifiées | Fichiers JavaScript | Part des requêtes |
|---|---|---|---|---|
| Googlebot | 1 042 | 368 | 35,3 % | |
| ClaudeBot | Anthropic | 435 | 81 | 18,6 % |
| bingbot | Microsoft | 812 | 107 | 13,2 % |
| OAI-SearchBot | OpenAI | 430 | 27, dont 24 pour notre script de statistiques | 6,3 % |
| GPTBot | OpenAI | 158 | 4 | 2,5 % |
| ChatGPT-User | OpenAI | 451 | 0 | 0 % |
« Vérifiée » : adresse IP comprise dans les plages publiées par Google, Microsoft, OpenAI, Anthropic et Perplexity, téléchargées le 28 septembre 2026. Aucune requête signée PerplexityBot, Perplexity-User, Claude-SearchBot ou Claude-User ne venait des adresses publiées par leur éditeur sur la période : nous ne pouvons pas les leur attribuer.
Sous les noms PerplexityBot et Claude-SearchBot, les URL les plus demandées étaient des fichiers système, de configuration ou d’identifiants (config.json, aws-credentials) : le profil d’un scanner de failles. Aucune de leurs 44 requêtes n’a obtenu de page.
Un fichier téléchargé ne prouve pas qu’un robot l’exécute. Sur getknown.fr, ClaudeBot a récupéré en proportion plus de scripts que bingbot ; Vercel relevait déjà 23,84 % de fichiers JavaScript dans les requêtes de Claude, sans exécution. Le cas de ChatGPT-User est plus net : OpenAI l’envoie sur une page quand un utilisateur de ChatGPT pose une question.
En 29 jours, il a fait 451 requêtes de pages, dont 390 sur la page d’accueil, sans récupérer un seul fichier JavaScript.
Nos journaux vont dans le sens de l’étude de Vercel : ce robot s’en tient au HTML servi. Googlebot a consacré plus du tiers de ses requêtes vérifiées aux scripts : il en a besoin pour rendre les pages.
Pour que ChatGPT, Claude ou Perplexity lisent votre texte, vos liens internes et vos données structurées, placez-les dans le HTML que le serveur envoie. C’est la condition de départ du GEO hors de Google, détaillée dans notre comparatif SEO, GEO et AEO.
Les Aperçus IA et le mode IA de Google puisent, eux, dans l’index de Google Search : d’après son guide d’optimisation pour l’IA générative, une page doit y être indexée et pouvoir s’afficher avec un extrait. Notre audit GEO mesure votre visibilité dans ChatGPT, Perplexity et les Aperçus IA.
CSR, SSR ou SSG : quel mode de rendu choisir pour le SEO ?
Pour toute page qui doit être trouvée, choisissez un mode qui livre le contenu dans le HTML : rendu côté serveur (SSR), génération statique (SSG) ou hydratation d’un HTML déjà rempli, les trois solutions que Google recommande. Le rendu côté client (CSR) convient aux espaces connectés et aux outils qui n’ont pas à être indexés.
Rendu côté client (CSR)
Le serveur envoie un HTML presque vide et un paquet de JavaScript ; le navigateur construit toute la page. C’est le fonctionnement d’une application monopage lancée sans rendu serveur. Google peut rendre ces pages, en différé. Les robots d’IA étudiés par Vercel n’en voient que la coquille.
Rendu côté serveur (SSR)
Le serveur exécute le JavaScript à chaque requête et renvoie un HTML rempli : robot et visiteur reçoivent le contenu dès la première réponse. Next.js, Nuxt, Angular (rendu serveur intégré) et React Router en mode framework le proposent. En contrepartie, chaque page vue sollicite le serveur, qu’il faut dimensionner et surveiller.
Génération statique (SSG)
Les pages HTML sont produites au moment de la construction du site, puis servies telles quelles. Le HTML est complet dès la première réponse et la charge serveur reste minimale.
Le format convient à un blog, une documentation ou un site vitrine. Sur un catalogue qui change toutes les heures, chaque mise à jour impose une nouvelle construction.
Modes hybrides et pré-rendu
Les frameworks récents mélangent les modes page par page : statique pour les pages stables, rendu serveur pour les pages personnalisées, hydratation pour l’interactivité.
La régénération incrémentale (ISR, dans Next.js) reconstruit une page statique après un délai, sans reconstruire tout le site. Pour chaque modèle de page qui compte, vérifiez une seule chose : son contenu part-il dans le HTML, ou attend-il le JavaScript ?
| Mode | Contenu dans le HTML envoyé | Lisible sans exécuter le JavaScript | Charge serveur | Pages adaptées |
|---|---|---|---|---|
| CSR (côté client) | Non, page vide au départ | Non | Basse | Espace client, back-office |
| SSR (côté serveur) | Oui, à chaque requête | Oui | Élevée | Catalogue, média, contenu qui change souvent |
| SSG (statique) | Oui, à la construction du site | Oui | Très basse | Blog, documentation, site vitrine |
| Hybride (SSG ou SSR, puis hydratation) | Oui, pour les pages pré-rendues | Oui, pour ces pages | Variable | Site mixte, contenu et application |
| Rendu dynamique (HTML pré-rendu servi aux seuls robots) | Pour les robots reconnus | Pour les agents de votre liste | Élevée | Transition, déconseillé par Google |
Notre règle en audit : fiches produit, articles, catégories et pages de service partent dans le HTML servi. Le CSR garde sa place derrière une connexion, dans un tableau de bord par exemple.
Comment vérifier ce que Google a indexé de votre page JavaScript ?
Ouvrez l’inspection d’URL de la Search Console : elle décrit la version indexée par Google, et « Afficher la page explorée » en donne le HTML. Comparez-le au HTML envoyé par votre serveur. Le test en direct récupère la page en temps réel : il ne montre pas forcément ce que Google a gardé.
- Lisez le HTML servi. « Afficher le code source » ou une requête curl montrent ce que reçoit un robot qui n’exécute pas le JavaScript. L’inspecteur du navigateur montre le DOM après exécution : l’écart entre les deux, c’est ce que Google doit rendre. Un navigateur dont le JavaScript est désactivé donne un aperçu comparable.
- Ouvrez la version indexée. Dans l’inspection d’URL, « Afficher la page explorée » donne le HTML de la version indexée ; « Afficher la page testée », celui du test en direct. Selon l’aide de la Search Console, ces détails n’existent que pour une URL présente dans l’index : pour une page non indexée, seul le test en direct reste consultable.
- Expliquez les écarts. D’après les tests de Dave Smart et de Tony McCreath, Google garde les scripts en cache jusqu’à 30 jours et fait partir son horloge d’indexation de minuit UTC. Le test en direct, lui, charge des scripts frais à l’heure réelle. Après une mise en production, attendez un nouveau passage avant de conclure.
- Passez à l’échelle du site. Un crawler qui exécute le JavaScript, Screaming Frog avec le rendu activé par exemple, compare HTML servi et HTML rendu sur toutes les URL. Il repère les pages dont le texte n’apparaît qu’après exécution.
- Consultez vos journaux serveur. Ils disent quels robots récupèrent vos scripts, et à quelle fréquence. Vérifiez chaque adresse IP contre les listes publiées par Google et par les éditeurs d’IA avant d’en tirer une conclusion.
Cette méthode est celle du volet technique de notre audit SEO : nous jugeons une page sur le HTML que reçoit le robot. Notre guide du SEO technique détaille les autres contrôles d’exploration et d’indexation.
Quelles erreurs de SEO JavaScript bloquent l’indexation ?
Google documente cinq erreurs de SEO JavaScript : scripts bloqués par le robots.txt, liens sans balise a ni attribut href, noindex retiré par script, URL canonique changée en JavaScript, pages d’erreur qui répondent 200. S’y ajoutent un contenu absent du HTML servi, invisible aux robots d’IA sans rendu, et un paramètre anti-cache aléatoire ou horodaté.
| Erreur | Effet | Correction |
|---|---|---|
| Fichiers JavaScript ou CSS bloqués dans le fichier robots.txt | Google analyse mal une page qui dépend de ces fichiers | Ne bloquer que des ressources sans effet sur le rendu |
| Liens en onclick, boutons ou fragments (#/page) | Google ne découvre que les éléments a dotés d’un attribut href | Balises <a href> et changement d’URL par l’API History |
| Noindex dans le HTML d’origine, retiré par script | Google peut sauter le rendu : la page reste exclue | Aucun noindex dans le code d’origine d’une page à indexer |
| URL canonique changée en JavaScript | Deux signaux contradictoires, avant et après le rendu | Même canonique avant et après le rendu, ou aucune dans le HTML d’origine |
| Page d’erreur d’une application monopage qui répond 200 | Page d’erreur indexée (soft 404) | Redirection JavaScript vers une URL qui répond 404, ou noindex ajouté par script |
| Contenu et liens absents du HTML servi | Invisibles pour les robots d’IA sans rendu, rendus en différé par Google | SSR ou SSG pour les pages à trouver |
| Paramètre anti-cache calculé en JavaScript à partir d’un nombre aléatoire ou de l’heure | Chez Google, la suite aléatoire est fixe et l’horloge part de minuit UTC (tests publics) : le paramètre ne suit pas vos déploiements | Nom de fichier tiré du contenu, changé à chaque déploiement |
Les Core Web Vitals sont un autre chantier. Un JavaScript lourd peut dégrader le LCP (affichage du plus grand élément) et l’INP (réactivité aux interactions), Core Web Vital depuis le 12 mars 2024.
Une page peut être rendue et indexée sans défaut tout en restant lente : traitez les deux sujets séparément, avec notre guide des Core Web Vitals.
Quels outils pour diagnostiquer le SEO JavaScript ?
La Search Console donne la version indexée, et le test des résultats enrichis un rendu à la demande. Un crawler qui exécute le JavaScript compare HTML servi et HTML rendu ; vos journaux serveur disent quels robots récupèrent vos scripts. Ces quatre outils suffisent pour diagnostiquer le SEO JavaScript.
- Search Console, inspection d’URL : seule source sur la version indexée ; les détails n’existent que pour une URL présente dans l’index.
- Test des résultats enrichis : rend la page à la demande. Google conseille d’y saisir l’URL : la saisie de code limite l’exécution du JavaScript. Comme le test en direct, il ne dit rien du cache ni de l’horloge du vrai passage.
- Crawler avec rendu JavaScript (Screaming Frog, par exemple) : compare HTML servi et HTML rendu à l’échelle du site. Son navigateur n’applique ni le cache de 30 jours ni l’horloge de Google.
- Journaux serveur : montrent ce que chaque robot demande, robots d’IA compris, une fois les adresses IP vérifiées.
Lighthouse et PageSpeed Insights servent un autre besoin : mesurer ce que le JavaScript coûte en performance.
FAQ : SEO JavaScript
Faut-il encore faire du rendu dynamique ?
Google déconseille le rendu dynamique : sa documentation le qualifie de contournement provisoire et recommande le rendu côté serveur, le rendu statique ou l’hydratation. Autre limite : il ne sert que les robots que vous avez listés, et un robot d’IA absent de la liste reçoit la page non rendue.
Googlebot comprend-il le JavaScript moderne ?
Oui. Depuis mai 2019, Googlebot rend les pages avec la version la plus récente de Chromium et Google s’est engagé à la mettre à jour régulièrement. Si vous transpilez ou ajoutez des polyfills pour Googlebot seul, Google invite à vérifier qu’ils restent nécessaires. Certaines fonctions manquent, WebGL par exemple : prévoyez un repli.
Bing exécute-t-il le JavaScript ?
Oui. Le 9 octobre 2019, Bing a annoncé qu’il exécuterait le JavaScript et rendrait les pages avec Microsoft Edge, bâti sur Chromium, en suivant sa dernière version stable. Sur getknown.fr, bingbot a téléchargé 107 fichiers JavaScript du 31 août au 28 septembre 2026, soit 13 % de ses requêtes vérifiées.
Google lit-il un JSON-LD ajouté en JavaScript ?
Oui : Google peut traiter un JSON-LD ajouté en JavaScript s’il figure dans le HTML rendu. Pour les fiches produit, il prévient qu’un balisage généré dynamiquement rend les explorations Shopping moins fréquentes et moins fiables. Les robots d’IA qui n’exécutent pas le JavaScript ne voient pas ce balisage : placez-le dans le HTML servi.
React, Vue ou Angular posent-ils des problèmes de SEO ?
React, Vue et Angular ne gênent pas le SEO par eux-mêmes. Sans rendu serveur, ils construisent la page dans le navigateur : Google doit la rendre et la plupart des robots d’IA n’en voient que la coquille. Next.js pour React, Nuxt pour Vue et le rendu serveur d’Angular livrent le contenu dans le HTML servi.
Le contenu d’un composant web (shadow DOM) est-il indexé ?
Google indique que son moteur de rendu aplatit le light DOM et le shadow DOM. Si vos composants web n’utilisent pas l’élément slot pour le contenu du light DOM, contrôlez le HTML rendu dans le test des résultats enrichis ou l’inspection d’URL. S’il manque du texte, ajoutez l’élément slot au composant.
Par où commencer ?
Sur un site JavaScript, commencez par comparer le HTML servi et le HTML rendu de vos cinq modèles de page les plus visités. Ouvrez ensuite leur version indexée dans la Search Console après chaque mise en production. Enfin, lisez un mois de journaux serveur, adresses IP vérifiées, pour savoir quels robots lisent quoi.
Si vous ne savez pas ce que Google et les robots d’IA lisent de votre site JavaScript, un diagnostic sur quelques URL le montre. Parlez-nous de votre projet.
Sources
- Google Search Central, Understand JavaScript SEO basics, mise à jour du 4 mars 2026.
- Google Search Central, Fix Search-related JavaScript problems, mise à jour du 18 décembre 2025.
- Google Search Central, Fix lazy-loaded content et Dynamic rendering as a workaround.
- Google Search Central, Generate structured data with JavaScript et Introduction to robots.txt.
- Google Search Central, journal des mises à jour de la documentation : entrées des 15, 17 et 18 décembre 2025 et du 4 mars 2026.
- Blog Google Search Central, Crawling December: The how and why of Googlebot crawling (3 décembre 2024) et The new evergreen Googlebot (7 mai 2019).
- Aide Search Console, outil d’inspection d’URL.
- Google Search Central, Optimizing your website for generative AI features on Google Search, mise à jour du 10 juillet 2026.
- Vercel et MERJ, The rise of the AI crawler (17 décembre 2024).
- Dave Smart, Tame the Bots, Google doesn’t cut off rendering after 5 seconds (juillet 2026).
- Tony McCreath, Tony’s Theory of Googlebot Relativity (relevés de janvier 2025).
- Bing Webmaster Blog, The new evergreen Bingbot (9 octobre 2019) ; web.dev, Interaction to Next Paint is officially a Core Web Vital (12 mars 2024).
- OpenAI, Overview of OpenAI Crawlers : rôles de GPTBot, OAI-SearchBot et ChatGPT-User.
- Journal serveur Apache de getknown.fr, 31 août au 28 septembre 2026 : requêtes classées par agent, adresses IP comparées aux plages publiées par Google, Microsoft, OpenAI, Anthropic et Perplexity le 28 septembre 2026.
Mise à jour du 30 septembre 2026 : article réécrit. Sources : la documentation de Google (décembre 2025 et mars 2026), l’étude de Vercel et MERJ, les tests de Dave Smart et de Tony McCreath, nos journaux serveur de septembre.
Retirés : le rendu dynamique présenté comme correctif rapide et une question de FAQ liée à une année.
Article rédigé par Yonel Sasson, Getknown, agence SEO et GEO.