SSR vs CSR en SEO : ce que Google voit et comment tester le HTML rendu

Avec le server-side rendering (SSR), le serveur fabrique le HTML à chaque requête. Avec le client-side rendering (CSR), le navigateur reçoit une coque HTML et du JavaScript, récupère les données puis construit l’écran. Le static site generation (SSG) produit le HTML à l’avance. Les frameworks hybrides mélangent ces modes selon les routes, parfois selon les composants.

L’hydratation rend ensuite le HTML serveur interactif dans le navigateur. Une page peut donc livrer un HTML complet pour la découverte tout en se comportant comme une application moderne. « SSR » ne veut pas dire « sans JavaScript ».

Google documente trois grandes phases pour les pages JavaScript : crawl, rendu et indexation. Il reçoit d’abord la réponse HTTP et analyse le HTML disponible, puis place la page dans une file de rendu Chromium avant d’analyser le HTML rendu. Google peut donc voir le contenu client, mais ce contenu doit survivre à une chaîne de dépendances supplémentaire.

La conclusion honnête n’est pas « Google ne lit pas JavaScript ». C’est : « le contenu important ne devrait pas disparaître parce qu’une API, un bundle, un consent manager, un lazy-loader, une interaction ou une erreur runtime a échoué ». Google recommande d’ailleurs SSR, rendu statique ou hydratation plutôt que le dynamic rendering comme solution durable.

Le mode de rendu n’est pas un facteur de classement en soi. C’est le résultat qui compte. Une page CSR devient risquée lorsque sa réponse initiale est presque vide et que le résultat dépend de nombreuses ressources, ou lorsque source et DOM vivant envoient des consignes contradictoires.

Contrôlez ce qui décide de la découverte et de l’interprétation : contenu principal, H1, liens explorables, title et description, robots, canonical, hreflang, données structurées, disponibilité produit, pagination et contenu derrière accordéons ou consentement. Une page jolie une fois chargée ne prouve pas que chaque robot a reçu le même document utile.

Pour les landing pages, articles, catégories et fiches produit publiques et indexables, SSR ou SSG constitue généralement le défaut le plus sûr pour le contenu utile et les directives SEO. Le CSR reste excellent pour dashboards, filtres, vues authentifiées, calculateurs et interactions dont l’état n’a pas besoin d’une URL indexable.

La plupart des équipes n’ont pas besoin de réécrire toute l’application. Commencez par rendre côté serveur le shell, les metas, le contenu principal, la navigation et les liens canoniques. Hydratez ensuite les îlots interactifs. C’est moins spectaculaire qu’un manifeste de rendu, mais beaucoup plus utile en production.

La source brute montre ce que le serveur a livré. Le DOM rendu montre ce qui existe après JavaScript. Le rendu sans JS montre ce qui reste lorsque l’exécution client disparaît. Il faut les trois, car chacun répond à une question différente.

Ne paniquez pas parce que 41 % des lignes diffèrent. Un bandeau de consentement peut produire beaucoup de bruit ; un seul lien interne absent peut compter davantage. Recherchez dans le diff les entités et directives importantes, puis confirmez l’URL finale dans l’Inspection d’URL de Search Console si vous contrôlez le site.