Le sujet du SSR (Server-Side Rendering) est, dans le référencement naturel, intimement lié aux problématiques de JavaScript SEO . Il s’agit, en clair, de s’assurer que les contenus rendus côté serveur soient bien accessibles, interprétables et indexables par les moteurs de recherche.
Et ce qui valait hier pour Google vaut encore plus aujourd’hui pour les moteurs génératifs. Car si une IA ne voit pas le contenu… elle ne pourra pas le reprendre. C’est d’ailleurs l’un des points que j’aborde en détail dans mon guide sur la Generative Engine Optimization (GEO) , qui explore comment rendre un contenu lisible et réutilisable par des systèmes comme ChatGPT Search, Perplexity ou SGE.
Cela fait depuis 2017 que je suis traumatisé travaille sur des sites en Javascript afin d’améliorer leur référencement naturel. J’ai d’ailleurs été un des premiers en France à créer un guide pour analyser, tester et améliorer l’indexation d’un site sous Javascript.
L’objectif de cet article “de niche” si je peux me permettre l’expression, est de vous apporter des réponses sur plusieurs éléments, que vous soyez un professionnel du marketing ou un développeur avec une sensibilité au référencement naturel . Ainsi, je vais aborder les points suivants :
Expliquer très simplement ce qu’est le SSR ; Pourquoi considérer cette solution en SEO ; Quelle solution choisir entre SSR et CSR ; Les autres alternatives au SSR qui sont compatibles avec le SEO ; Puis vous donner une version longue et plus complète pour les personnes qui aiment bien comprendre les tenants et aboutissants. Qu’est-ce que le SSR en SEO ? La version simple Lorsqu’un internaute clique sur un lien (depuis les SERPs ou depuis un autre site), mais c’est vrai aussi avec un robot d’exploration dont Googlebot, il se passe les actions suivantes (version simple) :
Le serveur reçoit la requête ; Il vérifie que le user agent n’est pas bloqué par le robots.txt ; Si le user agent n’est pas bloqué, le serveur cherche la ressource (la page si vous préférez) à envoyer au client client pouvant être le navigateur d’un internaute ou un crawler - ; Il génère alors le code HTML du document ; Puis envoie le document HTML complet au client . L’ “effort” principal est l’étape 4 ci-dessus durant laquelle la “gymnastique” est réalisée par le serveur. Le fait que cette “gymnastique” de génération du fichier HTML soit faite côté serveur fait qu’on peut parler de SSR (Server-Side Rendering ) .
Ainsi, le client (navigateur ou robot d’exploration) reçoit un fichier HTML déjà complet et structuré .
Quel est le lien entre SSR et SEO ? Pour une raison très simple et très basique qui n’est autre que la facture d’électricité de Google. Je m’explique.
Tout d’abord, il faut comprendre comment le processus d’exploration et d’indexation fonctionne chez Google.
Quand Google envoie une requête à un serveur, s’il n’est pas bloqué par le fichier robots.txt, il reçoit en échange des fichiers de format HTML, CSS, et JS.
Si votre site est sous PHP (comme un bon vieux Wordpress), Google reçoit un fichier HTML exhaustif et explicite où votre contenu principal est bien présent et qu’il comprendra parfaitement ; Si votre site est sous Javascript avec un rendering côté client , Google reçoit un fichier HTML très léger et peu explicite ainsi qu’un fichier JS volumineux. Dans ce second cas, celui du site en Javascript en CSR, la gymnastique est alors déportée sur Google. C’est à dire :
Googlebot récupère le HTML et le JS ; Il l’envoie à un autre “programme” de Google qu’on appelle le WRS (Web Rendering Service ) ; Le WRS exécute je Javascript ; Le WRS ensuite re-génère le fichier HTML et obtient cette fois un fichier plus exhaustif et explicite ; Google peut alors décider (ou non) d’indexer votre page et fournit au Googlebot les liens internes et externes qu’il a extrait du fichier. Il y a donc plus d’étapes lorsqu’un site est en Javascript avec Client-Side Rendering (CSR).
Mais qui dit plus d’étapes dit plus d’efforts.
Qui dit plus d’efforts dit plus de ressources consommées du côté de Google pour “comprendre” votre site par rapport au Wordpress de votre concurrent.
Qui dit plus d’efforts dit une plus grosse facture d’électricité. Bien que cela ne pose pas de problèmes à votre navigateur, à l’échelle du web mondial que Google cherche à explorer, ça en devient un.
Donc, un site internet render en client-side (CSR) n’est pas une bonne chose pour Google puisque pour l’interpréter, cela consomme plus de ressources . Google dédiant à chaque domaine une capacité maximum (qui se reflète dans le crawl budget ), s’il consomme trop de ces capacités à l’exécution de votre JS, il reviendra vous voir moins souvent.
Et ensuite, même pour vous en tant que SEO, ce n’est pas non plus nécessairement une bonne chose car l’exécution du JS par Google est plus prône à l’erreur que s’il récupère déjà un fichier HTML complet et explicite .
Nota Bene : j’entends par “explicite” que le cœur de votre contenu est inclus dans le fichier.
Javascript SEO : SSR vs CSR ? Si j’ai été bien clair ci-dessus, dans le cas où vous opposeriez le SSR versus le CSR pour un site utilisant un framework en JS, vous comprendrez que le CSR demande plus d’efforts aux outils de Google pour “analyser” et “comprendre” votre page .
Alors que dans le cas du SSR, cet effort est porté par le serveu r. Ainsi, si la question se pose entre le SSR et le CSR, je vous conseille fortement le SSR (ou SSG mais j’explique la subtilité plus bas).
SSR, SSG, SSR avec hydration , pre-rendering , dynamic rendering , hybrid rendering et CSR : la version longue et les abus de langage Maintenant que nous avons abordé la version 'simple' du SSR pour le SEO, je me permets cette partie plus détaillée si vous souhaitez comprendre ce principe de rendering en profondeur et/ou si vous êtes développeur .
Tout d’abord, côté Javascript SEO, on a tendance à opposer le SSR au CSR comme s’il n’y avait que deux choix. Et on se retrouve à parler de SSR alors qu’on parle de SSG par exemple. Ce qui, pour un marketeur, n’est qu’une “nuance” peut néanmoins être pour le développeur une vision technique drastiquement différente.
Ainsi, commençons par définir clairement les termes.
Avant toute chose, j'appelle web app toute plateforme web destinée à un utilisateur final que ce soit un blog, un site e-commerce, ou même un SaaS.
Définition du SSR Comme je l’expliquais plus haut, un client (le navigateur d’un internaute, un crawler ) envoie une requête à un serveur. Ensuite, le serveur génère tout le HTML de la ressource demandée et l’envoie enfin en réponse au client .
Avantages du SSR : Comme le serveur gère le rendering (on parle d’ailleurs de pre-rendering des pages), le fichier envoyé au client est composé de peu de Javascript , permettant ainsi :
Un fichier HTML explicite et exhaustif, plus facile à interpréter par des indexers de moteurs de recherche ; Puisqu’il y a peu de Javascript, le client a moins de “gymnastique” à faire pour afficher le cœur du contenu (First Contentful Paint (FCP)), permettant à l’utilisateur d’accéder et d’interagir avec le contenu plus rapidement ; C’est une méthode ancienne et établie, donc bien documentée . Par exemple, Wordpress fonctionne selon le principe du SSR . Lorsqu'une requête est reçue par le serveur, WordPress génère le contenu HTML sur le serveur en utilisant PHP et une base de données (MySQL). Ensuite, le fichier HTML correspondant à la page est renvoyé au client.
Définition de l’hydration (ou SSR avec hydration ) Alors, l’hydration (hydratation en Français) est un mélange de SSR et de CSR sans pour autant être de l’hybrid rendering que je vais définir après.
Pour être clair, je vais dérouler étape par étape :
Le serveur reçoit une requête depuis un client ; Le serveur génère le document HTML complet de la page demandée (comme pour la méthode de SSR); Le serveur envoie ce document au client ; Le client reçoit le document HTML et exécute le Javascript à la recherche d’event listeners et initialiser la web app . Une fois la web app initialisée, l’interface devient alors interactive pour l’internaute. L’hydration consiste à avoir des pages pre-rendered côté serveur au moment de la requête (comme un SSR classique). La différence majeure est que la page requiert l’exécution du Javascript pour devenir interactive. Cette méthode est utilisée par Next.js sur React.
Avantages du SSR avec hydration : C’est intéressant si vous avez besoin d’avoir une web app interactive et souvent en terme de performance.
Définition du SSG (Static Site Generation ) Le SSG , parfois appelé static rendering, pre-rendering at build time . Une fois ces fichiers HTML générés, ils sont stockés sur un serveur.
En d’autres termes :
Développement : construction de la web app par vous-même ou vos équipes de développement ; Compilation : au moment de “publier”, le Static Site Generator s’active et génère les fichiers HTML statiques correspondant notamment aux pages ; Déploiement : les fichiers statiques sont déployés sur votre serveur voire aussi sur un CDN ; Service : lorsque votre serveur reçoit une requête, il envoie immédiatement le fichier statique HTML. Avantages du SSG : Principalement la performance ; puisque le HTML est déjà généré, le serveur peut répondre à une requête bien plus rapidement ; Ensuite, puisque votre serveur n’a pas à générer le HTML à chaque requête, cela consomme moins de ressources. Netlify ou encore le CMS Webflow utilisent du SSG.
Définition du pre-rendering Le pre-rendering consiste en fait à générer le document HTML des pages web avant qu’il ne soit envoyé à l’utilisateur (client). Ce document peut être généré lors de la réception de la requête par le serveur (comme pour le SSR et le SSR avec hydration) ou lors de la compilation de la web app (comme pour le SSG).
Définition du dynamic rendering Le dynamic rendering était une solution plébiscitée par Google jusqu’en 2022. Elle consistait tout simplement à avoir deux versions de votre web app et à servir la version la plus à même d’être comprise par le client .
Par exemple, si la requête provenait d’un internaute (identifiable par son user agent ), vous pouviez lui envoyer l’application en CSR puisque c’est son navigateur qui ferait le travail de rendering . A l’inverse, si vous identifiez le user agent d’un crawler tel que le Googlebot, vous pouviez envoyer une version pre-rendered de votre web app .
Je mets tout au passé car comme vous pouvez le voir ci-dessous, Google ne conseille plus cette solution depuis fin 2022 et tend à recommander le SSR, SSG, ou l’hydration.
Source : le guide du dynamic rendering par Google Définition de l’hybrid rendering L’hybrid rendering comme son nom l’indique, est hybride. C’est-à-dire qu’il combine différentes méthodes de rendering selon ce que votre équipe technique décide, en fonction des contraintes imposées par les frameworks.
Veillez à toujours avoir une cohérence entre ce que vous servez en SSR et en CSR. C’est-à-dire que le CSR ne doit pas altérer des éléments clés tels que la balise titre . La règle d'or étant de ne jamais modifier le DOM .
Définition du CSR Vous l’aurez compris avant, mais le client-side rendering client . Dans le cas d’un internaute qui souhaiterait visiter une page, c’est son navigateur qui s’occuperait de cette génération et non un serveur.
Ce n’est pas une solution viable en SEO comme expliqué plus haut.
Les solutions selon les frameworks javascript Comme vous le savez peut-être, il existe des frameworks qui permettent de bénéficier du pre-rendering afin de faciliter le travail des moteurs de recherche pour comprendre un site construit en Javascript. Je vous mets ci-dessous un tableau qui reprend les principaux frameworks et qui j’espère vous sera utile.
Framework
SSR
SSR avec hydration
SSG
Next.js (React)
Oui (fonctionnalité principale)
Oui
Oui (avec ISR)
Gatsby (React)
Non (axé sur le SSG)
Non
Oui (fonctionnalité principale)
Nuxt.js (Vue)
Oui
Oui
Oui
Angular Universal (Angular)
Oui
Oui
Support Limité
Astro
Oui (approche flexible)
Oui
Oui
Remix
Oui
Oui
Oui
En résumé Il est courant que lors du développement d’une web app en Javascript, la question du rendering se pose pour vos pages. Mais qu’est-ce que le rendering ? Le rendering est l’étape à laquelle un fichier HTML est généré.
Quand cela se passe côté client (navigateurs de vos utilisateurs par exemple), nous parlons de Client-Side Rendering (CSR). Cela signifie que le serveur qui reçoit votre requête pour visualiser une page envoie l’intégralité des documents à votre navigateur et c’est ce dernier qui se charge d’exécuter l’intégralité du Javascript afin de générer le fichier HTML et de rendre le contenu de la page visible, lisible et interactif.
Quand cela se passe côté serveur, nous parlons de Server-Side Rendering (SSR). Cela signifie que lorsque le serveur reçoit une requête, il s’occupe d’abord de générer un fichier HTML complet avant de renvoyer le fichier au client . Ainsi, le “gros de l’effort” est porté sur le serveur et non sur le client .
Maintenant, pourquoi est-ce important en SEO ? Un site construit en Javascript avec un rendering côté client exige que Google exécute le Javascript afin d’accéder à l’entièreté du contenu et des liens contenus dans un document. Malheureusement, cela compliqué la tâche de Google car cela requiert (1) l’intervention d’une brique supplémentaire appelée Web Rendering Service , (2) cela requiert plus de ressources et enfin (3) il est possible que la manière dont Google exécute votre Javascript génère des erreurs.
Ce sont pour ces trois raisons qu’il est plus que recommandé de favoriser l’utilisation du SSR.
Alors, si vous lisez l’article vous comprendrez qu’il n’y a pas qu’une unique méthode de SSR mais qu’il en existe plusieurs avec des implications sur la performance de chargement, l’expérience utilisateur, et la complexité technique. Cela relève d’un arbitrage à faire avec votre équipe technique et selon vos objectifs et enjeux ; par exemple, une web app accessible uniquement aux personnes connectées (comme pour un SaaS) ne requiert aucunement du SSR puisque la performance SEO ne compte pas.
Si je peux me permettre un conseil, je conseille très fortement les équipes techniques et les marketeurs (et plus particulièrement l’expert SEO s’il existe) d’échanger en amont du développement d’un nouveau site web vitrine qui serait dédié à l’acquisition et la brand awareness . Cela vous aidera à anticiper les différents problèmes et ça évitera de voir des entreprises mettre la clé sous la porte à cause d’un simple sujet de rendering (déjà vu).
N’hésitez pas à commenter ci-dessous pour apporter des éléments complémentaires, rectificatifs ou poser vos questions.
Vous pouvez consulter aussi mes autres articles sur le Javascript SEO :
Partagez votre avis, vos questions, vos recommandations ci-dessous