Rendering

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).

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 fetch et XMLHttpRequest
• 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

Contenu critique en CSR pur — Déployer un site entièrement en CSR (React SPA, Angular SPA, Vue SPA) sans SSR ni pré-rendering pour des pages qui doivent être indexées. Le contenu est invisible dans le HTML source et entièrement dépendant du bon fonctionnement du WRS.

Erreurs JavaScript silencieuses — Une erreur JS non capturée (TypeError, ReferenceError, API indisponible) peut interrompre le rendering et laisser la page vide ou partiellement rendue côté Google, sans aucune alerte visible dans GSC.

Ressources tierces bloquées — Les appels API vers des domaines tiers qui échouent (CORS, timeout, rate limiting) empêchent le rendering du contenu dépendant de ces données. Si le contenu produit vient d’une API externe, prévoir un fallback côté serveur.

Lazy loading basé sur le scroll — Le contenu chargé uniquement au scroll de l’utilisateur ne sera jamais rendu par le WRS, qui ne simule pas le scroll. Utiliser l’IntersectionObserver avec un seuil approprié ou charger le contenu critique immédiatement.

Hydration mismatch — En SSR, une différence entre le HTML pré-rendu côté serveur et le DOM reconstruit côté client (hydration) peut provoquer des erreurs React/Vue et un re-rendering complet, dégradant les Core Web Vitals et potentiellement le contenu vu par Google.

Bloquer les ressources JS/CSS dans robots.txt — Empêcher le WRS d’accéder aux fichiers JavaScript ou CSS nécessaires au rendering rend la page non rendable par Google.

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 »

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