Le brief arrive avec la solution déjà choisie : « il faut du rendu côté serveur, pour le SEO. » L'intuition est généralement bonne et la consigne mauvaise, et si un développeur l'applique à la lettre, vous paierez pour de la puissance serveur dont vous n'aviez aucun besoin.

La stratégie de rendu fait partie des rares décisions d'un projet web réellement difficiles à défaire. Elle mérite dix minutes de réflexion avant de devenir un ticket.

Ce dont un robot d'IA a réellement besoin

Partons du besoin plutôt que de la technologie, car ce besoin est plus étroit qu'on ne l'imagine.

Un robot d'IA a besoin que le contenu existe dans la réponse HTML. C'est toute la spécification. Il n'a pas besoin que le contenu soit frais, puisqu'il ne repassera pas cet après-midi. Il n'a pas besoin de personnalisation, puisqu'il n'a pas de session. Il n'a aucun besoin d'interactivité.

Le point est important, car l'argument classique en faveur du rendu serveur repose sur la fraîcheur et la personnalisation à chaque requête, et ni l'une ni l'autre n'entre en jeu ici. Comme traité dans l'article de lundi sur le rendu, aucun des principaux robots d'IA n'exécute le JavaScript. Le robot de ChatGPT télécharge des fichiers de script dans 11,50 % de ses requêtes, celui de Claude dans 23,84 %, et aucun ne les exécute. Un contenu qui arrive après l'hydratation n'arrive pas.

La question n'est donc pas « rendu serveur ou non ». Elle est : quel est le moyen le moins coûteux, le plus rapide et le plus maintenable de garantir que ce contenu figure dans le HTML initial.

Les quatre options face à ce besoin

Trois options sur quatre satisfont le besoin. Une seule échoue, et elle échoue totalement plutôt que partiellement.

Pourquoi le statique l'emporte sur le rendu serveur pour la citation

C'est la partie que l'on saute, et c'est là que le réflexe SSR coûte de l'argent.

Si l'objectif est qu'un robot trouve votre contenu dans le HTML, SSG et ISR y parviennent avec le temps de réponse le plus court et le coût d'hébergement le plus bas. Le SSR fait la même chose avec le time to first byte le plus lent et une consommation serveur élevée, en échange d'une fraîcheur qu'aucun robot n'utilisera jamais.

Le temps de réponse n'est pas ici une métrique de confort. Les robots opèrent sous contrainte de budget. Rappelons, à partir du même jeu de données Vercel, que le robot de ChatGPT consacre déjà 34,82 % de ses requêtes à des pages 404 et celui de Claude 34,16 %, contre 8,22 % pour Googlebot. Quand un tiers du budget de crawl part déjà dans des URL mortes, ajouter de la latence serveur à chaque requête restante n'est pas un choix neutre.

Les recommandations de Vercel sur le sujet sont directes quant au défaut à retenir : s'appuyer autant que possible sur SSG et ISR, et réserver le SSR aux données qui doivent être fraîches à la seconde.

Pour un site vitrine, un site de services, une documentation ou un blog, c'est-à-dire l'essentiel de ce que produisent les agences, l'ISR constitue le bon défaut. Le contenu est dans le HTML, la réponse est servie depuis le edge, le coût reste faible, et le CMS peut déclencher la régénération à la publication.

Quand le SSR est réellement la bonne réponse

Pas jamais. Le SSR justifie son coût lorsque le contenu de la page diffère à chaque requête d'une manière qui compte :

• Tableaux de bord et espaces client connectés, dont le contenu est par définition propre à chaque utilisateur.
• Stock ou tarifs en temps réel, évoluant plus vite que toute fenêtre de revalidation raisonnable.
• Pages de résultats de recherche, dont la réponse dépend entièrement de la requête.
• Tout cas où servir une version en cache à la mauvaise personne constitue un problème de données.

Notez que presque aucune de ces pages n'est une page que vous souhaitez voir citée par un système d'IA. Ce n'est pas un hasard. Les pages qui nécessitent du SSR et celles qui doivent être citables sont largement distinctes, et c'est bien pourquoi appliquer une stratégie unique à tout le site constitue l'erreur de fond.

Là où le CSR reste pertinent

Le rendu côté client n'est pas une erreur. C'en est une comme stratégie globale de page pour des pages de contenu.

