JavaScript SEO : vérifier ce que Google et les IA lisent vraiment de vos pages

Le JavaScript SEO consiste à s’assurer que le contenu et les liens générés par JavaScript sont bien vus par les moteurs. Google exécute le JavaScript, mais en différé, dans une file de rendu. La plupart des robots des IA génératives (GPTBot, ClaudeBot, PerplexityBot) ne l’exécutent pas : ils ne lisent que le HTML source. La règle qui en découle est simple : tout contenu important doit figurer dans le HTML initial, ce que permettent le rendu côté serveur (SSR) ou la génération statique (SSG).

Ce guide explique la différence entre HTML source et page rendue, le fonctionnement du rendu chez Google, puis propose quatre tests pour vérifier ce que les moteurs voient vraiment, avant de passer en revue les cas qui posent problème le plus souvent.

01JavaScript SEO : HTML source et page rendue, la différence qui compte

Quand un navigateur ouvre une page, il reçoit d’abord un document HTML envoyé par le serveur. Il exécute ensuite les scripts, qui peuvent ajouter du texte, des liens, des images ou des données. Ce que vous voyez à l’écran n’est donc pas forcément ce que contient la réponse du serveur.

HTML source et DOM rendu : définitions

• Le HTML source (ou HTML initial) est la réponse brute du serveur, celle qu’affiche la commande « Afficher le code source » du navigateur.
• Le DOM rendu est l’état de la page après exécution du JavaScript, celui qu’affiche l’onglet Éléments des outils de développement.

Sur une application React construite sans rendu serveur, le HTML source peut se résumer à un conteneur vide du type div id= »root » et à quelques balises script. Tout le contenu n’existe que dans le DOM rendu. Un robot qui ne lit que le HTML source voit alors une page vide.

CSR, SSR, SSG et hydratation : les modes de rendu

• CSR (client-side rendering) : le navigateur construit la page à partir d’un HTML presque vide. Le contenu dépend entièrement du JavaScript.
• SSR (server-side rendering) : le serveur génère le HTML complet à chaque requête, puis le JavaScript prend le relais pour l’interactivité.
• SSG (static site generation) : les pages sont générées en HTML au moment de la compilation, puis servies telles quelles.
• Hydratation : étape où le JavaScript « rattache » l’interactivité à un HTML déjà rendu par le serveur. Le contenu est visible avant, les clics fonctionnent après.

Les frameworks modernes (Next.js pour React, Nuxt pour Vue, Angular avec son module SSR) savent combiner ces modes page par page. Le choix se fait donc gabarit par gabarit, pas pour tout le site.

02Comment Google explore, rend et indexe une page en JavaScript

Google traite les pages JavaScript en trois phases. Sa documentation sur les bases du SEO JavaScript les décrit ainsi : exploration, rendu, indexation.

Exploration, file de rendu, indexation : les trois phases

1. Exploration : Googlebot récupère l’URL et lit le HTML source. Il extrait les liens présents dans des balises a avec un attribut href.
2. Rendu : les pages qui répondent en code 200 sont placées dans une file de rendu. Quand les ressources de Google le permettent, une version headless de Chromium, maintenue à jour, exécute le JavaScript.
3. Indexation : Google analyse le HTML rendu, y découvre éventuellement de nouveaux liens et indexe le contenu.

Selon Google, une page peut attendre dans cette file quelques secondes, ou davantage. Google a assoupli son discours en 2026, en rappelant qu’il rend le JavaScript depuis plusieurs années, mais il continue de recommander le rendu côté serveur ou le prérendu.

Ce que le rendu différé implique pour vos contenus

• Les liens injectés en JavaScript ne sont découverts qu’après le rendu, ce qui peut ralentir l’exploration des pages profondes.
• Une balise noindex présente dans le HTML source peut conduire Google à ignorer le rendu : la retirer ensuite en JavaScript ne fonctionne pas forcément.
• Une balise canonical injectée en JavaScript doit avoir la même valeur que celle du HTML source, et rester unique.
• Le titre et la meta description peuvent être modifiés en JavaScript, mais une valeur correcte dans le HTML initial évite toute ambiguïté.
• Les erreurs doivent renvoyer un vrai code 404 : sur une application monopage, une page introuvable qui répond en 200 devient une soft 404.

Ces points recoupent les causes classiques de non-indexation détaillées dans l’article indexation Google : pourquoi vos pages ne sont pas indexées.

03Pourquoi la plupart des crawlers des IA génératives n’exécutent pas le JavaScript

Exécuter du JavaScript à grande échelle coûte cher en calcul. La plupart des robots des IA se contentent donc de récupérer le HTML. Une étude publiée par Vercel et MERJ en décembre 2024, fondée sur l’analyse du trafic de leur réseau, concluait qu’aucun des principaux robots d’IA n’exécutait alors le JavaScript.

