# SSR, CSR ou SSG pour le SEO : quel mode de rendu choisir ? SSR, CSR ou SSG pour ton SEO en 2026 : matrice de décision par type de site, impact Core Web Vitals chiffré, et ce que Googlebot voit vraiment. Publié le 2026-08-05 Source : https://abdelseo.fr/blog/choisir-entre-ssr-csr-ssg-pour-son-seo/ --- **Ce qu'il faut retenir** En 2026, certains sites qui rankent mal ne le doivent ni à leur contenu ni à leur netlinking, mais à un choix architectural fait des années plus tôt, sans réflexion SEO. React sur du contenu éditorial pur, headless sans stratégie de rendu, migration ratée vers Next.js sans ISR : autant de situations qu'un [consultant SEO technique](/consultant-seo-technique/) rencontre en mission. L'objectif ici : t'expliquer le plus simplement possible pourquoi choisir l'un plutôt que l'autre. Alors, c'est parti. ## SSR, CSR, SSG : les trois modes de rendu expliqués sans jargon - **SSR (Server-Side Rendering)** : à chaque requête, le serveur exécute ton code, construit le HTML et l'envoie au navigateur. Le visiteur (et Googlebot) reçoit une page prête. Le serveur travaille à chaque visite. - **CSR (Client-Side Rendering)** : le serveur envoie une coquille HTML vide plus un bundle JavaScript. Le navigateur exécute ce JS pour construire l'interface. Le serveur ne fait presque rien. - **SSG (Static Site Generation)** : au moment du build, toutes les pages sont pré-générées en HTML statique. Servies telles quelles par un CDN. Aucun calcul serveur à la requête. Autour de ces trois modes gravitent des variantes hybrides (ISR pour régénérer par lot, streaming SSR, React Server Components) traitées plus bas. ## Ce que Googlebot fait vraiment avec le JavaScript en 2026 Depuis mai 2019, Googlebot utilise un Chromium evergreen aligné sur la version stable de Chrome. Il peut donc exécuter à peu près tout ce qu'un Chrome utilisateur exécute. Mais entre « peut exécuter » et « exécute vite à chaque URL », il y a un gouffre. L'indexation d'une page JS passe par trois étapes : crawling, puis rendering (via le Web Rendering Service), puis indexing. Le rendering se fait dans une file d'attente séparée. Ahrefs a mesuré, sur des millions de pages, une **médiane de 5 secondes entre crawl et rendu, mais un 90e percentile en minutes**, avec un long tail en heures voire en jours pour les sites peu prioritaires. À cela s'ajoute une limite technique confirmée par Google en avril 2026 : **2 Mo maximum par URL fetchée** (64 Mo pour les PDF). Sur un site React lourd, ce plafond est plus proche qu'on ne l'imagine. La position officielle de Google en 2026 reste inchangée : « Server-side or pre-rendering is still a great idea ». Google gère le JavaScript, mais préfère ne pas avoir à le faire. **À retenir** Google indexe le JavaScript avec délai, avec un coût en crawl budget, et avec une limite de 2 Mo par URL. Un site CSR n'est pas invisible : il est retardé et fragile. Un site SSR ou SSG est prioritaire dans la file de crawl. ## L'angle mort majeur : les crawlers IA n'exécutent pas de JavaScript Google n'est plus le seul crawler qui compte. GPTBot (OpenAI), ClaudeBot (Anthropic) et PerplexityBot alimentent les réponses génératives que tes prospects lisent de plus en plus. Aucun de ces crawlers n'exécute de JavaScript en 2026. Concrètement : un site en CSR pur est **totalement invisible dans ChatGPT, Perplexity et Claude**. Tes concurrents en SSR ou SSG sont cités, pas toi. **Alerte** C'est l'enjeu SEO 2026 que la plupart des articles techniques FR ignorent encore. Un audit CSR doit maintenant se juger à deux critères : Google (rendu retardé) et IA (aveugle au JS). ## L'impact du CSR sur les Core Web Vitals et le crawl budget Trois effets mesurables, souvent sous-estimés : - **LCP dégradé de 30 à 60 %** vs SSR/SSG. La cause est mécanique : avant tout affichage, le navigateur télécharge le HTML puis le JS, parse, exécute, requête les API, construit le DOM, puis rend. Si le sujet t'intéresse, je détaille les leviers dans mon guide pour [améliorer la vitesse de chargement d'un site](/blog/ameliorer-vitesse-chargement-site/). - **INP à risque à cause de l'hydratation** ou de la reprise du contrôle par le JS après l'affichage. Sur un site React lourd, l'INP en rouge est souvent plus lié au mode de rendu qu'à un handler isolé. - **Crawl budget divisé.** Chaque page rendue par le WRS coûte plus cher qu'une page HTML statique. Sur un catalogue à 500 000 URL, un CSR mal fait décale l'indexation des contenus profonds de plusieurs semaines. Sur une base CSR lourde migrée vers du rendu serveur, les gains publics sur le LCP dépassent régulièrement les 50 %. C'est le levier technique le plus rentable sur ce profil. ## SSR : quand il est vraiment supérieur, et quand il ne l'est pas Le mythe le plus tenace en SEO technique : « le SSR est toujours mieux ». C'est faux, et cette croyance conduit à des architectures inutilement complexes. **Quand le SSR fait la différence** : pages fréquemment mises à jour (fiches produit avec stock temps réel, actualités), contenu personnalisé mais devant rester indexable, sites très volumineux où la pré-génération complète est impossible (marketplace à millions de pages). **Quand le SSR est un coût inutile** : SaaS derrière un login (aucun enjeu SEO), dashboard interne, application mobile hybride, ou blog et docs à contenu peu changeant (le SSG bat le SSR sur toutes les métriques utiles). **Alerte** Sur un site en streaming SSR (Next.js App Router avec Suspense), le TTFB devient une métrique trompeuse : le premier octet reçu peut n'être que le ``. Concentre-toi sur le LCP et l'INP, pas sur le TTFB seul. ## SSG et ISR : le meilleur rapport LCP/coût pour le contenu éditorial Sur le contenu éditorial (blog, docs, marketing, catalogue relativement stable), le statique bat le SSR. Du HTML servi par CDN donne : - Un TTFB souvent sous 100 ms globalement - Aucune charge serveur à la requête - Une résilience maximale (rien à exécuter, aucun risque d'erreur runtime) - Un LCP directement lié au poids de la page, pas au temps de calcul C'est le mode idéal pour tout site à contenu peu dynamique, ce qui couvre en pratique 70 % des projets web. L'ISR (Incremental Static Regeneration de Next.js, équivalent Nuxt 3 via `routeRules`) combine la vitesse du SSG et la fraîcheur du SSR. La page est servie depuis le cache statique. Après un délai configurable, elle est régénérée en arrière-plan pour la prochaine visite. **Astuce d'expert** Sur un e-commerce dont le catalogue change quelques fois par jour mais pas à chaque visite, l'ISR est presque toujours le bon défaut. Cache stable + régénération toutes les 60 minutes = LCP de CDN, catalogue à jour. ## React Server Components, Astro, Qwik : les paradigmes qui changent la donne Trois approches modernes vont plus loin que le simple SSR pour réduire la charge JS envoyée au navigateur. **React Server Components (RSC).** Des composants exécutés exclusivement côté serveur, jamais envoyés au client. Seuls le HTML rendu et les composants clients enfants transitent. Bundle client sensiblement réduit, gain LCP et INP dès la première release. C'est le modèle par défaut de Next.js 15 App Router. Sur un projet React moderne, s'en priver demande à être justifié. **Astro et les îlots.** HTML statique par défaut, hydratation ciblée uniquement sur les composants marqués `client:*`. Sur un blog ou une doc, le payload JavaScript descend souvent à quasi zéro. C'est mon défaut recommandé pour tout site content-first où l'interactivité reste limitée à quelques îlots. **Qwik et la resumability.** Plutôt que d'hydrater tout le HTML côté client, Qwik télécharge le JavaScript à la demande, uniquement à l'interaction. Un site Qwik n'envoie quasiment aucun JS de framework au premier chargement. Plus niche, mais différenciant sur les projets où la performance est critique dès la conception. ## Edge rendering : où le TTFB fait vraiment gagner du terrain Le rendu edge (Vercel Edge Functions, Cloudflare Workers, Netlify Edge Functions) exécute le rendu sur des serveurs proches du visiteur, plutôt que dans une région centrale. Les chiffres publiés par Vercel donnent un TTFB de **60 à 120 ms globalement** pour du rendu edge, contre **350 à 700 ms** pour un rendu serverless régional depuis une audience internationale. Sur une audience mondiale, cette différence de TTFB se traduit directement en LCP amélioré, donc en signal SEO positif. Sur une audience purement française avec un serveur en Europe, le gain reste marginal. ## Choisir son mode de rendu selon le type de site C'est la question qui décide vraiment ton architecture. Voici la matrice de décision que j'applique chez mes clients. | Type de site | Mode recommandé | Framework typique | | :---- | :---- | :---- | | Blog / média éditorial | SSG + ISR | Astro, Next.js App Router | | Site vitrine / marketing | SSG pur | Astro | | Documentation technique | SSG | Astro, Docusaurus, Nextra | | E-commerce catalogue (< 10 000 URL) | SSG + ISR | Next.js, Nuxt 3 | | E-commerce headless volumineux | SSR + ISR selon les pages | Next.js RSC | | Marketplace grande volumétrie | SSR + edge | Next.js Edge, Remix | | SaaS marketing (public) | SSG | Astro, Next.js | | SaaS applicatif (derrière login) | CSR | React, Vue, Angular | | Dashboard interne | CSR | React, Vue | | Landing page campagne | SSG | Astro, HTML pur | Règle métier : plus ton contenu est stable et destiné à être indexé, plus le SSG est adapté. Plus ton contenu est dynamique et non indexé, plus le CSR devient acceptable. Le SSR est le compromis quand aucun des extrêmes ne convient. **Astuce d'expert** Ne mélange pas ta stratégie de rendu entre gabarits. Un marketing en SSG et un blog en SSR sur le même Next.js, c'est un piège de maintenance. Choisis un mode dominant, puis ajoute des exceptions justifiées. ## Comment tester si Googlebot voit vraiment tes pages Trois vérifications concrètes. **Le test URL Inspection dans la Search Console.** Sur n'importe quelle URL, lance « Test Live URL ». Regarde le HTML rendu (bouton « View tested page > HTML »), le screenshot et la console JavaScript. Si le HTML rendu est vide ou tronqué là où ton contenu devrait apparaître, ton CSR pose problème. **Le test curl avec l'user-agent Googlebot.** ```bash curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://ton-url.com | less ``` Ce que tu vois ici, c'est ce que Googlebot reçoit avant l'exécution du JavaScript. Et surtout, c'est aussi ce que les crawlers IA voient définitivement. **Le test des liens injectés côté client.** Les liens créés par JavaScript après le rendu initial (routing SPA, lazy loading) sont indexés avec retard, parfois ignorés. Vérifie que tes liens de navigation principaux existent dans le HTML source, pas seulement après hydratation. **Astuce d'expert** La différence entre le HTML source (`view-source:` dans Chrome) et le HTML rendu (URL Inspection de la Search Console) est le premier diagnostic à faire sur un site JavaScript. Si les deux sont très différents, ton SEO dépend entièrement de la fiabilité du rendu Googlebot. ## Migration entre modes : ce que ça coûte vraiment Quatre configurations types : - **CSR vers SSG** : 4 à 12 semaines développeur. Faisable si ton contenu est stable. Meilleur rapport bénéfice/coût pour les sites éditoriaux. - **CSR vers SSR** : 3 à 6 mois. Refonte lourde qui demande de repenser toute la logique de fetch et l'authentification. - **Ajout d'un prerender externe** (Prerender.io, Rendertron) : solution de rattrapage rapide pour rendre un CSR indexable. Utile en transition, pas une cible long terme. - **Migration vers RSC** (Next.js App Router) : 2 à 6 mois. Rentable sur une base Next.js Pages Router qui montre ses limites, avec un gain LCP et INP significatif. ## Un audit de rendu SEO pour ton site Le choix d'un mode de rendu est une décision business qui engage ton architecture pour plusieurs années : coût d'infra, visibilité SEO, et de plus en plus visibilité dans les moteurs IA. Chez mes clients, je réalise cet arbitrage lors d'un audit SEO technique complet : test URL Inspection sur les gabarits critiques, analyse du HTML rendu vs HTML source, mesure des Core Web Vitals actuels, benchmark vs concurrents en SERP, et recommandation d'architecture cible avec estimation du coût de migration.