// guide technique
JavaScript SEO : faire indexer un site JS.
React, Vue, SPA : les sites JavaScript posent des défis d'indexation que les sites statiques ignorent. Comprendre le rendu en deux vagues de Googlebot, les pièges du rendu client, les solutions SSR et hydration, et pourquoi les crawlers IA rendent le sujet encore plus critique.
Le rendu en deux vagues de Googlebot.
Pour un site statique, Google lit le HTML et c'est réglé. Pour un site JavaScript, le processus est différent et se déroule en deux temps distincts, ce qui change tout pour l'indexation.
// à retenir
Vague 1 : Googlebot crawle le HTML brut immédiatement, sans exécuter le JavaScript. Vague 2 : la page est mise en file d'attente pour un rendu complet via le Web Rendering Service, différé de quelques heures à plusieurs jours. Tout contenu présent uniquement dans le JS n'est vu qu'à la vague 2.
La conséquence est directe : si le contenu essentiel (texte, liens, balises) n'existe que dans le JavaScript, son indexation est retardée et fragilisée. Sur un site neuf ou à fort volume, la vague 2 peut prendre beaucoup de temps, voire être incomplète si le rendu échoue.
Les pièges du rendu client pur.
Le rendu client (CSR) est le mode par défaut d'une application React ou Vue non configurée : le serveur renvoie un HTML quasi vide, et le navigateur construit la page. C'est la source numéro un des problèmes d'indexation JavaScript.
- HTML initial vide : à la vague 1, Googlebot ne voit ni contenu, ni liens, ni balises. Tout dépend de la vague 2.
- Liens non découverts : si la navigation est gérée en JS sans vraies balises
<a href>, Googlebot ne suit pas les liens et ne découvre pas les pages profondes. - Balises SEO injectées tardivement : un
title, une meta description ou un canonical posés en JS peuvent être manqués si le rendu échoue. - noindex injecté en JS : risqué dans les deux sens, la directive peut être lue trop tard ou manquée. Voir balise noindex.
SSR, SSG, hydration : les solutions.
La règle d'or : servir le contenu essentiel dans le HTML initial, pour qu'il soit lu dès la première vague. Trois approches, toutes supportées par les frameworks modernes.
SSR
Rendu serveur
Le serveur génère un HTML complet à chaque requête. Idéal pour le contenu dynamique. Next.js, Nuxt, Astro le proposent nativement.
SSG
Génération statique
Le HTML est pré-généré au build. Le plus rapide et le plus robuste pour l'indexation, parfait pour le contenu stable.
Hydration
Hybride
Le serveur livre un HTML pré-rendu lu immédiatement par les crawlers, puis le JS active l'interactivité côté navigateur. Le meilleur des deux mondes.
// le bon réflexe
Tester son site JavaScript désactivé : le contenu et les liens essentiels doivent rester visibles. Si la page est vide sans JS, elle dépend de la vague 2 et il faut passer en SSR ou SSG.
Pourquoi les crawlers IA aggravent tout.
Le rendu JavaScript était déjà un risque pour Google. Avec la montée des moteurs IA, il devient un facteur d'invisibilité encore plus marqué.
// le point clé
OAI-SearchBot et la plupart des crawlers IA ne rendent pas le JavaScript comme Googlebot. Un site en rendu client pur peut donc être totalement invisible dans ChatGPT et Perplexity, même s'il finit par être indexé par Google via la vague 2.
Autrement dit, servir un HTML riche côté serveur n'est plus seulement une optimisation Google : c'est la condition d'existence sur les moteurs IA. Le sujet rejoint celui des crawlers IA et de la citation par ChatGPT et Perplexity.
Diagnostiquer le rendu.
- 01
Tester sans JavaScript
Désactiver JavaScript dans le navigateur et recharger la page. Ce qui reste visible correspond grosso modo à la première vague de Googlebot. Une page vide est un signal d'alerte.
- 02
Inspecter l'URL dans Search Console
"Tester l'URL en direct" puis "Voir la page testée" affiche le HTML réellement rendu par Googlebot et les ressources bloquées. Comparer au contenu attendu pour confirmer que le JS est exécuté.
- 03
Vérifier le code source vs le DOM rendu
Comparer le HTML source (Ctrl+U) au DOM final (inspecteur). Si le contenu n'apparaît que dans le DOM rendu, il dépend du JavaScript et donc de la seconde vague. Compléter avec un diagnostic d'indexabilité.
Questions fréquentes.
Google indexe-t-il les sites en JavaScript ?
Oui, mais avec des limites. Googlebot procède en deux vagues : il crawle d'abord le HTML brut (rapide), puis met la page en file d'attente pour un rendu JavaScript via son Web Rendering Service (différé de quelques heures à plusieurs jours). Si le contenu n'existe que dans le JS, il n'est vu qu'à la seconde vague, plus tardive et moins fiable.
Pourquoi mon site React ou Vue n'est-il pas bien indexé ?
Le plus souvent parce qu'il est en rendu client pur (CSR) : le HTML initial est quasi vide, tout le contenu est injecté par JavaScript dans le navigateur. Googlebot doit alors attendre la seconde vague pour voir le contenu, et les crawlers IA, qui rendent mal le JS, ne le voient parfois pas du tout. La solution est de servir le contenu dans le HTML initial via SSR ou SSG.
Quelle différence entre CSR, SSR, SSG et hydration ?
CSR (rendu client) : le serveur envoie un HTML vide, le JS construit la page dans le navigateur, mauvais pour l'indexation. SSR (rendu serveur) : le serveur renvoie un HTML complet à chaque requête. SSG (génération statique) : le HTML est pré-généré au build. Hydration : le serveur livre un HTML pré-rendu que les crawlers lisent immédiatement, puis le JS l'active côté navigateur. SSR, SSG et hydration servent tous un HTML crawlable d'emblée.
Les crawlers IA gèrent-ils le JavaScript ?
Moins bien que Google. OAI-SearchBot et la plupart des crawlers IA ne rendent pas le JavaScript comme Googlebot. Un site en rendu client pur risque donc d'être invisible des moteurs IA, même s'il finit par être indexé par Google. Servir un HTML riche côté serveur est encore plus critique pour la visibilité IA que pour Google.
Comment savoir si Googlebot rend bien mon JavaScript ?
Dans Search Console, inspection d'URL puis "Tester l'URL en direct" et "Voir la page testée" : on voit le HTML rendu par Googlebot et les ressources bloquées. Comparer ce HTML au contenu attendu révèle si le JS a été exécuté. Tester aussi en désactivant JavaScript dans le navigateur : ce que vous voyez est proche de la première vague de Googlebot.
Le lazy-loading nuit-il à l'indexation ?
Il peut, s'il dépend d'une interaction utilisateur (scroll, clic) que Googlebot ne reproduit pas. Le contenu chargé uniquement après une action peut ne jamais être vu. Utiliser le lazy-loading natif (attribut loading="lazy") pour les images, et s'assurer que le contenu textuel important est présent dans le HTML rendu sans interaction.
Un site JavaScript peut-il bien se positionner en SEO ?
Oui, à condition de servir le contenu en SSR ou SSG. Les frameworks modernes (Next.js, Nuxt, Astro) le permettent nativement. L'enjeu 2026 n'est plus le rendu de base mais la performance : un Largest Contentful Paint sous 2,5 s et un contenu disponible dès le premier rendu pour Googlebot. Voir aussi le mobile-first indexing.
// passer à l'action
Vérifier ce que Google voit vraiment.
Diagnostiquer le rendu d'une URL et confirmer que le contenu essentiel est bien accessible sans dépendre du JavaScript.