Does JavaScript prerendering still pose indexing risks for SEO?

Why does Google talk about prerendering instead of just server-side rendering?

Prerendering involves generating a complete static HTML version of a page before it is requested by a crawler or a user. Unlike traditional Server-Side Rendering (SSR), prerendering can be triggered by a third-party service or a headless browser that executes JavaScript and then freezes the result.

Google distinguishes this approach from purely client-side rendering, where the bot must wait for the JS execution to see the content. With a well-calibrated prerendering, Googlebot receives an entire DOM immediately, without JS execution latency. The risk? If prerendering ignores certain scripts or lazy-loads entire blocks, the bot sees only an empty shell.

What constitutes

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Totalement. Les audits de sites SPA montrent régulièrement des écarts entre le DOM hydraté et le DOM crawlé, surtout quand le prerendering est délégué à un CDN edge worker mal configuré. Les outils comme Screaming Frog en mode JS vs no-JS révèlent ces trous béants : sections entières absentes, maillage interne invisible, balises alt manquantes.

Là où ça coince : certains headless CMS promettent un « prerendering automatique » mais ne gèrent pas les composants asynchrones imbriqués. Si un bloc attend une API tierce, le snapshot HTML se fige avant réponse. Googlebot hérite d'un spinner ou d'un placeholder vide. [A vérifier] : Google affirme pouvoir attendre « quelques secondes », mais aucune donnée publique ne précise le timeout exact ni les conditions de retry.

Quelles nuances faut-il apporter à cette directive ?

Mueller dit « autant de contenu que possible », pas « 100 % du contenu ». Traduction : il y a une hiérarchie d'importance. Un widget de chat live ou un bandeau cookies en JS pur ? Peu critique. Une description produit de 800 mots générée par Vue après fetch API ? Critique.

Le vrai débat porte sur les contenus évolutifs en temps réel : prix, stocks, avis. Faut-il les prérendrer au risque de servir des données périmées ? Ou laisser le JS les injecter, au risque qu'elles échappent au crawl ? La réponse dépend de la fraîcheur d'indexation souhaitée. Pour un site à fort crawl budget, un SSR/ISR avec revalidation courte est préférable. Pour un site crawlé une fois par semaine, un prerendering statique suffit.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Les applications web pures (SaaS derrière login, dashboards internes) n'ont aucun intérêt SEO à être indexées. Elles peuvent ignorer cette directive sans dommage. Idem pour les sections privées d'un site public : espaces membres, paniers, checkout.

Ensuite, les sites AMP ou ceux utilisant des formats structurés natifs (JSON-LD standalone, RSS enrichi) peuvent compenser un prerendering léger si Google accède aux données via d'autres canaux. Mais c'est une stratégie de niche : miser sur le parsing de schema.org pour pallier un DOM incomplet reste risqué.

Que faut-il auditer en priorité sur un site déjà en production ?

Lance un crawl dual-mode avec Screaming Frog ou OnCrawl : un passage sans exécution JS, un autre avec rendu complet. Compare les word counts, les liens extraits, les balises Hn. Tout écart de plus de 10 % signale un problème. Vérifie aussi l'URL Inspection Tool dans Search Console : le « HTML récupéré » doit contenir le contenu critique.

Ensuite, teste les pages stratégiques avec Puppeteer ou Playwright en mode headless, avec un timeout court (3 secondes). Si du contenu manque après ce délai, Googlebot risque de le manquer aussi. Identifie les composants asynchrones qui tardent à se charger et optimise-les ou précharge-les côté serveur.

Quelles erreurs techniques faut-il absolument éviter ?

Ne jamais servir un prerendering conditionnel basé uniquement sur le user-agent Googlebot. C'est du cloaking pur et dur. Si tu prérendres pour les bots, sers la même version aux utilisateurs (ou une variante progressive enhancement acceptable). Google détecte les divergences via les signaux Chrome et peut pénaliser.

Évite aussi les lazy-loaders qui attendent un IntersectionObserver pour charger du contenu above-the-fold. Googlebot ne scroll pas (sauf exceptions non documentées). Si un bloc critique nécessite un scroll pour apparaître, il sera invisible au crawl. Préfère un eager loading pour le contenu haut de page, lazy uniquement pour les images de footer ou les modules secondaires.

Comment mettre en place une stack de prerendering robuste ?

Privilégie un SSR ou ISR natif au framework (Next.js getServerSideProps, Nuxt SSR, SvelteKit) plutôt qu'un prerendering tiers post-build. Le SSR garantit un HTML frais à chaque requête, l'ISR permet de cacher avec revalidation programmée. Les solutions tierces (Prerender.io, Rendertron) ajoutent une couche de complexité et des points de défaillance.

Si tu dois utiliser un prerenderer externe, configure des timeouts généreux (10 secondes minimum) et désactive tout lazy-loading agressif durant le snapshot. Teste avec des requêtes curl simulant Googlebot pour vérifier que le HTML retourné est complet. Monitore les logs pour détecter les pages qui timeout ou retournent des erreurs 5xx durant le prerendering.

• Crawler le site en mode JS-off et JS-on, comparer les résultats
• Utiliser l'URL Inspection Tool pour chaque template critique
• Vérifier que le HTML source contient le contenu textuel complet, sans dépendre de scripts externes
• Tester les timeouts avec Puppeteer en simulant des connexions lentes
• Documenter les composants asynchrones et leur stratégie de prerendering
• Mettre en place des alertes si le taux de contenu crawlé chute