À l'intérieur d'une page rendue par ailleurs en statique ou côté serveur, le CSR est l'outil adapté aux comportements interactifs : un filtre qui réordonne des résultats, un panier, une galerie, un configurateur, une prévisualisation. Rien de tout cela n'a besoin d'être explorable, et le faire transiter par le serveur n'apporte rien.

La règle est simple. Le contenu dans le HTML, l'interaction dans le client. Le problème n'est pas d'utiliser du JavaScript, c'est de l'utiliser pour livrer les mots.

La SPA héritée, qui est la vraie situation

La plupart du temps, personne ne choisit une stratégie de rendu. On se retrouve devant une application React de trois ans, construite entièrement côté client par un prestataire précédent, avec un client peu enclin à financer une refonte.

Trois options honnêtes, par ordre de préférence :

1. Migrer uniquement les gabarits de contenu. Basculer les gabarits vitrine, services, articles et produits en rendu serveur ou statique, et laisser les zones applicatives en l'état. C'est souvent bien moins lourd qu'il n'y paraît, car ces gabarits constituent la partie la plus simple du code. C'est le correctif qui résout le problème plutôt que de le contourner.

2. Le prérendu pour les robots, en solution d'attente. Une couche de prérendu détecte les user agents des robots et leur sert un instantané HTML pendant que les utilisateurs reçoivent l'application normale. Servir le même contenu dans un format différent n'est pas du cloaking, lequel consiste à servir un contenu différent pour manipuler le classement. Mais soyons lucides : Google a constamment présenté le rendu dynamique comme un contournement plutôt que comme une architecture durable, l'essentiel de la documentation qui en fait la promotion est publiée par les entreprises qui le vendent, et vous ajoutez une dépendance à maintenir et à surveiller. Cela achète du temps. Ce n'est pas la réponse.

3. Constater et documenter. Si aucune des deux options n'est possible, dites-le par écrit, et ne vendez pas de prestation de visibilité IA sur ce site. C'est la version honnête de la conversation, et elle coûte bien moins cher que celle du neuvième mois.

Décider par gabarit, pas par site

La réponse mature est qu'un site n'a pas de stratégie de rendu. Chaque gabarit en a une.

Un exemple concret pour un e-commerce classique :

• Accueil et gabarits de catégories : SSG. Évoluent peu, doivent être rapides et explorables.
• Fiches produit : ISR, avec revalidation au changement de stock ou de prix. Explorables, rapides, à jour en quelques minutes.
• Résultats de recherche : SSR. Dépendants de la requête, et pages que vous n'avez pas besoin de faire citer.
• Panier et tunnel : CSR. Interactif, propre à la session, délibérément non explorable.
• Blog et guides : SSG ou ISR. C'est votre surface de citation, traitez-la comme telle.

Les frameworks actuels permettent de choisir par route. Si la plupart des projets ne le font pas, c'est que la question n'a été posée à personne au moment où y répondre coûtait peu.

Le brief à écrire réellement

Plutôt que « il faut du SSR pour le SEO », la consigne qui produit la bonne construction ressemble à ceci :

Les gabarits de contenu (accueil, services, produit, article, catégorie) doivent restituer leur contenu principal dans le HTML initial, en génération statique ou régénération incrémentale, la revalidation étant déclenchée à la publication depuis le CMS. Les gabarits applicatifs (compte, panier, tunnel, recherche) peuvent être rendus côté client ou à la requête. Test de recette : pour chaque gabarit de contenu, une phrase du texte visible doit être trouvable dans le code source, JavaScript désactivé.

C'est cette dernière phrase qui compte. Une stratégie de rendu sans test de recette est une préférence. Avec un test, c'est une exigence vérifiée avant livraison plutôt que découverte neuf mois plus tard.

Où se situe Genesis Digital Factory

Les migrations de rendu représentent une part importante de ce que les agences nous confient, généralement comme moitié technique d'une mission de visibilité déjà vendue. Basculer les gabarits de contenu du client vers du statique ou de l'incrémental, assainir la surface de crawl, inscrire les données structurées dans le HTML initial. L'agence conserve la stratégie et la relation client, nous réalisons la production en marque blanche.

Envoyez-nous un sitemap et une note sur la stack actuelle. Nous revenons avec une recommandation de rendu par gabarit, les gabarits à migrer, ceux qui peuvent rester en l'état, et une estimation chiffrée de la migration. Gratuitement, sous 48 heures. Découvrez nos services techniques, ou notre offre de sous-traitance en marque blanche.