L’étude de Vercel précise que les robots de ChatGPT et de Claude téléchargent parfois des fichiers JavaScript, sans les exécuter. Le contenu affiché côté client leur reste donc invisible. Ces comportements peuvent évoluer : vérifiez régulièrement vos journaux serveur plutôt que de considérer ce constat comme définitif.

Conséquence directe pour le GEO : une fiche produit, un comparatif ou une FAQ générés en CSR peuvent être indexés par Google et rester absents des réponses de ChatGPT ou de Perplexity. Le sujet est développé dans les articles LLM SEO : comment les moteurs IA lisent votre contenu et optimisation technique GEO.

04Vérifier ce que les moteurs voient vraiment : quatre tests

Ces quatre tests se complètent. Les trois premiers montrent ce que voit un robot qui n’exécute pas le JavaScript, le quatrième ce que Google obtient après rendu. Choisissez une phrase caractéristique de la page (un paragraphe, un prix, un nom de produit) et cherchez-la à chaque étape.

1. Lire le code source de la page

Dans Chrome, ajoutez view-source: devant l’URL ou utilisez le raccourci Ctrl+U (Cmd+Option+U sur Mac). Cherchez votre phrase avec Ctrl+F.

• Le texte apparaît : il est dans le HTML initial, lisible par tous les robots.
• Il n’apparaît pas : il est injecté par JavaScript.

Attention à ne pas confondre avec l’onglet Éléments des outils de développement, qui affiche le DOM rendu.

2. Récupérer le HTML brut avec curl

La commande curl récupère la réponse du serveur sans rien exécuter, comme un robot simple. Elle permet aussi de tester un user-agent précis, car certains serveurs ou pare-feu répondent différemment selon le robot :

curl -sL https://www.example.com/page/ | grep -c "votre phrase"
curl -sL -A "GPTBot" https://www.example.com/page/ | grep -c "votre phrase"
curl -sIL -A "ClaudeBot" https://www.example.com/page/

Un résultat à 0 signifie que la phrase est absente du HTML brut. La troisième commande affiche les en-têtes HTTP : un code 403 ou une page de défi anti-robot révèle un blocage au niveau du serveur ou du CDN, indépendant du JavaScript.

3. Naviguer avec le JavaScript désactivé

Dans les outils de développement de Chrome, ouvrez le menu de commandes (Ctrl+Shift+P), tapez « Disable JavaScript » et rechargez la page. Vous voyez alors approximativement ce que lit un robot d’IA.

• Le menu principal s’affiche-t-il, avec des liens cliquables ?
• Le texte principal, les prix et les avis sont-ils présents ?
• Les liens vers les pages produits ou les articles existent-ils ?

4. Inspecter l’URL dans la Search Console

L’outil d’inspection d’URL montre ce que Google obtient après rendu. Lancez « Tester l’URL en ligne », puis « Afficher la page testée » :

• l’onglet HTML contient le code rendu : cherchez-y votre phrase ;
• la capture d’écran montre ce que Google a affiché ;
• la section « Plus d’infos » liste les ressources non chargées et les messages de la console JavaScript.

Pour un audit à l’échelle du site, un crawler comme Screaming Frog en mode rendu JavaScript compare le HTML source et le HTML rendu sur toutes les URL. C’est une étape standard d’un audit SEO technique.

05Cas fréquents qui cachent du contenu ou des liens en JavaScript

Google le précise dans sa documentation sur le chargement différé : la recherche Google n’interagit pas avec la page. Elle ne clique pas, ne fait pas défiler et ne saisit rien. Tout contenu qui attend une action de l’utilisateur risque donc de rester invisible.

Accordéons et onglets chargés au clic

Deux implémentations se ressemblent à l’écran mais diffèrent pour les moteurs :

• Contenu présent dans le HTML et simplement masqué en CSS : il est lu par Google et par les robots qui lisent le HTML source.
• Contenu récupéré par une requête au moment du clic : il n’existe pas tant que personne ne clique, ni pour Google ni pour les robots des IA.

Sur une fiche produit, la description détaillée, la composition ou la FAQ doivent relever du premier cas.

Liens codés en button au lieu de balises a href

Google l’écrit clairement dans ses consignes sur les liens explorables : il ne peut explorer un lien que s’il s’agit d’un élément a avec un attribut href. Un bouton qui change de page via un gestionnaire onclick, un span cliquable ou un lien en href= »javascript:… » ne transmet rien.

<!-- Explorable -->
<a href="/chaussures/trail/">Chaussures de trail</a>

<!-- Non explorable -->
<button onclick="router.push('/chaussures/trail/')">Chaussures de trail</button>
<span onclick="goTo('trail')">Chaussures de trail</span>

Ce défaut touche souvent les menus, les filtres de catégories et les boutons « Voir le produit ». Il prive les pages profondes de liens internes.

Carrousels et contenus chargés au défilement

