SSR SEO : le rendu côté serveur peut rendre le contenu accessible dans le HTML initial, mais il ne garantit ni l’indexation ni un meilleur classement. Pour choisir entre SPA, CSR, SSR et SSG, il faut distinguer la navigation, le mode de rendu et le rôle de chaque page.
Votre application comporte des pages publiques et un espace client connecté. Les premières doivent être découvertes et comprises depuis un moteur de recherche. Le second sert surtout à consulter des données personnelles et à effectuer des actions.
Décidez page par page. Un article, une fiche produit et un tableau de bord n’ont ni les mêmes besoins de fraîcheur, ni les mêmes contraintes d’accès.
SPA, CSR, SSR et SSG : quatre notions distinctes
Une SPA, ou Single Page Application, change de vue sans recharger un document HTML complet à chaque navigation. Elle peut recevoir une première page rendue sur le serveur. Opposer systématiquement « SPA ou SSR » mélange donc deux décisions.
| Notion | Ce qu’elle décrit | Conséquence à examiner |
|---|---|---|
| SPA | Navigation gérée dans l’application après le chargement initial | Accès direct aux URL et comportement des transitions |
| CSR | Contenu construit dans le navigateur avec JavaScript | Dépendance au chargement du code et des données |
| SSR | HTML généré côté serveur à la demande | Temps serveur, disponibilité des données et cache |
| SSG | HTML généré à l’avance | Délai de mise à jour du contenu et régénération |
Le SSR et le SSG peuvent ensuite être complétés par du JavaScript pour les interactions. L’hydratation relie alors le comportement interactif au HTML déjà présent. La présentation des modes de rendu par web.dev détaille leurs compromis.
Une page visible n’est donc pas forcément entièrement interactive. Inversement, une SPA ne commence pas nécessairement par un écran vide.
SSR et SEO : ce que Google peut réellement lire
Google peut exécuter JavaScript. Sa documentation distingue exploration, rendu et indexation : une page en CSR n’est pas automatiquement invisible. Le rendu peut toutefois attendre, et une erreur JavaScript ou une ressource bloquée peut empêcher l’accès au contenu attendu.
Google recommande le rendu serveur ou le prérendu, notamment parce que tous les robots ne savent pas exécuter JavaScript. Le guide JavaScript SEO de Google Search Central explique ces limites.
Le bénéfice recherché est concret : fournir le titre, le texte principal et les liens sans dépendre de leur construction dans le navigateur. Cela facilite l’accès au contenu, sans décider de son indexation.
Une fiche produit en SSR peut rester exclue si elle porte une directive noindex. Une page accessible peut aussi apporter trop peu de valeur pour être retenue. Changer de rendu ne corrige pas à lui seul le contenu, le maillage ou les doublons.
Quel rendu choisir selon la page ?
Pour un article ou une page service qui évolue peu, commencez par examiner le SSG. Le HTML peut être servi depuis un cache sans reconstruire la page à chaque visite. Prévoyez une régénération lorsque le contenu change.
Pour une page publique dont les données doivent être calculées à la demande, le SSR mérite d’être étudié. Définissez toutefois la fraîcheur réellement nécessaire : un descriptif et une disponibilité ne doivent pas forcément suivre la même stratégie.
Pour un tableau de bord privé, le CSR peut convenir : son contenu n’a pas vocation à apparaître dans Google. Le chargement initial, l’accessibilité et la gestion des erreurs restent des exigences produit. L’absence d’enjeu SEO ne justifie pas une interface lente.
Dans un projet de développement SaaS, on peut ainsi prérendre les pages d’acquisition et charger les données personnelles après connexion. La frontière public/privé doit rester explicite, notamment dans la gestion du cache.
Le SSR ne garantit pas la performance
Le SSR déplace une partie du travail vers le serveur. Si celui-ci attend une requête lente avant d’envoyer le contenu, l’utilisateur attend aussi. Le cache peut aider, à condition de maîtriser la fraîcheur des données et de ne pas partager une réponse personnelle entre utilisateurs.
Le navigateur doit encore traiter les styles, les images et le JavaScript nécessaire. Un HTML disponible tôt peut donc coexister avec des interactions tardives. web.dev souligne notamment le coût du JavaScript et de l’hydratation dans les compromis de rendu.
Mesurez le délai de réponse serveur, l’affichage du contenu principal et la réactivité sur les parcours importants. Comparez les mêmes pages, appareils et conditions réseau. Aucun gain de conversion ne peut être déduit du seul passage au SSR.
Vérifier une page avant de changer d’architecture
- Ouvrez directement son URL : elle doit fonctionner sans passer par la page d’accueil.
- Inspectez le HTML reçu : le contenu public essentiel est-il présent avant l’exécution de JavaScript ?
- Contrôlez les signaux techniques : statut HTTP, directives d’indexation, URL canonique et liens explorables.
- Utilisez l’inspection d’URL de Search Console : examinez le rendu testé et les ressources qui n’ont pas pu être chargées.
- Vérifiez le parcours réel : contenu affiché, interactions et gestion d’une erreur réseau sur mobile.
Ces vérifications servent à localiser le problème. Si le texte apparaît correctement mais que la page ne répond pas à la recherche, une migration SSR ne remplace pas le travail éditorial. Si le contenu manque dans le rendu, corrigez d’abord la cause observée.
Ce qu’il faut retenir
Le SSR SEO consiste à réduire la dépendance au rendu JavaScript pour accéder au contenu public. Le SSG peut répondre au même besoin lorsque le HTML peut être préparé à l’avance. Aucun de ces choix ne garantit un classement.
SPA décrit la navigation, tandis que CSR, SSR et SSG décrivent la production du contenu. Une application peut combiner ces approches selon la fraîcheur des données, les usages et les contraintes de chaque page.
Questions fréquentes
Une SPA peut-elle être référencée ?
Oui, si ses pages sont explorables et si leur contenu est accessible au moteur. Une SPA peut aussi utiliser le SSR pour son chargement initial. Le mot SPA ne suffit pas à diagnostiquer un problème SEO.
Faut-il du SSR pour un blog ?
Pas nécessairement. Le SSG fournit également du HTML préparé et convient à des articles dont les changements peuvent déclencher une régénération.
Le test en direct de Search Console garantit-il l’indexation ?
Non. Il aide à examiner l’accessibilité et le rendu de la page au moment du test. L’indexation reste une étape distincte.
Conclusion
Choisissez le mode de rendu selon le rôle de la page et le problème mesuré. Pour le SEO, commencez par vérifier ce que le moteur peut lire avant d’engager une refonte.
Pour examiner le rendu de votre application et les options utiles, réservez un échange de 30 minutes.