S

SSR (Server-Side Rendering)

Sans rendu serveur, votre page est invisible pour l'IA.

Définition

Le SSR (Server-Side Rendering) est le fait de générer le HTML d'une page côté serveur, de sorte que le contenu soit présent dès le premier fetch - sans dépendre de l'exécution du JavaScript côté client. Il s'oppose au rendu côté client (CSR), où le serveur envoie une coquille quasi vide que le navigateur remplit ensuite en exécutant du JS. Pour un humain équipé d'un navigateur moderne, la différence est invisible ; pour une machine qui n'exécute pas le JavaScript, elle est totale.

Pourquoi ça compte

Les agents IA - ChatGPT Search, Perplexity, Gemini, AI Mode - lisent le premier HTML renvoyé par le serveur et n'exécutent généralement pas le JavaScript. Conséquence directe : une SPA (application monopage) non rendue côté serveur leur apparaît comme une page vide. Le contenu existe pour le visiteur humain, mais n'entre jamais dans le corpus que les machines récupèrent : c'est la différence entre être citable et être ignoré. Le SSR est donc un prérequis de la couche découvrabilité - sans lui, tout le reste (répondabilité, blocs extractibles, données structurées) porte sur un contenu que l'IA ne voit pas. Le rendu serveur n'est plus un détail technique : c'est une condition d'existence dans l'IA.

Exemple concret

Un site vitrine élégant est bâti en pur rendu client : à l'ouverture, le navigateur d'un internaute exécute le JavaScript et affiche un beau contenu. Mais quand un crawler d'IA requête la même URL, il reçoit une coquille quasi vide - le contenu n'est injecté qu'après, par du JS qu'il n'exécute pas. Résultat : le site est superbe pour les humains et invisible pour l'IA, qui n'a jamais « vu » ses textes. En SSR, la même page aurait livré son contenu intégral dès la première réponse serveur.

SSR vs CSR

CritèreSSR (rendu serveur)CSR (rendu client)
Où le HTML est généréSur le serveur, avant l'envoiDans le navigateur, après exécution du JS
Contenu au premier fetchCompletQuasi vide
Lisibilité par les agents IAÉlevéeFaible à nulle
Risque pour la découvrabilitéFaibleÉlevé

Comment l'optimiser

  • Servir le contenu essentiel en SSR : titres, texte, liens et données structurées présents dans la réponse initiale du serveur.
  • Vérifier le premier HTML : afficher le code source brut (ou désactiver le JS) pour voir ce qu'une machine récupère réellement.
  • Envisager le pré-rendu / rendu statique pour les contenus stables (articles, fiches), qui n'ont pas besoin d'être recalculés à chaque visite.
  • Ne rien réserver au client : tout ce qui n'apparaît qu'après exécution du JS est invisible aux crawlers qui ne l'exécutent pas.

Erreurs fréquentes

  • Bâtir une SPA en pur rendu client et s'étonner de n'être ni indexé ni cité par les IA.
  • Tester son site uniquement dans un navigateur (qui exécute le JS) et conclure à tort que « tout s'affiche ».
  • Charger le contenu principal après coup, en JavaScript, en le rendant inaccessible aux machines.
  • Confondre rapidité d'affichage et lisibilité machine : une page peut sembler rapide à l'œil et rester vide pour un crawler.

Termes liés

FAQ

Le SSR est-il obligatoire pour être visible par les IA ? Pas strictement, mais c'est le moyen le plus sûr de garantir que votre contenu est récupérable. Les agents IA lisent le premier HTML et n'exécutent généralement pas le JavaScript - le SSR supprime le risque d'être invisible.

SSR ou site statique, quelle différence ? Le SSR génère le HTML à la demande, côté serveur ; le rendu statique le génère une fois à l'avance. Les deux livrent un contenu complet dès le premier fetch ; pour des pages stables comme un glossaire, le statique est souvent suffisant et plus économe.

Comment savoir si mon site est en SSR ? Affichez le code source brut de la page (ou désactivez le JavaScript) : si le texte de votre contenu y figure déjà, il est rendu côté serveur. S'il manque et n'apparaît qu'à l'écran, il est injecté côté client - donc invisible pour la plupart des agents.