Le prerendering JavaScript pose-t-il encore des risques d'indexation en SEO ?

Pourquoi Google parle-t-il de prerendering et pas simplement de rendu côté serveur ?

Le prerendering consiste à générer une version HTML statique complète d'une page avant qu'elle ne soit demandée par un crawler ou un utilisateur. À la différence du Server-Side Rendering (SSR) classique, le prerendering peut être déclenché par un service tiers ou un headless browser qui exécute le JavaScript puis fige le résultat.

Google distingue cette approche du rendu purement client-side, où le bot doit attendre l'exécution du JS pour voir le contenu. Avec un prerendering bien calibré, Googlebot reçoit immédiatement un DOM complet, sans latence d'exécution JS. Le risque ? Si le prerendering ignore certains scripts ou lazy-load des blocs entiers, le bot ne voit qu'une coquille vide.

Qu'est-ce qui constitue un « contenu complet » selon cette déclaration ?

Mueller ne donne pas de liste exhaustive, mais on comprend qu'il s'agit de tout élément structurant : titres, paragraphes, images avec attributs alt, données structurées, liens internes. Si un composant React ou Vue génère du texte critique après hydratation, il doit apparaître dans le prérendu.

Le piège classique : fragmenter le prerendering pour économiser du temps serveur. Par exemple, ne précharger que le above-the-fold et laisser le reste en lazy JS. Googlebot peut théoriquement exécuter le JS restant, mais rien ne garantit qu'il attende suffisamment longtemps ou qu'il trigger les observers nécessaires.

Quels sont les cas d'usage où le prerendering partiel est tentant mais dangereux ?

Les sites e-commerce avec des milliers de SKU cherchent souvent à optimiser les coûts de calcul en ne prérendant que les métadonnées produit, laissant descriptions enrichies et avis clients en JS différé. Résultat : Googlebot indexe une fiche produit squelettique.

Même chose pour les blogs techniques avec des widgets de code interactifs ou des graphiques D3.js : si ces éléments ne sont pas prérendus (même sous forme de fallback statique), ils disparaissent du crawl. Google peut extraire le titre et l'intro, mais perd le corps de l'article si celui-ci est injecté par un framework après montage.

• Inclure tous les contenus textuels, images et liens critiques dans le HTML prérendu, sans dépendre d'un second passage JS.
• Vérifier le rendu final avec un fetch as Googlebot (Search Console URL Inspection) pour comparer avec la version utilisateur.
• Éviter les patterns de lazy-loading qui nécessitent un scroll ou un événement utilisateur pour charger du contenu indexable.
• Ne jamais compter sur les promesses d'exécution JS « suffisamment longue » de Googlebot — le budget crawl et les timeouts varient.
• Documenter les éléments générés dynamiquement pour s'assurer qu'ils sont bien capturés par le pipeline de prerendering.

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