Le SEO JavaScript reste associé à une idée reçue tenace : Google traiterait les pages en « deux vagues d'indexation », avec des jours ou des semaines d'attente entre la lecture du HTML et l'exécution du JavaScript. Ce modèle, présenté par Google en 2018, ne figure plus dans sa documentation. Le rendu fonctionne aujourd'hui comme une file d'attente asynchrone, et la documentation indique qu'une page y reste le plus souvent quelques secondes, parfois davantage. La question utile n'est donc plus de savoir quand Google exécutera votre JavaScript, mais ce qu'il a réellement retenu une fois le rendu effectué. Cette information existe : l'outil d'inspection d'URL et le rapport « Indexation des pages » de la Google Search Console donnent, pour chaque URL, le verdict prononcé après l'exécution du JavaScript. Deux questions organisent ce diagnostic : quels statuts signalent un rendu défaillant, et comment vérifier ce que Google a indexé sans se fier au rendu de son propre crawler.
Comment Google traite le JavaScript aujourd'hui
Google traite les pages JavaScript en trois phases : l'exploration, le rendu et l'indexation (« Google processes JavaScript web apps in three main phases: Crawling, Rendering, Indexing »). Googlebot lit d'abord le HTML renvoyé par le serveur, puis place la page dans une file d'attente de rendu ; un Chromium sans interface exécute ensuite le JavaScript (« Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript »), et l'indexation porte sur le résultat de ce rendu.
Deux précisions de la documentation actuelle corrigent des croyances répandues. D'abord, l'attente en file de rendu se compte le plus souvent en secondes : « The page may stay on this queue for a few seconds, but it can take longer than that ». Les délais de plusieurs jours entre « première vague » et « deuxième vague » appartiennent à un modèle que Google n'utilise plus dans sa documentation ; la limite des « 5 secondes d'exécution », souvent citée, n'y figure pas non plus. Ensuite, le rendu n'est pas garanti pour autant : il dépend des ressources de Google, et certaines instructions le court-circuitent. La documentation précise par exemple qu'en présence d'une balise noindex, Google peut sauter entièrement le rendu (« When Google encounters the noindex tag, it may skip rendering and JavaScript execution ») : un script qui retire un noindex posé dans le HTML initial ne sera probablement jamais exécuté.
Le moteur de rendu de Google a aussi ses propres règles, différentes d'un navigateur. Il refuse les demandes de permission (« Expect Googlebot to decline user permission requests »), n'ouvre pas de connexions WebSocket ou WebRTC, et ne conserve aucun état entre les chargements : « Local Storage and Session Storage data are cleared across page loads. HTTP Cookies are cleared across page loads ». Un contenu qui dépend d'un cookie, d'une session ou d'une interaction utilisateur a donc toutes les chances de ne jamais apparaître dans la version rendue.
Le rendu de votre crawler n'est pas le verdict de Google
Pour vérifier une page JavaScript, le réflexe courant consiste à lancer un crawler en mode rendu (Screaming Frog, Sitebulb ou l'audit d'une suite SEO) et à comparer le HTML initial au DOM rendu. Cette comparaison est utile, mais elle a une limite structurelle : elle montre ce que votre outil a rendu, avec son moteur, ses délais et ses réglages. Elle ne dit pas ce que Google a rendu, ni surtout ce qu'il a décidé d'indexer.
Les deux résultats peuvent diverger pour des raisons ordinaires : un script bloqué pour Googlebot mais accessible à votre crawler, un appel réseau qui expire côté Google, une ressource mise en cache dans une vieille version, un contenu conditionné à un état que le moteur de rendu de Google efface (cookie, localStorage), ou simplement une exécution partielle. Une page peut donc paraître complète dans votre audit et être indexée incomplète par Google, sans qu'aucune erreur ne s'affiche nulle part.
La source qui tranche existe : c'est le verdict officiel. L'inspection d'URL de la Search Console montre le HTML rendu par Google lui-même, les ressources chargées, les exceptions JavaScript rencontrées. Et le rapport « Indexation des pages » enregistre la décision finale, URL par URL. Autrement dit, pour savoir si votre JavaScript pose un problème de SEO, perfectionner son propre rendu ne suffit pas : il faut lire ce que Google a conclu du sien.
La grille : symptôme de rendu, statut, cause, correctif
Chaque défaillance de rendu laisse une empreinte reconnaissable dans le rapport d'indexation. Le tableau résume les correspondances les plus fréquentes sur les sites à fort JavaScript ; d'autres statuts restent possibles selon la configuration.
| Symptôme | Statut le plus fréquent | Cause probable |
|---|---|---|
| Le HTML initial est une coquille, le contenu vient du JS | « Explorée, actuellement non indexée », ou page indexée vide | Rendu incomplet ou jugé sans valeur |
| Routage client, URLs qui affichent un état vide | « Soft 404 » | Pas de vrai code d'erreur, page « introuvable » rendue en 200 |
| Gros site, JS lourd, pages récentes en attente | « Détectée, actuellement non indexée » | File de rendu et budget de crawl |
| Balises injectées ou modifiées en JS (canonical, title, robots) | Statuts de doublons canoniques | Directives divergentes entre HTML initial et rendu |
| Contenu injecté, lazy loading, hydration défaillante | Selon le cas : exploration sans le contenu, doublons | Le contenu n'existe pas dans la version rendue |
La coquille CSR : rendue, lue, écartée
Sur une page en client-side rendering, le HTML initial ne contient presque rien ; tout arrive avec le JavaScript. Quand le rendu réussit et que le contenu convainc, la page s'indexe normalement. Quand le rendu échoue ou que le résultat paraît pauvre, deux verdicts reviennent le plus souvent : « Explorée, actuellement non indexée », quand Google a lu la page rendue et ne l'a pas retenue, et le cas plus trompeur de la page indexée sans contenu, quand Google indexe la coquille rendue vide : la page figure dans l'index, mais sur aucune requête utile. Ce second cas est le plus emblématique du JavaScript, car rien ne semble anormal tant qu'on ne compare pas ce qui est indexé à ce qui devait l'être.
Le routage client et les états vides : « Soft 404 »
Dans une application à routage JavaScript, une URL inexistante ne renvoie pas de code 404 : le serveur répond 200 et le JavaScript affiche « aucun résultat ». Google reconnaît ce motif et classe ces pages en « Soft 404 ». Sa documentation consacre une section entière à l'éviter en rendu client, en renvoyant un vrai code d'erreur côté serveur ou en signalant l'état d'erreur dans la page rendue. Des fiches produit épuisées, des recherches sans résultat ou des routes de secours mal configurées peuvent alimenter ce statut en série.
Le JavaScript lourd sur les gros sites : l'attente qui s'allonge
Le rendu consomme des ressources, côté Google comme côté serveur. Sur un site volumineux dont chaque page exige une exécution complète de JavaScript, l'exploration et le rendu ralentissent, et les pages récentes s'accumulent en « Détectée, actuellement non indexée » : Google connaît l'URL et n'a pas encore pris le temps de la traiter. Ce mécanisme rejoint la question du budget de crawl : moins chaque page coûte cher à traiter, plus Google en traite. Servir le contenu essentiel dans le HTML initial reste la recommandation de la documentation, qui rappelle que le rendu côté serveur ou le pré-rendu « makes your website faster for users and crawlers ».
Les balises injectées en JavaScript : les directives qui divergent
Un title, une canonique ou une balise robots qui n'existent que dans la version rendue créent une situation ambiguë : le HTML initial dit une chose, le DOM rendu en dit une autre. Selon le moment et la directive, Google peut retenir l'une ou l'autre version, et en cas de directives contradictoires, il applique la plus restrictive. Les verdicts qui en découlent sont les statuts de doublons : « Page en double sans URL canonique » quand la canonique injectée n'a pas été prise en compte, ou « Page en double : Google n'a pas choisi la même URL canonique » quand il a tranché contre votre déclaration. La règle la plus sûre consiste à placer les directives d'indexation (canonical, robots, title) dans le HTML initial plutôt que dans le JavaScript.
Les pièges hors SPA : contenu injecté, lazy loading, hydration
Le sujet ne concerne pas que les applications monopage. Un site classique peut injecter en JavaScript des blocs entiers : avis clients, caractéristiques produit, FAQ, contenus recommandés. Si le script échoue chez Google, la page s'indexe sans ces blocs, et rien ne le signale. Le lazy loading mal configuré produit le même effet : un contenu chargé uniquement au défilement n'existe pas pour un moteur de rendu qui ne défile pas comme un utilisateur, et la documentation renvoie à ses consignes dédiées pour le charger de façon détectable. Les listes en défilement infini relèvent du même traitement, détaillé dans notre article sur la pagination. Enfin, sur les frameworks hybrides, une hydration défaillante peut remplacer un HTML serveur correct par un état client dégradé. Dans tous ces cas, le mécanisme est identique : la version rendue ne contient pas ce que vous croyez avoir publié, et seul le verdict de Google en témoigne.
Le cas des SPA
Une application monopage (React, Vue, Angular) cumule ces pièges sous leur forme la plus aiguë : tout le contenu dépend du rendu, le routage est entièrement client, et l'échec ne produit aucune erreur visible. Ce cas a son article dédié, avec les quatre statuts qui trahissent une SPA mal indexée et le triage à mener avant de tout basculer en SSR : SEO des SPA React.
Diagnostiquer à l'échelle : les verdicts de Google sur vos URLs à fort JavaScript
L'inspection d'URL montre le rendu de Google pour une page. C'est l'outil de la preuve, pas celui du diagnostic d'ensemble : sur un site dont des milliers de pages dépendent du JavaScript, la question n'est pas « cette URL est-elle bien rendue ? » mais « quelle part de mes pages à fort JavaScript est réellement indexée, et avec quels motifs d'exclusion ? ».
La méthode consiste à inspecter en masse une liste d'URLs que vous maîtrisez : votre sitemap, un export, ou une sélection construite depuis la Search Console par pattern d'URL. C'est exactement ce que fait IndexProbe : il ne rend pas votre JavaScript localement, il interroge l'API officielle d'inspection et lit le verdict que Google a prononcé après son propre rendu, URL par URL. Face au JavaScript, cette différence avec un crawler est décisive : le résultat n'est pas une simulation supplémentaire, c'est la décision de Google elle-même.
Avec une segmentation par type de rendu (générée par IA ou définie à la main : pages servies en HTML complet, gabarits en client-side rendering, blocs injectés, vues à routage client), la lecture devient directe : les segments à fort JavaScript concentrent-ils les statuts d'échec de rendu, ou se comportent-ils comme les pages servies en HTML ? Un écart net entre les deux familles désigne le rendu comme cause, avant même d'ouvrir une seule page.
💡 Votre crawler peut rendre 10 000 pages parfaitement ; cela ne dit pas combien Google en a indexées après son propre rendu. Découvrir IndexProbe en accès anticipé →
Vérifier après correction : le rendu est asynchrone
Corriger un problème de rendu (passer un gabarit en SSR, servir le contenu essentiel dans le HTML initial, réparer un lazy loading) ne change pas le rapport d'indexation immédiatement. Google doit repasser sur chaque URL, la re-rendre et re-décider, et ce cycle dépend de sa file de rendu et de la fréquence de crawl de chaque page. La vérification demande donc un suivi daté : relancer la même analyse sur la même liste d'URLs quelques semaines après le déploiement, et comparer.
Après un passage au SSR, les pages du segment corrigé doivent refluer d'« Explorée, actuellement non indexée » vers l'indexation ; les « Soft 404 » de routage doivent s'éteindre à mesure que les vrais codes d'erreur sont vus ; les doublons liés aux balises injectées doivent se résorber. La vue Comparaison d'IndexProbe met les deux analyses face à face, statut par statut, et le relancement planifié transforme cette vérification en surveillance : une régression de rendu introduite par une mise à jour de framework se repère au changement de verdict, avant la baisse de trafic.
La démarche complète : comprendre ce que Google fait de votre JavaScript, lire les verdicts qu'il a prononcés après son rendu, corriger ce qu'ils désignent, puis confirmer la bascule dans le temps. Essayez IndexProbe en accès anticipé pour lire ces verdicts sur l'ensemble de vos URLs à fort JavaScript, en une seule analyse.
Questions fréquentes
Google indexe-t-il le contenu JavaScript ?
Oui. Google exécute le JavaScript avec un Chromium sans interface et indexe le résultat du rendu. Le point de vigilance n'est pas la capacité de Google à rendre, mais l'issue du rendu pour chaque page : un script bloqué, un appel qui expire ou un contenu dépendant d'une interaction peuvent produire une version rendue incomplète, et c'est cette version qui est indexée.
Le client-side rendering est-il mauvais pour le SEO ?
Pas en soi : une page en CSR correctement rendue s'indexe. Le CSR ajoute en revanche une étape faillible entre la publication et l'indexation, et ses échecs sont silencieux. La documentation Google recommande le rendu côté serveur ou le pré-rendu, plus rapides pour les utilisateurs comme pour les robots ; le choix se fait gabarit par gabarit, en fonction de ce que les verdicts d'indexation montrent.
Comment savoir ce que Google a réellement rendu sur ma page ?
Avec l'outil d'inspection d'URL de la Search Console : il affiche le HTML rendu par Google, les ressources chargées et les exceptions JavaScript rencontrées. C'est la seule source qui montre le rendu de Google plutôt qu'une simulation. Pour l'ensemble d'un site, la lecture se fait par les statuts du rapport « Indexation des pages », en masse.
Les « deux vagues d'indexation » existent-elles encore ?
Ce modèle ne figure plus dans la documentation de Google. Le rendu fonctionne comme une file d'attente asynchrone, où une page reste le plus souvent quelques secondes, parfois davantage. Les longues attentes systématiques entre lecture du HTML et exécution du JavaScript décrivent l'état de 2018, pas le fonctionnement actuel.
Le SSR est-il obligatoire pour être bien référencé ?
Non. Des pages en rendu client s'indexent correctement tous les jours. Le SSR ou le pré-rendu deviennent pertinents quand les verdicts montrent un problème : segments CSR qui concentrent l'« Explorée, non indexée », pages indexées vides, file d'attente qui s'allonge sur un gros site. La décision se prend sur ces constats, pas par principe.
Combien de temps Google met-il à rendre une page JavaScript ?
La documentation évoque une attente en file de rendu de quelques secondes, parfois davantage, sans garantie de délai. En pratique, le délai total dépend surtout de la fréquence de crawl de la page et des ressources que le site consomme : sur un gros site au JavaScript coûteux, l'attente se lit dans l'accumulation de pages « Détectée, actuellement non indexée ».