• Carrousel : seules les diapositives présentes dans le HTML sont lues. Celles chargées à la navigation restent invisibles.
• Défilement infini : Google recommande de donner à chaque segment une URL unique et persistante (par exemple ?page=2), reliée par des liens classiques.
• Bouton « Charger plus » : doublez-le d’une pagination en liens a href, sans quoi les produits suivants ne sont pas découverts.
• Avis clients chargés par un widget tiers : souvent absents du HTML, ils ne profitent ni au SEO ni à la visibilité dans les IA.

Applications React et Next.js : le mode de rendu fait la différence

React n’est pas incompatible avec le SEO. Tout dépend du mode de rendu. Une application React montée en CSR pur (avec Vite, par exemple) livre un HTML presque vide. Next.js, Remix ou Gatsby génèrent en revanche le HTML côté serveur ou à la compilation.

• Avec l’App Router de Next.js, les composants serveur sont rendus côté serveur par défaut, et les composants clients sont aussi prérendus dans le HTML initial.
• Le piège : charger les données principales dans un useEffect ou une requête côté client. La structure arrive en HTML, mais le contenu non.
• Vérifiez les métadonnées : title, meta description, canonical et données structurées doivent sortir du serveur.

06SSR ou CSR : quel rendu choisir pour le SEO de votre site JavaScript

Pour toute page qui doit se classer ou être citée, le contenu doit être dans le HTML initial. Le CSR reste acceptable pour les espaces connectés, les tableaux de bord ou les fonctions secondaires qui n’ont pas vocation à être indexés.

Comparatif CSR, SSR, SSG et rendu dynamique

Le rendu dynamique consiste à servir une version prérendue aux robots et la version JavaScript aux visiteurs. Google indique dans sa page sur le rendu dynamique qu’il s’agissait d’une solution de contournement, pas d’une solution à long terme, et recommande à la place le rendu côté serveur, le rendu statique ou l’hydratation.

07Checklist JavaScript SEO et erreurs à éviter

Utilisez cette liste à chaque refonte, nouveau gabarit ou changement de framework :

1. Le contenu principal, les prix et les avis figurent dans le HTML source.
2. Le title, la meta description, la canonical et les données structurées sont générés côté serveur.
3. Tous les liens de navigation sont des balises a avec un attribut href pointant vers de vraies URL, sans fragment #.
4. Les pages introuvables renvoient un code 404, pas une page vide en 200.
5. Aucune balise noindex n’est ajoutée ou retirée en JavaScript.
6. Les fichiers JavaScript et CSS nécessaires au rendu ne sont pas bloqués dans le fichier robots.txt.
7. La pagination et les listes de produits restent accessibles par des liens, sans clic ni défilement.
8. L’image principale n’est pas chargée en différé.
9. Le test curl et l’inspection d’URL donnent le même contenu essentiel.

Les erreurs les plus coûteuses restent les mêmes d’un projet à l’autre : une refonte en React sans rendu serveur, des menus en boutons, des descriptions produits chargées au clic, des avis injectés par un widget. Elles relèvent toutes du SEO technique et se corrigent bien plus facilement avant la mise en ligne qu’après.

08Questions fréquentes

Google exécute-t-il le JavaScript ?

Oui. Googlebot place les pages qui répondent en code 200 dans une file de rendu, puis une version récente de Chromium exécute le JavaScript avant l’indexation. Ce rendu est différé, de quelques secondes à davantage. Google recommande toutefois le rendu côté serveur ou le prérendu, plus rapides pour les utilisateurs et lisibles par les robots qui n’exécutent pas le JavaScript.

Les IA lisent-elles le contenu chargé en JavaScript ?

Pour la plupart, non. Selon l’étude publiée par Vercel en décembre 2024, les robots d’OpenAI, d’Anthropic, de Perplexity et de Meta n’exécutaient pas le JavaScript. Seuls Googlebot, utilisé pour Gemini, et Applebot effectuaient un rendu complet. Un contenu affiché côté client risque donc d’être absent des réponses de ChatGPT, Claude ou Perplexity.

React est-il compatible avec le SEO ?

Oui, à condition de choisir le bon mode de rendu. Une application React en rendu client pur livre un HTML presque vide, que Google doit rendre et que les robots des IA ne lisent pas. Avec un framework qui génère le HTML côté serveur ou à la compilation, comme Next.js, le contenu est présent dès la réponse du serveur.

Next.js est-il bon pour le référencement ?

Next.js est bien adapté au SEO, car il génère le HTML côté serveur ou à la compilation par défaut. Les problèmes viennent surtout de l’implémentation : données principales chargées côté client, métadonnées définies dans le navigateur, liens remplacés par des boutons. Vérifiez chaque gabarit avec curl et l’outil d’inspection d’URL de la Search Console.

Comment savoir si Google voit mon contenu ?

Utilisez l’outil d’inspection d’URL de la Search Console : lancez un test en ligne, ouvrez la page testée et cherchez votre texte dans l’onglet HTML, qui contient le code rendu. Consultez aussi la capture d’écran et les ressources non chargées. Pour savoir si les robots des IA le voient, cherchez ce même texte dans le HTML brut récupéré avec curl.