En bref. Le rendu côté serveur génère le HTML à la demande pour que le contenu de la page soit disponible avant l’exécution des scripts du navigateur.

Définition : Le rendu côté serveur (server-side rendering, SSR) génère le HTML d’une page sur le serveur en réponse à une demande de navigation. La réponse contient le contenu effectif de la page, qu’un navigateur ou un robot d’exploration peut lire avant l’exécution des scripts du navigateur.

Points clés

En octobre 2026, la documentation de Google sur le SEO JavaScript distingue les réponses produites par un rendu côté serveur, qui contiennent le contenu de la page, du squelette d’application (app shell), dont le contenu nécessite l’exécution de JavaScript.
Le guide web.dev de Google, Rendering on the Web, décrit le rendu côté serveur comme une production de HTML à la demande et le rendu statique comme une production de HTML au moment de la compilation (build).
La documentation de référence de React sur hydrateRoot décrit l’hydratation comme le rattachement de la logique de l’application au HTML déjà généré sur le serveur.
Le guide de dépannage JavaScript de Google recommande le test des résultats enrichis (Rich Results Test) ou l’outil d’inspection d’URL de la Search Console (URL Inspection Tool) pour examiner la manière dont Google explore une URL et en effectue le rendu.

Quel contenu arrive avant l’exécution de JavaScript ?

Une réponse HTML est le document renvoyé par le serveur à la suite d’une requête de page. Dans le guide de Google sur le SEO JavaScript, le contenu des pages rendues côté serveur figure dans cette réponse. Un squelette d’application fournit un document initial qui nécessite des scripts pour générer le contenu effectif de la page.

L’extrait HTML suivant provient de l’exemple du guide consacré à l’API History, qui montre la navigation entre les URL de pages :

<h1>Welcome to example.com!</h1>
<div id="placeholder">
  <p>Learn more about <a href="/products">our products</a> and <a href="/services">our services</a></p>
</div>

Le titre, le paragraphe et les destinations des liens figurent déjà dans le HTML. Google décrit l’extraction des destinations des liens à partir des attributs href de la réponse, puis une nouvelle analyse des liens après le rendu. Fournir le texte et les liens dans la réponse rend ce contenu disponible dès l’analyse initiale.

Le rendu côté serveur s’inscrit dans le processus de rendu de Google. Le même guide indique que les pages renvoyant un statut HTTP 200 entrent dans la file d’attente de rendu, sauf si une balise meta robots ou un en-tête demande à Google de ne pas les indexer. Google utilise le HTML après rendu pour indexer la page. Le SSR intervient donc dans la manière dont le contenu parvient à Google au sein de ce processus.

En quoi la génération statique et l’hydratation diffèrent-elles ?

La génération de sites statiques produit le HTML avant les requêtes, lors d’une compilation. Le guide de web.dev sur le rendu la distingue de la génération à la demande du SSR. Les deux approches peuvent fournir le contenu dans la réponse HTML. Le guide présente l’accès à des données en temps réel et la personnalisation comme des raisons de générer les pages à la demande, tout en précisant que les calculs sur le serveur prennent du temps et peuvent retarder l’arrivée du premier octet de la réponse.

L’hydratation exécute des scripts dans le navigateur pour ajouter des comportements au HTML existant, rendu côté serveur. Dans la documentation de React, hydrateRoot rattache la logique des composants à ce HTML et rend l’application interactive. React attend du rendu initial dans le navigateur qu’il corresponde au résultat produit par le serveur et considère les écarts comme des bugs.

Le contenu visible et les interactions fonctionnelles peuvent donc devenir disponibles à des moments différents. Le guide de web.dev explique qu’une page rendue côté serveur avec hydratation peut sembler prête alors que ses commandes attendent encore les scripts du navigateur et les gestionnaires d’événements.

Comment vérifier le contenu transmis ?

Un contrôle pratique consiste à comparer la réponse HTML à la page après rendu. La réponse permet d’établir quels textes et liens arrivent avant l’exécution des scripts. Google recommande le rendu côté serveur ou le prérendu notamment parce que certains robots ne peuvent pas exécuter JavaScript, selon ses recommandations sur le SEO JavaScript.

Pour Google en particulier, sa documentation de dépannage oriente les personnes chargées du contrôle vers le test des résultats enrichis ou l’outil d’inspection d’URL. Ces outils affichent le contenu après rendu, les ressources chargées et les erreurs JavaScript. Comparer la réponse à ce résultat aide à repérer le contenu fourni uniquement par les scripts et les défaillances qui affectent le rendu.

Termes associés

Questions fréquentes

Une page rendue côté serveur peut-elle aussi utiliser JavaScript ?

Oui. La documentation de React sur l’hydratation explique comment les scripts du navigateur rattachent la logique des composants au HTML généré par le serveur. Vous pouvez recevoir un contenu lisible avant que l’application ne devienne interactive.

La génération de sites statiques fournit-elle aussi le contenu en HTML ?

Oui. Le guide de web.dev décrit la création à l’avance d’un fichier HTML pour chaque URL. Vous recevez du HTML déjà produit au lieu d’attendre que la page soit générée à la demande.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Rendu côté serveur