React, Vue ou Angular permettent de construire des single-page applications (SPA) : une seule page HTML, une navigation sans rechargement, une expérience fluide pour l'internaute. Côté référencement, en revanche, cette architecture a un revers : le contenu n'existe qu'après l'exécution du JavaScript, et dans certaines conditions, il n'atteint jamais l'index de Google. Cela ne se juge pas à l'œil nu : Google le consigne dans le rapport « Indexation des pages » de la Search Console, à travers quatre statuts qui reviennent sur ce type de sites.
Lesquels ? Que révèle chacun sur ce que Googlebot a réellement vu de la page ? Et comment savoir, à l'échelle d'un site entier, quelles vues Google a fini par indexer, et lesquelles il a laissées de côté ?
Aucune erreur ne s'affiche. Le verdict, lui, est déjà écrit.
Une SPA, pour Googlebot, c'est quoi
Pour Googlebot, une single-page application se présente d'abord comme une coquille HTML presque vide. Le contenu, les liens et les métadonnées n'existent qu'après l'exécution du JavaScript, qui les injecte dans la page côté navigateur. Googlebot doit donc rendre la page pour accéder à ce qu'un internaute voit à l'écran.
Ce rendu ne suit pas immédiatement l'exploration. Google explore d'abord le HTML brut, place la page dans une file d'attente de rendu, puis exécute le JavaScript avec une version de Chromium avant d'indexer le résultat. Google Search Central décrit cette file sans en garantir le délai : « la page peut rester dans cette file quelques secondes, mais cela peut prendre plus de temps. » Entre l'exploration et le rendu, votre contenu reste invisible pour l'index.
Ce décalage entre exploration et rendu est au cœur des enjeux de crawl et d'indexation propres au JavaScript. Le fonctionnement détaillé de ce moteur de rendu, la façon dont Google exécute le JavaScript et ce qui pèse sur le budget de rendu, fera l'objet d'un article à venir. Ici, l'important est la conséquence : tant que le rendu n'a pas abouti, une SPA n'expose presque rien à indexer.
Google lit le JavaScript, et recommande quand même le rendu côté serveur
Deux idées opposées circulent, toutes deux fausses. D'un côté, l'idée que Google « ne lit pas le JavaScript » : fausse, Googlebot rend les pages depuis des années avec une version à jour de Chromium. De l'autre, l'idée qu'il « rend tout sans le moindre effort » : fausse également, car le rendu est différé, coûteux, et l'environnement de rendu ne conserve rien d'une page à l'autre.
C'est pourquoi Google Search Central ne se contente pas d'annoncer que le JavaScript est pris en charge. La documentation recommande de le contourner : « le rendu côté serveur ou le pré-rendu reste une très bonne idée, car il rend votre site plus rapide pour les utilisateurs comme pour les robots, et tous les robots ne savent pas exécuter le JavaScript. » Autrement dit, l'entreprise qui rend le mieux le JavaScript conseille malgré tout de lui livrer le HTML directement.
Le rendu JavaScript est donc un vrai levier, ni une fatalité ni une catastrophe. Il fonctionne, mais il ajoute une étape de plus où les choses peuvent échouer sans bruit. Et quand elles échouent, elles laissent une trace précise.
Les 4 statuts de la Search Console qui trahissent une SPA mal indexée
Quand le rendu d'une SPA échoue, Google n'affiche aucun message d'erreur. Il range simplement la page dans un statut d'indexation. Quatre statuts, en particulier, sont la signature d'un problème de rendu. Chacun correspond à un moment précis où le processus a déraillé.
| Mode de défaillance de la SPA | Statut dans la Search Console | Ce que Google a fait |
|---|---|---|
| Le rendu n'a jamais eu lieu | Détectée, actuellement non indexée | URL connue, ni explorée ni rendue |
| Rendu effectué, mais vue jugée creuse | Explorée, actuellement non indexée | Explorée et rendue, valeur non retenue |
| Un 200 renvoyé sur une vue vide | Soft 404 | Page servie en 200 mais perçue vide |
| La coquille indexée avant la fin du rendu | Page indexée sans contenu | Indexée, mais sans le contenu attendu |
Détectée, actuellement non indexée
« Détectée, actuellement non indexée » est le statut des pages que Google connaît mais n'a pas encore explorées, et donc pas encore rendues. Sur une SPA, il grimpe vite quand le site expose des milliers de vues via le routing côté client : Google découvre les URLs, les met en file, mais ne trouve pas le temps de toutes les traiter. Le rendu n'est pas en cause ici, il n'a simplement jamais eu lieu. C'est souvent le signe d'un budget de crawl sous tension.
Explorée, actuellement non indexée
« Explorée, actuellement non indexée » raconte l'inverse : Google a bien exploré et rendu la page, mais n'a pas jugé utile de la garder. Sur une SPA, deux causes reviennent. Soit le rendu a produit une vue trop mince, contenu encore en chargement ou appel à l'API échoué au moment du rendu ; soit plusieurs vues se ressemblent trop, faute de titre et de description propres à chacune. Google a vu la page. Elle ne l'a pas convaincu.
Soft 404
Une Soft 404 survient quand une vue renvoie un code HTTP 200 alors qu'elle est en réalité vide ou en erreur. C'est le piège classique du routing côté client : sans serveur pour renvoyer un vrai 404, une URL inexistante affiche une coquille « page introuvable » en 200. Google Search Central le décrit noir sur blanc : les single-page applications renvoient souvent « un code HTTP 200 au lieu du code approprié ». Google le détecte, et classe la page en Soft 404.
Page indexée sans contenu
« Page indexée sans contenu » est le plus insidieux des quatre. Google a indexé l'URL au stade de la coquille, avant que le rendu n'aboutisse. La page existe dans l'index, vide ou presque. Pour une SPA, c'est le scénario où Googlebot a récupéré le HTML initial, l'a retenu, mais où le contenu injecté par le JavaScript n'a jamais rejoint la version indexée.
Les pièges structurels d'une SPA, documentés par Google
Au-delà du rendu lui-même, l'architecture d'une SPA cumule des pièges que Google documente précisément. Ils ont un point commun : ils privent Googlebot d'un repère que les sites classiques lui offrent gratuitement, une URL propre, un lien suivable, une balise stable.
Le premier tient aux URLs. Historiquement, les SPA changeaient de vue en modifiant la partie de l'adresse située après le #. Google ne suit plus cette mécanique : « le schéma d'exploration AJAX est obsolète depuis 2015 ; vous ne pouvez donc pas compter sur les fragments d'URL pour fonctionner avec Googlebot. Nous recommandons d'utiliser l'History API. » Chaque vue à indexer a besoin de sa propre URL réelle.
Viennent ensuite les liens. Un lien déclenché par un onClick sur une <div> n'est pas un lien pour Googlebot. Sans balise <a href>, il ne découvre pas la vue de destination et ne lui transmet aucun signal. Même logique pour le contenu qui n'apparaît qu'après une interaction, clic sur un onglet ou ouverture d'un accordéon : Googlebot ne clique pas. Ce qui compte doit figurer dans le rendu initial, pas derrière une action de l'internaute.
Restent les balises. Injecter la canonique en JavaScript est risqué : « vous ne devriez pas utiliser JavaScript pour modifier l'URL canonique », prévient Google Search Central. Même prudence pour la balise meta robots : « utiliser JavaScript pour modifier ou retirer la balise meta robots peut ne pas fonctionner comme prévu. » Une page laissée en noindex dans le HTML initial peut le rester aux yeux de Google, quoi que fasse le script ensuite. Enfin, l'environnement de rendu ne garde aucune mémoire d'une page à l'autre : « les données de Local Storage et de Session Storage sont effacées entre deux chargements de page. Les cookies HTTP sont effacés entre deux chargements de page. » Une vue dont le contenu dépend d'un état stocké côté client peut donc apparaître vide au rendu.
💡 Avant de corriger, encore faut-il savoir lesquelles de vos vues Google a réellement indexées, et sous quel statut. Découvrir IndexProbe en accès anticipé →
Avez-vous vraiment besoin de SSR ?
Toutes les vues d'une SPA n'ont pas besoin d'être indexées. Avant de tout basculer en rendu côté serveur, la bonne question n'est pas technique mais éditoriale : cette vue a-t-elle vocation à attirer du trafic depuis la recherche ? La réponse décide de l'effort, pas l'inverse.
Séparez vos vues en deux familles. D'un côté, celles qui doivent se positionner : page d'accueil, fiches produit, articles, pages de catégorie. Elles ont besoin que Google voie leur contenu sans dépendre du rendu, donc d'un SSR (Server-Side Rendering, rendu côté serveur), d'un SSG (Static Site Generation, génération de site statique) ou d'un pré-rendu. De l'autre, les vues purement applicatives : tableau de bord, panier, écrans derrière authentification. Elles n'ont rien à faire dans l'index ; un noindex assumé vaut mieux qu'un SSR inutile.
Entre SSR, SSG et pré-rendu, le choix dépend de la fraîcheur du contenu et de vos contraintes techniques, pas d'un prestataire à privilégier. Une page qui change en permanence penche vers le SSR ; un catalogue stable se prête à la génération statique ; un pré-rendu peut dépanner un site existant sans le réécrire. L'essentiel reste le même : les vues qui comptent doivent arriver à Googlebot déjà remplies.
Vérifier à l'échelle quelles vues Google indexe vraiment
Corriger le rendu ne suffit pas : il faut vérifier, vue par vue, ce que Google en a fait. L'outil d'Inspection d'URL de la Search Console donne ce verdict officiel, mais une seule URL à la fois. Sur une SPA qui expose des milliers de vues, l'auditer page par page devient impraticable.
IndexProbe est la version en masse de cet outil d'Inspection d'URL. Vous lui confiez la liste des vues à surveiller, par sitemap, CSV, copier-coller, ou en la constituant directement depuis votre Search Console (par clics, impressions ou pattern d'URL), et il interroge pour chacune l'API officielle de la Search Console. Pour chaque vue, vous récupérez le statut d'indexation détaillé, le motif de non-indexation, la canonique retenue par Google et la date du dernier passage de Googlebot. D'un filtre, vous isolez les vues restées en « Explorée, actuellement non indexée » ou en « Page indexée sans contenu », celles-là mêmes que trahit un rendu qui a échoué. La segmentation des URLs, générée automatiquement ou définie à la main, regroupe au passage vos vues par famille (fiches produit, catégories, écrans applicatifs…) : si un type de vues concentre les échecs de rendu, il ressort immédiatement.
IndexProbe n'est pas un crawler : il ne découvre aucune vue en suivant des liens, il inspecte uniquement la liste que vous fournissez ou que vous constituez depuis la GSC (Google Search Console). Là où l'inspecteur de la Search Console impose une URL à la fois, vous obtenez le même verdict officiel, daté, sur toute votre liste, dans un tableau filtrable que vous relancez quand vous le souhaitez.
Vérifier que la correction a payé
Une correction de rendu ne se constate pas le jour du déploiement, mais le jour où Google repasse et réévalue la page. La mesure se fait dans le temps, en comparant deux analyses de la même liste de vues, avant et après. Le bon signal n'est pas un chiffre isolé, c'est un mouvement de statuts.
Après un passage en SSR ou en pré-rendu, les vues sorties de « Explorée, actuellement non indexée » et de « Page indexée sans contenu » basculent peu à peu vers « Envoyée et indexée ». La vue Comparaison met ce déplacement en évidence, statut par statut, entre deux relances de la même liste.
Ce suivi sert aussi de garde-fou. Une SPA bien indexée aujourd'hui peut se dégrader après une refonte, l'ajout d'un module ou une régression de build qui casse le rendu. Reprendre la même liste à intervalles réguliers transforme une dérive silencieuse en signal repérable, avant que les vues ne quittent l'index.
💡 Le rendu d'une SPA ne se devine pas : il se lit dans les statuts d'indexation de la Search Console, statut par statut, vue par vue. IndexProbe vous donne, pour toute la liste que vous fournissez ou constituez depuis la GSC, le verdict officiel et daté de Google par URL, et reste répétable pour suivre chaque évolution d'une analyse à l'autre. Tester IndexProbe en accès anticipé →
Questions fréquentes
React est-il mauvais pour le référencement ?
Non. React n'empêche pas l'indexation ; c'est le rendu côté client qui pose problème, quand le contenu n'existe qu'après exécution du JavaScript. Un site React rendu côté serveur, avec Next.js par exemple, ou pré-rendu se positionne aussi bien qu'un site classique. Le framework n'est pas en cause, la stratégie de rendu l'est.
Google indexe-t-il les single-page applications (SPA) ?
Oui. Google explore et rend les single-page applications avec une version à jour de Chromium, puis indexe le résultat. Mais ce rendu est différé et peut échouer sans message d'erreur. Une SPA s'indexe donc, à condition que ses vues exposent une URL propre et un contenu accessible sans interaction de l'internaute.
Google lit-il le JavaScript ?
Oui. Googlebot exécute le JavaScript pour rendre les pages avant de les indexer. Google Search Central recommande néanmoins le rendu côté serveur ou le pré-rendu, car le rendu JavaScript ajoute une étape coûteuse et faillible, et tous les robots ne l'exécutent pas.
Faut-il du SSR pour le référencement d'une SPA ?
Pas systématiquement. Seules les vues qui doivent attirer du trafic organique, accueil, fiches produit, articles, catégories, ont besoin d'un rendu côté serveur, statique ou pré-rendu. Les vues applicatives privées, tableau de bord ou panier, n'ont pas à être indexées et peuvent rester en rendu côté client.
Pourquoi ma page React n'est-elle pas indexée ?
Regardez son statut dans la Search Console. « Détectée, actuellement non indexée » signale que la page n'a pas encore été explorée ; « Explorée, actuellement non indexée » que Google l'a rendue mais jugée trop faible ; « Soft 404 » qu'elle renvoie un 200 sur une vue vide ; « Page indexée sans contenu » que Google a indexé la coquille avant la fin du rendu. Chaque statut oriente vers une cause différente.
Qu'est-ce qu'une single-page application (SPA) ?
Une single-page application (SPA) est un site qui charge une seule page HTML puis met à jour son contenu via JavaScript à mesure que l'internaute navigue, sans recharger la page. React, Vue et Angular servent couramment à en construire. L'approche est fluide pour l'utilisateur, mais elle demande une attention particulière au rendu pour rester indexable.