Pages JavaScript non indexées : corriger le rendu SPA et framework pour Google
Ton application JavaScript a l'air parfaite dans le navigateur mais Google voit une page vide. Comprends exactement comment le processus d'indexation à deux vagues de Google gère le contenu JavaScript et ce que tu dois changer.
Dans ce guide
React, Vue, Angular, Next.js et d'autres frameworks JavaScript propulsent des millions de sites web, mais il existe une tension fondamentale entre le rendu côté client et la manière dont Google indexe les pages.
Google traite les pages en deux vagues. La première vague analyse le HTML brut immédiatement. La seconde vague, qui peut se produire des heures ou des jours plus tard, rend le JavaScript. Si ton HTML est un div vide avec une balise script, la première vague de Google ne voit aucun contenu. La file de rendu peut prendre des jours, et les échecs dus à des timeouts d'API ou à des erreurs JS peuvent entraîner une classification permanente de thin content.
Ce guide couvre les diagnostics pour les échecs d'indexation liés au rendu et les solutions pratiques pour chaque framework majeur.
Comment fonctionne réellement l'indexation à deux vagues de Google
Comprendre le pipeline de rendu de Google est essentiel pour diagnostiquer et corriger les problèmes d'indexation JavaScript. Le processus fonctionne en étapes distinctes, et des problèmes à n'importe quelle étape peuvent empêcher ton contenu d'être indexé.
Dans la première étape, Googlebot envoie une requête HTTP pour ton URL et reçoit la réponse HTML. C'est identique à ce que tu verrais en affichant la source de la page (Ctrl+U) dans ton navigateur. Googlebot analyse ce HTML pour extraire le contenu texte, les liens, les balises meta, les balises canonical et les données structurées. Tout contenu présent dans cette réponse HTML initiale est immédiatement disponible pour l'indexation. Cette étape est rapide et se produit lors du processus de crawl normal.
Dans la seconde étape, l'URL est placée dans une file de rendu. Google exploite un Web Rendering Service (WRS) qui utilise un navigateur Chromium headless pour exécuter le JavaScript et produire le DOM rendu final. Le WRS charge ta page, exécute tous les scripts, attend que le contenu dynamique se charge, puis capture l'état final de la page. Ce DOM rendu est comparé au HTML initial. Tout nouveau contenu découvert dans le DOM rendu est ajouté à l'index de Google.
L'idée critique est que la file de rendu n'est pas en temps réel. Google a reconnu que la file de rendu peut avoir des délais significatifs parce que l'exécution de JavaScript est gourmande en ressources. Bien que Google ait considérablement amélioré la vitesse de rendu au fil des années, la file peut encore introduire des délais de plusieurs heures à plusieurs jours, surtout pour les pages provenant de domaines à faible autorité ou de sites que Google ne priorise pas pour un crawl fréquent.
Pendant la période d'attente entre la première vague et la seconde vague, ta page peut être évaluée uniquement sur son contenu HTML initial. Si ce HTML initial contient juste un div racine, une animation de chargement et une référence de bundle JavaScript, Google évalue la page comme n'ayant aucun contenu significatif. Cette évaluation peut entraîner la dépriorisation de la page pour le rendu ou sa classification comme thin content avant même que la seconde vague n'ait la chance de la traiter.
La file de rendu est également sujette aux échecs. Si ton JavaScript lance une erreur pendant le rendu, si un appel d'API expire, si la page nécessite une authentification, ou si un script tiers bloque l'exécution, le WRS peut produire un rendu incomplet ou vide. Google ne réessaie pas immédiatement les rendus échoués, ce qui signifie qu'une erreur transitoire pendant le rendu peut empêcher l'indexation pendant une période prolongée.
Le WRS de Google exécute une version moderne de Chromium qui prend en charge ES6+, async/await, fetch, les Web Components et la plupart des API JavaScript modernes. Cependant, il ne prend pas en charge toutes les API navigateur. Notamment, il n'a pas un accès significatif à localStorage, sessionStorage ou IndexedDB. Il ne prend pas en charge les événements d'interaction utilisateur (défilement, clic, survol), ce qui signifie que le contenu chargé par les événements de défilement, les éléments cliquables-pour-développer ou les popups déclenchés au survol est invisible pour Google. Le WRS a également un timeout pour l'exécution JavaScript. Si ta page prend plus d'environ cinq secondes pour rendre son contenu critique, le WRS peut capturer un état incomplet.
Rendu côté client vs SSR vs SSG : l'impact sur l'indexation
La stratégie de rendu que tu choisis pour ton application JavaScript a un impact direct et mesurable sur les résultats d'indexation. Comprendre les compromis entre le rendu côté client (CSR), le rendu côté serveur (SSR) et la génération de site statique (SSG) est essentiel pour prendre des décisions architecturales éclairées.
Le rendu côté client est le défaut pour les applications monopages construites avec Create React App, Vue CLI ou Angular CLI. Le serveur envoie un document HTML minimal contenant un élément racine et des balises script. Tout le rendu de contenu se produit dans le navigateur après que le JavaScript se charge et s'exécute. Du point de vue de Google, les pages CSR sont vides jusqu'à ce que la file de rendu les traite, ce qui crée les délais et les risques d'échec décrits ci-dessus. Le CSR est la stratégie de rendu la plus risquée pour le SEO et l'indexation.
Le rendu côté serveur génère le HTML complet sur le serveur pour chaque requête. Quand Googlebot demande une page, le serveur exécute le framework JavaScript, produit le HTML complet et l'envoie dans la réponse. La première vague de Google voit immédiatement tout le contenu sans avoir à attendre la file de rendu. Après le chargement du HTML dans le navigateur d'un véritable utilisateur, JavaScript hydrate la page pour la rendre interactive. Le SSR offre le meilleur des deux mondes : disponibilité immédiate du contenu pour Google et interactivité complète pour les utilisateurs. Les frameworks comme Next.js, Nuxt et SvelteKit fournissent des capacités SSR intégrées.
La génération de site statique pré-rend les pages au moment de la compilation plutôt qu'à chaque requête. Le résultat est une collection de fichiers HTML statiques servis directement depuis un CDN. Google reçoit un HTML complet instantanément, et il n'y a aucun délai ou échec de rendu côté serveur. Le SSG est idéal pour le contenu qui ne change pas à chaque requête : articles de blog, documentation, pages marketing et catalogues de produits qui se mettent à jour périodiquement plutôt qu'en temps réel. La limitation est que le SSG nécessite une recompilation pour mettre à jour le contenu, ce qui le rend peu pratique pour les pages très dynamiques comme les tableaux de bord, les résultats de recherche ou les affichages d'inventaire en temps réel.
L'Incremental Static Regeneration (ISR), disponible dans Next.js et frameworks similaires, combine le SSG avec un re-rendu périodique. Les pages sont pré-rendues au moment de la compilation mais peuvent être régénérées à des intervalles définis ou à la demande quand le contenu change. Cela fournit la fiabilité d'indexation du SSG avec la fraîcheur de contenu du SSR. Pour les sites e-commerce avec des milliers de pages de produits qui changent périodiquement, l'ISR est souvent le choix optimal.
La recommandation pratique est claire : évite le rendu purement côté client pour toute page que tu veux faire indexer par Google. Utilise le SSR pour les pages dynamiques qui changent par requête et le SSG ou ISR pour le contenu qui change périodiquement. Si la migration de CSR à SSR n'est pas faisable à court terme, implémente le rendu dynamique comme solution de transition.
Diagnostiquer les échecs de rendu JavaScript
Identifier si le rendu JavaScript cause tes problèmes d'indexation nécessite des tests systématiques avec des outils qui te montrent exactement ce que Google voit à chaque étape du pipeline d'indexation.
L'outil de diagnostic principal est la fonctionnalité d'inspection d'URL de Google Search Console. Entre l'URL d'une page rendue par JavaScript non indexée et clique sur « Tester l'URL en direct ». L'outil effectue un crawl et un rendu en direct de la page, simulant le pipeline de traitement réel de Google. Examine deux sorties : la capture d'écran de la page rendue (qui montre ce que Google voit après l'exécution JavaScript) et les détails de la page testée (qui montrent le HTML brut et toute erreur de chargement de ressources). Compare la capture d'écran à ce que tu vois dans ton navigateur. Si la capture d'écran montre un contenu incomplet, des sections manquantes ou une page vide, Google échoue à rendre ton JavaScript correctement.
La seconde étape de diagnostic consiste à examiner le code source HTML brut. Ouvre l'URL de ta page dans un navigateur et appuie sur Ctrl+U pour afficher la source non rendue. C'est ce que Google voit dans la première vague d'indexation. Si la source montre un contenu significatif (titres, en-têtes, paragraphes de texte, liens), ton contenu est disponible immédiatement. Si elle montre seulement un div avec un ID comme « root » ou « app » et des balises script, ton contenu dépend entièrement du rendu JavaScript.
Troisièmement, vérifie les erreurs JavaScript qui pourraient empêcher le rendu. Dans les outils de développement de ton navigateur, ouvre l'onglet Console et recharge la page. Note tous les messages d'erreur en rouge. Ces mêmes erreurs se produiront dans l'environnement de rendu de Google et peuvent empêcher le chargement du contenu. Les coupables courants incluent les appels d'API vers des serveurs qui rejettent les requêtes sans en-têtes d'authentification appropriés (le renderer de Google n'envoie pas de cookies ou de tokens d'authentification), les erreurs CORS sur des ressources tierces, et les références à des API spécifiques au navigateur qui n'existent pas dans Chromium headless.
Quatrièmement, teste la vitesse de rendu. Le WRS de Google a un timeout pour l'exécution JavaScript. Dans les outils de développement de ton navigateur, ouvre l'onglet Performance et enregistre un chargement de page. Si ton contenu critique prend plus de trois à cinq secondes à apparaître après le chargement HTML initial, Google peut expirer avant que le contenu ne soit rendu. Les réponses d'API lentes, les gros bundles JavaScript et la logique de rendu complexe peuvent pousser ta page au-delà du timeout de rendu.
Cinquièmement, vérifie le contenu derrière des portes d'interaction. Certaines applications JavaScript chargent du contenu uniquement en réponse à des interactions utilisateur : cliquer sur un bouton « Charger plus », défiler au-delà d'un seuil ou sélectionner un onglet. Le renderer de Google n'effectue pas ces interactions. Le contenu caché derrière des exigences d'interaction ne sera jamais visible pour Google. Assure-toi que tout le contenu que tu veux faire indexer est visible au rendu initial de la page sans aucune interaction utilisateur requise.
Corrections spécifiques par framework pour les blocages d'indexation courants
Chaque framework JavaScript a son propre ensemble de patterns courants qui causent des problèmes d'indexation. Connaître les pièges et corrections spécifiques au framework peut épargner des heures de débogage.
Pour les applications React construites avec Create React App (CRA), l'application entière est rendue côté client par défaut. Il n'y a aucune capacité SSR intégrée. Le chemin de migration recommandé est de passer à Next.js, qui fournit le SSR et le SSG d'emblée tout en utilisant le même modèle de composant React. Si la migration vers Next.js n'est pas faisable, implémente le rendu dynamique en utilisant un service de pré-rendu qui génère des instantanés HTML statiques pour le crawler de Google.
Pour les applications Next.js, la plupart des problèmes d'indexation proviennent des pages qui utilisent uniquement la récupération de données côté client (useEffect + fetch) au lieu de la récupération de données côté serveur (getServerSideProps ou getStaticProps, ou les nouveaux server components de l'App Router). Si le contenu de ta page est chargé dans un hook useEffect, il n'apparaîtra pas dans le HTML rendu côté serveur. Déplace la récupération de données vers la couche serveur. Dans l'App Router, utilise les Server Components par défaut et n'ajoute « use client » qu'aux composants qui ont véritablement besoin d'interactivité. Dans le Pages Router, utilise getServerSideProps pour les données dynamiques et getStaticProps pour les données statiques.
Pour les applications Vue utilisant Nuxt, des principes similaires s'appliquent. Utilise asyncData ou useFetch dans le contexte serveur plutôt que des appels fetch uniquement côté client. Le mode SSR par défaut de Nuxt rend le contenu sur le serveur, mais les plugins et composants qui ne fonctionnent que côté client peuvent créer des trous dans la sortie rendue. Utilise explicitement le composant wrapper ClientOnly pour le contenu uniquement côté client et assure-toi qu'il n'est pas utilisé autour du contenu critique indexable.
Pour les applications Angular, Angular Universal fournit le rendu côté serveur. Implémente Angular Universal et assure-toi que tes composants de contenu principaux sont rendus sur le serveur. Surveille les composants qui référencent directement des objets spécifiques au navigateur comme window, document ou navigator, car ceux-ci lèveront des erreurs pendant le rendu côté serveur et peuvent empêcher la page de se rendre du tout.
Pour tous les frameworks, accorde une attention particulière au lazy loading et au code splitting. Les imports dynamiques qui chargent les composants à la demande (React.lazy, imports dynamiques dans Vue et Angular) peuvent empêcher le contenu d'être présent dans le rendu serveur initial. Le contenu critique au-dessus du pli ne devrait jamais être chargé en lazy. Déplace les composants de contenu clés dans le bundle principal pour t'assurer qu'ils se rendent dans la réponse HTML initiale.
Les Web Components présentent leurs propres défis. Bien que Google puisse rendre les Web Components standard, les structures Shadow DOM complexes et les éléments personnalisés profondément imbriqués peuvent ne pas se rendre de manière fiable dans le WRS. Teste explicitement le rendu des Web Components en utilisant l'outil d'inspection d'URL et envisage d'aplatir le contenu critique hors du Shadow DOM pour une meilleure fiabilité d'indexation.
Le rendu dynamique comme solution de transition
Le rendu dynamique est une technique où ton serveur détecte si la requête entrante provient d'un crawler de moteur de recherche ou d'un utilisateur régulier et sert un contenu différent en conséquence. Les requêtes de crawler reçoivent une version HTML statique entièrement pré-rendue de la page, tandis que les requêtes d'utilisateur reçoivent l'application JavaScript normale. Google a explicitement approuvé le rendu dynamique comme approche acceptable pour les sites qui ne peuvent pas implémenter le SSR complet.
La configuration implique trois composants. Premièrement, un mécanisme de détection de user-agent sur ton serveur ou CDN qui identifie les requêtes de Googlebot et autres crawlers de moteurs de recherche. Googlebot s'identifie avec une chaîne user-agent contenant « Googlebot », qui est simple à matcher. Deuxièmement, un service de pré-rendu (comme Puppeteer, Rendertron ou un service commercial comme Prerender.io) qui génère et met en cache des instantanés HTML statiques de tes pages JavaScript. Troisièmement, une logique de routage qui sert le HTML pré-rendu aux requêtes de crawler détectées et l'application JavaScript normale à toutes les autres requêtes.
Le rendu dynamique n'est explicitement pas du cloaking, ce qui est contraire aux directives de Google. Le cloaking implique de montrer un contenu complètement différent aux utilisateurs et aux crawlers pour manipuler les classements. Le rendu dynamique montre le même contenu dans un format technique différent. L'instantané HTML pré-rendu devrait contenir exactement le même texte, les mêmes images, les mêmes liens et les mêmes données structurées que la version rendue par JavaScript. Google a confirmé à plusieurs reprises cette distinction.
Les approches d'implémentation varient selon l'infrastructure. Pour les serveurs Node.js, tu peux utiliser un middleware qui vérifie l'en-tête user-agent et achemine les requêtes Googlebot via Puppeteer ou Rendertron. Pour les sites derrière un CDN comme Cloudflare, tu peux utiliser des edge workers pour intercepter les requêtes Googlebot et servir des pages pré-rendues mises en cache. Pour l'hébergement statique avec un backend API, un service de pré-rendu peut générer des instantanés HTML pendant ton processus de build ou de déploiement.
La stratégie de mise en cache pour les pages pré-rendues importe. Les instantanés pré-rendus deviennent obsolètes à mesure que ton contenu change. Pour le contenu statique comme les articles de blog ou la documentation, les instantanés peuvent être mis en cache pendant des jours ou des semaines. Pour le contenu dynamique comme les pages de produit avec des prix et disponibilités changeants, les instantanés devraient être régénérés au moins quotidiennement. Pour le contenu en temps réel comme les tickers boursiers ou les scores en direct, le rendu dynamique peut ne pas être approprié parce que l'instantané mis en cache sera toujours obsolète.
Le rendu dynamique devrait être considéré comme une solution transitoire, pas comme une architecture permanente. La meilleure pratique à long terme est d'implémenter un rendu côté serveur natif afin que tous les utilisateurs et crawlers reçoivent la même réponse. Le rendu dynamique ajoute de la complexité, une charge de maintenance et un point de défaillance potentiel (si le service de pré-rendu tombe en panne, Googlebot voit des pages cassées). Utilise-le comme un pont en attendant de migrer vers le SSR ou SSG.
Guide étape par étape
Déterminer ta stratégie de rendu actuelle
Ouvre une de tes pages non indexées et affiche le code source HTML (Ctrl+U, pas l'inspecteur des outils de développement). Regarde le contenu du body. Si tu vois un seul div avec un ID comme « root » ou « app » et une ou plusieurs balises script, ta page utilise un rendu purement côté client. Si tu vois un contenu HTML complet incluant des titres, des paragraphes et des données structurées, ta page est au moins partiellement rendue côté serveur. Documente quelle stratégie de rendu chaque section de ton site utilise. De nombreuses applications modernes utilisent un mélange : navigation et mise en page rendues côté serveur avec des zones de contenu rendues côté client.
Tester les pages avec l'outil d'inspection d'URL de Google
Dans Google Search Console, entre l'URL d'une page non indexée et clique sur « Tester l'URL en direct ». Attends que le test se termine puis examine les résultats. Examine la capture d'écran de la page rendue pour voir si ton contenu apparaît. Vérifie la section « Plus d'infos » pour toute erreur de chargement de ressources, erreur JavaScript ou ressource bloquée. Si la capture d'écran montre le contenu complet de ta page mais que la page n'est toujours pas indexée, le rendu fonctionne mais il peut y avoir d'autres problèmes (thin content, balises noindex, conflits canonical). Si la capture d'écran montre un contenu manquant ou une page vide, les échecs de rendu bloquent l'indexation. Teste cinq à dix pages à travers différentes sections de ton site pour identifier des patterns.
Identifier et corriger les erreurs de rendu JavaScript
Dans les résultats de l'outil d'inspection d'URL, vérifie les ressources bloquées et les erreurs de ressources de page. Les problèmes courants incluent les appels d'API qui échouent parce que le renderer de Google n'envoie pas de cookies d'authentification, les ressources cross-origin bloquées par CORS, les références à des API navigateur non disponibles dans le renderer headless de Google (window.localStorage, navigator.geolocation) et les scripts tiers qui bloquent le rendu. Pour chaque erreur, détermine si elle affecte le contenu critique. Corrige l'authentification d'API en fournissant des endpoints publics pour les données de contenu. Remplace les appels d'API spécifiques au navigateur par des alternatives côté serveur ou fournis un comportement de repli quand les API ne sont pas disponibles.
Implémenter le rendu côté serveur ou la génération statique
Selon ton framework, implémente la stratégie de rendu serveur appropriée. Pour les projets React CRA, migre vers Next.js avec son App Router et ses Server Components. Pour les projets Vue CLI, migre vers Nuxt avec son SSR intégré. Pour les projets Angular, implémente Angular Universal. Pour les projets Next.js ou Nuxt existants qui utilisent la récupération de données côté client, déplace la récupération de données vers des fonctions côté serveur (getServerSideProps, getStaticProps, server components ou asyncData). Après avoir implémenté le SSR ou SSG, vérifie en affichant la source de la page et en confirmant que le contenu apparaît dans le HTML brut sans exécution JavaScript.
Implémenter le rendu dynamique comme correctif à court terme si nécessaire
Si la migration vers le SSR n'est pas immédiatement faisable, implémente le rendu dynamique comme solution de transition. Configure un service de pré-rendu (Puppeteer, Rendertron ou Prerender.io). Configure ton serveur ou CDN pour détecter les requêtes Googlebot par chaîne user-agent et les acheminer vers le HTML pré-rendu. Teste en utilisant curl avec une chaîne user-agent Googlebot pour vérifier que le HTML pré-rendu est servi correctement. Compare le HTML pré-rendu à la page normale pour assurer la parité du contenu. Configure des rafraîchissements automatisés du cache de pré-rendu pour garder les instantanés à jour avec ton contenu.
Vérifier les corrections et soumettre pour indexation
Après avoir implémenté le SSR, SSG ou rendu dynamique, retesteste tes pages avec l'outil d'inspection d'URL. Vérifie que la capture d'écran rendue montre le contenu complet et qu'aucune erreur de ressource n'est signalée. Affiche la source de la page pour confirmer que le contenu est dans le HTML initial. Une fois vérifié, utilise l'outil d'inspection d'URL pour demander l'indexation de tes pages hautement prioritaires. Pour les sites avec de nombreuses pages affectées par des problèmes de rendu JavaScript, utilise IndexBolt pour soumettre toutes les URLs corrigées en masse pour une indexation rapide. Surveille le rapport Pages au cours des deux semaines suivantes pour suivre la récupération de l'indexation.
Mettre en place une surveillance continue des régressions de rendu
Les problèmes de rendu JavaScript peuvent réapparaître après des déploiements de code, des mises à jour de dépendances ou des changements d'API. Mets en place une surveillance automatisée pour détecter les régressions tôt. Utilise Lighthouse CI ou un outil similaire dans ton pipeline CI/CD pour tester la sortie HTML rendue côté serveur pour les pages clés. Configure des alertes pour les échecs de rendu dans ton service de pré-rendu. Planifie des vérifications hebdomadaires du rapport Pages de Google Search Console pour détecter tout nouveau pic de pages « Explorée, actuellement non indexée » qui pourrait indiquer une régression de rendu. Documente ton architecture de rendu et tes exigences SSR afin que les nouveaux membres de l'équipe n'introduisent pas accidentellement des patterns de contenu uniquement côté client.
Problèmes courants et comment les résoudre
Une app React affiche une page vide ou un loader dans l'outil d'inspection d'URL
Cause : L'application utilise un rendu purement côté client (Create React App ou similaire) où le serveur envoie une coquille HTML vide et JavaScript construit toute la page dans le navigateur. La première vague d'indexation de Google ne voit aucun contenu, et la file de rendu peut échouer à traiter la page en raison d'erreurs d'API, de longs temps de chargement ou de rendu gourmand en ressources.
Solution : Migre vers Next.js pour le rendu côté serveur intégré. En attendant, implémente le rendu dynamique avec Prerender.io ou une instance Rendertron auto-hébergée. Assure-toi que les endpoints d'API utilisés par l'application sont publiquement accessibles sans authentification afin que le renderer de Google puisse récupérer les données. Si la migration n'est pas possible immédiatement, ajoute au minimum les balises meta critiques (title, description, canonical) et le texte des titres clés au template HTML statique que le serveur envoie avant le chargement du JavaScript.
Pages Next.js indexées mais affichant du contenu obsolète dans les résultats Google
Cause : Les pages utilisant la Génération de Site Statique (getStaticProps) sont pré-rendues au moment de la compilation, et Google a mis en cache la version du moment du build. Si ton contenu change entre les builds, la version indexée devient obsolète. Ce n'est pas un échec de rendu mais un problème de fraîcheur. Les pages utilisant l'Incremental Static Regeneration peuvent également afficher du contenu obsolète si l'intervalle de revalidation est plus long que la fréquence de crawl de Google.
Solution : Pour les pages avec du contenu changeant fréquemment, passe de SSG à SSR (getServerSideProps ou pages App Router dynamiques). Pour les pages utilisant l'ISR, réduis l'intervalle de revalidation pour qu'il corresponde à ta fréquence de mise à jour du contenu. Après une mise à jour majeure du contenu, utilise IndexBolt ou Search Console pour demander le re-crawl des pages mises à jour afin que Google récupère la dernière version. Envisage d'implémenter l'ISR à la demande qui déclenche la régénération de page quand le contenu est mis à jour plutôt que de te fier à une revalidation basée sur le temps.
Application monopage avec routage basé sur le hash dont les pages internes ne sont pas indexées
Cause : Le routage basé sur le hash (URLs comme tondomaine.com/#/about, tondomaine.com/#/products) est invisible pour Google. Google traite tout ce qui suit le # comme un identifiant de fragment et ne l'envoie pas au serveur. Toutes les URLs basées sur le hash se résolvent à la même page du point de vue de Google. Le WRS de Google ne navigue pas entre les routes hash, donc seul le contenu de la page initiale est rendu.
Solution : Migre du routage basé sur le hash vers un routage basé sur l'historique (URLs propres comme tondomaine.com/about, tondomaine.com/products). Dans React Router, passe de HashRouter à BrowserRouter. Dans Vue Router, définis le mode sur « history » au lieu de « hash ». Configure ton serveur pour gérer tous les chemins de route et retourner le HTML de l'application pour tout chemin d'URL. Après la migration, soumets les nouvelles URLs propres via Google Search Console ou IndexBolt et surveille l'indexation de chaque route.
Composants et images en lazy loading n'apparaissant pas dans le rendu de Google
Cause : Le contenu chargé via React.lazy(), les imports dynamiques ou le lazy loading basé sur intersection observer peut ne pas se rendre dans le WRS de Google s'il dépend d'événements de position de défilement ou d'intersection de viewport. Le renderer de Google charge la page mais ne défile pas ni ne redimensionne le viewport, donc le contenu déclenché par les événements de défilement reste non chargé.
Solution : Ne charge jamais en lazy le contenu critique au-dessus du pli. Pour le contenu sous le pli que tu veux faire indexer, utilise le lazy loading natif (attribut loading="lazy" sur les images) que Google prend en charge, plutôt que le lazy loading basé sur intersection observer en JavaScript qui nécessite des événements de défilement. Pour les composants importés dynamiquement qui contiennent du contenu indexable, charge-les avec empressement côté serveur et fais du lazy load uniquement côté client pour la performance. Inclus un fallback noscript avec du contenu critique pour une résilience maximale du rendu.
Pages de contenu pilotées par API échouant à se rendre parce que l'API nécessite une authentification
Cause : De nombreuses applications JavaScript récupèrent du contenu depuis des API qui nécessitent des tokens d'authentification, des clés API dans les en-têtes ou des cookies de session. Le WRS de Google n'a pas accès à ton système d'authentification, ne peut pas se connecter et n'envoie pas de cookies d'authentification. Les appels d'API qui retournent des erreurs 401 ou 403 pendant le rendu de Google entraînent des zones de contenu vides.
Solution : Pour le contenu qui devrait être publiquement accessible, crée des endpoints d'API publics qui ne nécessitent pas d'authentification. Sers le contenu de page que Google a besoin de voir depuis des endpoints publics tout en gardant les données spécifiques à l'utilisateur (détails de compte, personnalisation) derrière des endpoints authentifiés. Implémente la récupération de données côté serveur où le serveur s'authentifie auprès de l'API et inclut le contenu dans la réponse HTML avant de l'envoyer au navigateur. Cela élimine le besoin d'authentification d'API côté client pendant le rendu.
Astuces pro
Les délais de rendu JavaScript signifient que tes pages peuvent attendre des jours dans la file de rendu de Google avant d'être indexées. IndexBolt contourne l'attente en soumettant tes URLs directement au pipeline d'indexation de Google. Que tu utilises React, Vue, Angular ou Next.js, fais indexer immédiatement tes pages rendues par JavaScript au lieu d'espérer que le renderer de Google les traite correctement.
100 crédits gratuits. Aucune carte bancaire requise. Résultats en moins de 24 heures.
Questions fréquentes
Google peut-il vraiment rendre les pages JavaScript de manière fiable ?+
Le WRS de Google utilise Chromium moderne et rend la plupart du contenu JS, mais ce n'est pas instantané (délais de file), pas fiable à 100 % (les échecs d'API causent des rendus incomplets) et pas universel (pas d'API d'interaction). Pour les pages importantes, te fier entièrement au rendu JS est risqué. Le SSR élimine ce risque en garantissant que le contenu est toujours dans le HTML initial.
Le rendu côté serveur est-il nécessaire pour le SEO, ou est-il juste recommandé ?+
Pas techniquement nécessaire. Google peut indexer le contenu CSR. Mais le SSR fournit une fiabilité, une vitesse et une couverture considérablement meilleures. Les pages CSR font face à des délais de file de rendu, des risques d'échec et une dépriorisation de crawl. Le contenu SSR est évalué immédiatement dans la première vague. Pour toute page où le trafic organique compte, le SSR est fortement recommandé. Le CSR convient pour les tableaux de bord authentifiés et les panneaux d'administration.
Comment savoir si Google rend avec succès mes pages JavaScript ?+
Utilise l'outil d'inspection d'URL de Google Search Console pour voir exactement ce que Google rend. Entre une URL, clique sur « Tester l'URL en direct » et compare la capture d'écran rendue avec ce que tu vois dans ton navigateur. Si le contenu correspond, le rendu fonctionne. Vérifie également la section « Page explorée » pour le HTML que Google a reçu et la section « Plus d'infos » pour toute erreur de chargement de ressources. Pour une surveillance continue, suis le ratio de pages soumises (dans ton sitemap) par rapport aux pages indexées dans le rapport Pages. Un grand écart suggère que des problèmes de rendu ou de qualité empêchent l'indexation.
Quelle version de Chrome Googlebot utilise-t-il pour le rendu ?+
Le Web Rendering Service de Google exécute une version evergreen de Chromium, ce qui signifie qu'elle reste à jour avec la dernière version stable de Chrome. À partir de 2026, cela signifie une prise en charge complète de JavaScript moderne (ES2022+), CSS Grid, Flexbox, Web Components, imports dynamiques, IntersectionObserver et la plupart des fonctionnalités modernes de la plateforme web. Cependant, l'environnement de rendu ne prend pas en charge les API d'interaction utilisateur (pas d'événements de clic, de défilement, de survol ou de clavier), ne prend pas en charge les API de paiement ou de notification, et a une prise en charge limitée de localStorage/sessionStorage. Consulte la documentation officielle de Google pour la liste actuelle des API prises en charge et non prises en charge.
Devrais-je utiliser le rendu dynamique ou passer au rendu côté serveur ?+
Si tu as les ressources d'ingénierie pour implémenter le SSR, c'est toujours le meilleur choix à long terme. Le SSR bénéficie à tous les utilisateurs (chargements de page initiaux plus rapides, meilleure accessibilité, Core Web Vitals améliorés), pas seulement aux crawlers de moteurs de recherche. Le rendu dynamique est une solution à court terme valide pour les équipes qui ne peuvent pas migrer vers le SSR rapidement, mais il ajoute de la complexité de maintenance (tu dois maintenir le service de pré-rendu en fonctionnement et le cache à jour) et crée un système où les utilisateurs et les crawlers voient des réponses techniquement différentes. Utilise le rendu dynamique comme un pont en planifiant et exécutant une migration SSR.
Mon app Next.js utilise les Server Components. Pourquoi les pages ne sont-elles toujours pas indexées ?+
Les Server Components Next.js sont rendus côté serveur par défaut, ce qui devrait fournir une excellente indexation. Les problèmes courants incluent : importer un composant avec « use client » qui enveloppe le contenu principal (le forçant à se rendre côté client), récupérer des données dans un composant client au lieu de les passer en props depuis un server component, avoir un fichier loading.tsx qui affiche un squelette au lieu du contenu pendant le rendu serveur, ou un middleware qui redirige Googlebot vers une autre page. Vérifie ton arbre de composants et assure-toi que les composants principaux portant du contenu sont des Server Components (pas de directive « use client ») et que la récupération de données se produit au niveau serveur.