Le rendering est le processus par lequel un moteur de recherche — ou un navigateur — exécute le code d’une page (HTML, CSS, JavaScript) pour générer le DOM final tel qu’il sera visuellement affiché et sémantiquement compris. En SEO, le rendering désigne spécifiquement la capacité de Googlebot à exécuter le JavaScript d’une page pour accéder au contenu qui n’est pas présent dans le HTML brut initial. C’est l’étape intermédiaire entre le crawl (récupération du HTML source) et l’indexation (stockage du contenu compris).
• Le rendering transforme le HTML source en DOM final exploitable.
• Le JavaScript génère du contenu visible après le rendering.
• Le rendu côté serveur (SSR) accélère l’indexation du contenu.
• Le rendu côté client (CSR) retarde la découverte du contenu par Google.
• Le rendering consomme des ressources du budget crawl.
• Le DOM rendu est la version que Google indexe réellement.
Fonctionnement chez Google : le crawl en deux vagues
Google opère un processus de rendering en deux phases distinctes, ce qui est fondamental à comprendre pour tout site dépendant du JavaScript :
Première vague — Crawl du HTML brut — Googlebot télécharge le HTML source de la page. À ce stade, il extrait les liens <a href> présents dans le HTML statique, les métadonnées (<title>, <meta description>, <link rel="canonical">), et le contenu textuel directement disponible dans le code source. Si le site repose sur le Server-Side Rendering, l’essentiel du contenu est déjà disponible à cette étape.
Seconde vague — Rendering JavaScript — La page est envoyée dans une file d’attente du Web Rendering Service (WRS), un service basé sur une version headless de Chrome (Chromium evergreen, maintenu à jour avec les dernières versions stables). Le WRS exécute le JavaScript, résout les appels API (fetch, XHR), construit le DOM final et le CSSOM, puis renvoie le résultat au pipeline d’indexation. Ce processus peut prendre de quelques secondes à plusieurs jours selon la charge de la file d’attente et la priorité attribuée au site.
Ce décalage entre les deux vagues signifie qu’un contenu généré exclusivement par JavaScript côté client peut être découvert et indexé avec un retard significatif — un problème critique pour les contenus à forte fraîcheur (actualités, promotions, stock en temps réel).
Stratégies de rendering
SSR — Server-Side Rendering (Rendu côté serveur)
Le serveur exécute le JavaScript et envoie au client (et à Googlebot) un HTML complet contenant tout le contenu. C’est la stratégie la plus favorable au SEO car elle élimine la dépendance au rendering côté Google. Frameworks compatibles : Next.js (React), Nuxt.js (Vue), SvelteKit, Angular Universal.
CSR — Client-Side Rendering (Rendu côté client)
Le serveur envoie une coquille HTML quasi vide avec des bundles JavaScript. Le contenu est généré entièrement dans le navigateur (ou dans le WRS de Google). C’est la stratégie la plus risquée pour le SEO : dépendance totale au rendering JavaScript de Google, délai d’indexation, et échec de rendering en cas d’erreur JS, timeout ou ressource bloquée.
SSG — Static Site Generation (Génération statique)
Les pages sont pré-générées au moment du build sous forme de fichiers HTML statiques. Idéal pour le SEO (HTML complet, temps de réponse minimal), mais inadapté aux contenus dynamiques ou aux sites à très grand nombre de pages nécessitant des mises à jour fréquentes. Frameworks : Next.js (export statique), Gatsby, Hugo, Astro.
ISR — Incremental Static Regeneration (Régénération statique incrémentale)
Hybride entre SSG et SSR. Les pages sont servies en statique mais régénérées en arrière-plan selon un intervalle défini (revalidate). Combine les avantages SEO du HTML statique avec la capacité de mise à jour. Spécifique à Next.js et aux plateformes Vercel/Netlify.
Dynamic Rendering (Rendu dynamique)
Le serveur détecte le User-Agent du visiteur : s’il s’agit d’un bot, il sert une version pré-rendue (HTML complet) ; s’il s’agit d’un utilisateur humain, il sert la version CSR. Google a officiellement qualifié cette approche de solution de contournement (workaround) et non de solution pérenne. Elle est tolérée mais déconseillée à long terme car elle crée une dette technique et un risque de divergence entre les versions.
Le Web Rendering Service (WRS) en détail
Le WRS de Google fonctionne sur un Chromium headless sans état (stateless) : il ne conserve ni cookies, ni localStorage, ni sessionStorage entre les sessions de rendering. Cela signifie que tout contenu dépendant d’un état de session, d’une authentification, d’un consentement cookie ou d’un stockage local ne sera jamais visible par Google.
Capacités actuelles du WRS :
- Exécution d’ES6+ et des APIs JavaScript modernes
- Support des Web Components et du Shadow DOM
- Résolution des requêtes
fetchetXMLHttpRequest - Exécution des CSS modernes (Flexbox, Grid, variables CSS)
- Support des APIs IntersectionObserver (lazy loading natif)
Limitations du WRS :
- Pas de support des interactions utilisateur (click, scroll, hover) — le contenu déclenché par interaction n’est pas rendu
- Pas de permissions (géolocalisation, notifications, caméra)
- Pas de persistance (cookies, localStorage, sessionStorage, IndexedDB)
- Timeout d’exécution limité — les scripts trop lents sont interrompus
- Pas de support de WebSocket pour le contenu en temps réel
- Les ressources bloquées par robots.txt ne sont pas chargées, ce qui peut casser le rendering
Impact SEO du rendering
Découverte des liens — Les liens générés dynamiquement par JavaScript (routage SPA, navigation AJAX) ne sont découverts par Google qu’après rendering. Si le rendering échoue ou est retardé, les pages liées ne seront pas crawlées. Les liens doivent idéalement être des <a href="..."> standard dans le HTML source pour garantir la découverte en première vague.
Contenu indexé — Google indexe le DOM post-rendering, pas le HTML source. Mais le délai de rendering signifie que les mises à jour de contenu JavaScript-dependent peuvent mettre plus de temps à être reflétées dans l’index. Pour les sites d’actualité ou e-commerce avec des mises à jour fréquentes de stock/prix, le SSR est quasi indispensable.
Métadonnées — Les balises <title>, <meta description>, <link rel="canonical"> et les données structurées modifiées par JavaScript sont prises en compte après rendering, mais il est recommandé de les inclure dans le HTML initial pour garantir leur lecture en première vague.
Core Web Vitals — Les stratégies de rendering impactent directement le LCP (un SSR ou SSG produit un LCP plus rapide qu’un CSR pur), l’INP (la quantité de JavaScript exécuté côté client affecte la réactivité) et le CLS (les contenus injectés dynamiquement après le chargement initial provoquent des layout shifts).
Erreurs fréquentes du rendering
• Si le contenu n’est pas présent dans le HTML source, son indexation dépend entièrement du bon fonctionnement du rendering JavaScript.
• Erreurs JavaScript silencieuses : une TypeError, ReferenceError ou API indisponible peut interrompre le rendering et laisser la page vide ou partiellement rendue côté Google.
• Ressources tierces bloquées : des appels API qui échouent à cause du CORS, d’un timeout ou du rate limiting empêchent le rendu du contenu dépendant de ces données.
• Lazy loading basé sur le scroll : le contenu chargé uniquement au scroll ne sera pas rendu correctement, car le WRS ne simule pas toujours le comportement d’un utilisateur réel.
• Hydration mismatch : une différence entre le HTML pré-rendu côté serveur et le DOM reconstruit côté client peut provoquer un re-rendering complet et dégrader les Core Web Vitals.
• Ressources JS/CSS bloquées dans robots.txt : empêcher Google d’accéder aux fichiers nécessaires au rendering rend la page difficilement interprétable par Googlebot.
Leviers d’optimisation du rendering
- Privilégier le SSR ou le SSG pour toutes les pages à vocation SEO — garantit que le contenu est dans le HTML initial sans dépendre du rendering Google
- Inclure les liens critiques en HTML standard (
<a href>) dans le code source, même sur un site SPA, pour garantir la découverte en première vague de crawl - Pré-rendre les métadonnées —
<title>,<meta description>, canonical et schema JSON-LD doivent être dans le HTML source initial - Auditer le DOM rendu → Comparer le HTML source (
view-source:) avec le DOM rendu (Chrome DevTools → Elements) pour identifier les contenus dépendants du JavaScript - Gérer les erreurs JS gracieusement — Implémenter des error boundaries (React) ou des fallbacks pour que le contenu critique s’affiche même en cas d’échec partiel du JavaScript
- Minimiser les chaînes de dépendances JS — Réduire le critical rendering path : inline le CSS critique, différer les scripts non essentiels, éviter les chaînes de requêtes séquentielles (API → API → rendering)
- Ne jamais bloquer JS/CSS dans robots.txt — Toutes les ressources nécessaires au rendering doivent être accessibles à Googlebot
Outils de diagnostic du rendering
- Google Search Console → Inspection d’URL → Compare le HTML crawlé (première vague) avec le HTML rendu (après WRS) et affiche une capture d’écran du rendering — outil le plus fiable pour vérifier ce que Google voit réellement
- Chrome DevTools → onglet Elements → Inspecter le DOM final post-rendering côté navigateur
view-source:vs DevTools → Comparer le HTML source brut avec le DOM rendu pour identifier les contenus JavaScript-dependent- Chrome DevTools → Disable JavaScript → Visualiser la page sans JavaScript pour simuler un scénario d’échec de rendering
- Lighthouse → SEO audit → Signale les problèmes de contenu non crawlable et de métadonnées manquantes
- Rich Results Test (Google) → Affiche le HTML rendu et vérifie la détection des données structurées après rendering JavaScript
- Screaming Frog (mode JavaScript rendering) → Crawl avec exécution JavaScript pour comparer le contenu rendu vs HTML source à l’échelle du site
- Web Rendering Service logs (GSC) → Les erreurs de rendering sont parfois signalées dans le rapport d’indexation sous le statut « Crawled – currently not indexed »
FAQ Rendering
Quelle est la différence entre SSR, CSR et SSG ?
Le SSR, Server-Side Rendering, exécute le JavaScript côté serveur et envoie un HTML complet au navigateur et à Googlebot. Le CSR, Client-Side Rendering, envoie un HTML quasi vide et génère le contenu dans le navigateur via JavaScript. Le SSG, Static Site Generation, pré-génère les pages en HTML statique au moment du build. Pour le SEO, le SSR et le SSG sont recommandés car le contenu est immédiatement disponible sans dépendre du rendering de Google.
Google peut-il exécuter le JavaScript de mon site ?
Oui. Le Web Rendering Service, ou WRS, de Google utilise un Chromium headless maintenu à jour qui exécute le JavaScript moderne, comme ES6+, fetch ou Web Components. Cependant, le rendering se fait en deux vagues avec un délai potentiel de plusieurs heures à plusieurs jours entre le crawl du HTML brut et l’exécution du JavaScript. Le contenu dépendant exclusivement du JavaScript peut donc être indexé avec un retard significatif.
Pourquoi mon contenu JavaScript n’est-il pas indexé ?
Les causes les plus fréquentes sont une erreur JavaScript silencieuse qui interrompt le rendering, des ressources tierces bloquées, comme une API en timeout, une erreur CORS ou du rate limiting, des fichiers JS ou CSS bloqués par le robots.txt, un contenu déclenché uniquement par une interaction utilisateur, comme un clic ou un scroll, que le WRS ne simule pas, ou un timeout d’exécution dépassé sur des scripts trop lourds.
Le Dynamic Rendering est-il recommandé par Google ?
Non. Google a qualifié le Dynamic Rendering de solution de contournement, ou workaround, pas de solution pérenne. Il est toléré mais déconseillé à long terme car il crée une dette technique et un risque de divergence entre la version servie aux bots et celle servie aux utilisateurs. Le SSR ou le SSG sont les alternatives recommandées.
Comment vérifier ce que Google voit après rendering ?
Utiliser l’inspection d’URL dans Google Search Console, qui compare le HTML crawlé, correspondant à la première vague, avec le HTML rendu après WRS et affiche une capture d’écran. Comparer également le HTML source avec view-source: et le DOM rendu dans Chrome DevTools, onglet Elements. Désactiver JavaScript dans Chrome DevTools permet aussi de simuler un scénario d’échec de rendering.
Besoin d’un accompagnement ?
Garantir que Google voit et indexe correctement votre contenu JavaScript — choisir la bonne stratégie de rendering (SSR, SSG, ISR), auditer le DOM rendu et corriger les erreurs silencieuses — demande une double expertise SEO et développement. Nos experts SEO technique diagnostiquent les problèmes de rendering de votre site et implémentent les solutions techniques pour sécuriser votre indexation.
Entités liées (→ définitions dédiées)
→ Crawl · Indexation · Budget crawl · Core Web Vitals · LCP · INP · CLS · Robots.txt · Balise canonical · Données structurées · Google Search Console · Mobile-First · TTFB
