SSR, SSG ou CSR : quel mode de rendu choisir pour bien référencer son site ?

Rendu côté serveur, génération statique, rendu côté navigateur : ce que ces sigles changent pour Google, pour les IA et pour la vitesse de votre site, expliqué simplement.

Par Léo Chuzel · Publié le 16 octobre 2026 · 4 min de lecture

Votre prestataire vous parle de React, de Next.js, de « SSR » ou de « site statique » et vous décrochez ? C’est normal : ce sont des choix techniques. Mais ils ont une conséquence très concrète sur votre business : Google et les assistants IA voient-ils réellement le contenu de votre site ? Cet article vous donne les clés pour comprendre et poser les bonnes questions.

Le problème : une page qui se construit dans le navigateur

Un site classique envoie au visiteur une page HTML complète : textes, titres, liens, tout est déjà là. Beaucoup de sites modernes fonctionnent autrement. Le serveur envoie une page presque vide et un gros fichier JavaScript, puis c’est le navigateur qui fabrique la page. On parle de rendu côté client, ou CSR (Client-Side Rendering).

Pour un humain équipé d’un téléphone récent, la différence se voit à peine. Pour un robot, c’est une autre histoire : s’il n’exécute pas le JavaScript, il trouve une page blanche.

Les quatre modes de rendu en clair

CSR : rendu côté client

La page est construite par le navigateur. C’est le fonctionnement par défaut d’une application React ou Vue « simple ». Idéal pour un espace client ou un outil derrière une connexion, beaucoup moins pour des pages que vous voulez voir sur Google.

SSR : rendu côté serveur

Le serveur construit la page complète à chaque visite, puis l’envoie. Le contenu est immédiatement lisible par tous les robots. Utile pour des pages qui changent en permanence : stock, prix, disponibilités.

SSG : génération statique

Les pages sont fabriquées une seule fois, au moment de la publication, puis servies telles quelles. C’est le plus rapide et le plus robuste : pas de calcul à chaque visite, un hébergement simple, une sécurité renforcée. Parfait pour un site vitrine, un blog ou des pages de services.

ISR et rendu hybride

Les frameworks modernes comme Next.js permettent de mélanger : pages statiques régénérées automatiquement quand le contenu change (ISR), pages serveur pour le dynamique, et JavaScript côté client uniquement là où il y a de l’interaction. C’est aujourd’hui la meilleure approche pour la plupart des projets.

Google sait lire le JavaScript… avec des limites

Google exécute le JavaScript, mais en deux temps : il explore d’abord le HTML brut, puis place la page dans une file d’attente pour la « rendre ». Ce délai peut ralentir l’indexation de vos nouvelles pages, et toute erreur JavaScript peut faire disparaître du contenu. Les liens générés uniquement en JavaScript, sans vraie balise de lien, sont parfois ignorés.

L’impact sur la vitesse

Le rendu côté client oblige le téléphone du visiteur à télécharger et exécuter beaucoup de code avant d’afficher quoi que ce soit. Résultat : un premier affichage plus lent et des indicateurs Core Web Vitals dégradés. Une page statique ou rendue côté serveur s’affiche presque instantanément.

Comment vérifier votre site en deux minutes

Ouvrez votre site, faites un clic droit puis « Afficher le code source de la page ».
Cherchez (Ctrl+F ou Cmd+F) une phrase visible à l’écran, par exemple votre titre principal.
Si la phrase est présente dans le code source, le contenu est servi en HTML : c’est bon signe.
Si vous ne voyez qu’une structure vide et des scripts, votre contenu dépend du JavaScript.
Pour confirmer, utilisez l’outil d’inspection d’URL de la Google Search Console et consultez la page telle que Google l’a rendue.

Que choisir pour votre projet ?

Site vitrine, blog, pages de services : génération statique, avec régénération quand vous modifiez un contenu.
Boutique en ligne : pages produits statiques ou serveur, panier et compte client dynamiques. C’est le principe d’une boutique Shopify headless.
Espace client, back-office, outil métier : le rendu côté client convient très bien, puisque ces pages n’ont pas vocation à être sur Google.
Application mobile : le sujet est différent, voir notre article application mobile ou PWA.

Notre approche

Chez SOBO, nous développons nos sites avec Next.js en privilégiant la génération statique : chaque page arrive complète chez le visiteur et chez les robots, puis l’interactivité s’ajoute là où elle est utile. C’est ce qui nous permet de livrer des sites à la fois rapides, faciles à référencer et lisibles par les IA. Si vous avez un doute sur votre site actuel, nous le vérifions gratuitement lors de notre audit, et nous pouvons vous accompagner dans sa refonte.