Faut-il vraiment rendre le contenu principal côté serveur avant les métadonnées en SSR ?

Pourquoi Google inverse-t-il la priorité classique SSR/CSR ?

La déclaration de Splitt casse une habitude solidement ancrée chez les développeurs : on ne commence plus par le head, on attaque direct le body. L'explication tient en un constat brutal — si ton contenu principal reste bloqué côté client pendant que les métadonnées s'affichent tranquille côté serveur, tu te retrouves avec un ratio Signal/Bruit catastrophique pour Googlebot.

Le robot crawle, charge le HTML initial, voit un title nickel, une meta description aux petits oignons… et un body vide en attente de JavaScript. Si le JS met 4 secondes à s'exécuter ou plante pour une raison quelconque, Google indexe du vent. Et c'est précisément ce que Splitt veut éviter : maximiser les chances que le contenu critique soit visible même si l'hydratation client échoue.

Qu'est-ce que le « contenu critique » selon cette logique ?

Splitt mentionne explicitement title, meta description, canonical et contenu principal. Le contenu principal, c'est tout ce qui porte la sémantique de ta page : paragraphes d'intro, titres H1-H2, premiers blocs texte, images hero avec alt descriptifs. Les éléments « secondaires » — navigation complexe, sidebar, widgets, recommandations produits — peuvent rester en CSR sans impacter l'indexation.

Cette hiérarchie pose un problème conceptuel : en pratique, les métadonnées font partie du contenu critique. Splitt les cite d'ailleurs. Ce qu'il veut dire, c'est qu'il ne faut pas se contenter de SSR ces balises en espérant que le corps de page suivra. Il faut garantir que le flux HTML initial contient déjà le textuel indexable, pas juste les signaux meta.

En quoi cela change-t-il les performances perçues par Google ?

Le Time to First Byte (TTFB) reste critique, mais le Largest Contentful Paint (LCP) devient déterminant pour l'indexation. Si ton LCP dépend d'un fetch client pour charger le contenu principal, tu prends un risque double : latence réseau + temps d'exécution JS. En SSR du contenu principal, tu garantis que le LCP correspond à un élément déjà présent dans le HTML initial.

Googlebot n'attend pas indéfiniment. Les tests terrain montrent qu'il alloue environ 5 secondes d'exécution JS par page en moyenne — parfois moins sur des sites à crawl budget serré. Si ton contenu principal arrive après ce délai parce qu'il dépend d'une API tierce ou d'un bundle React trop lourd, il ne sera jamais indexé.

• Contenu principal en SSR : visible dans le HTML source, indexable immédiatement même si JS échoue
• Métadonnées sans contenu : Google indexe une coquille vide avec de beaux snippets SERP… qui renvoient vers rien
• Hydratation progressive : le contenu SSR reste fonctionnel pendant que le JS enrichit l'interactivité sans bloquer l'indexation
• Résilience au timeout JS : si Googlebot coupe l'exécution, le contenu critique est déjà capturé
• Cohérence rendering mobile/desktop : moins de divergences si le HTML initial porte déjà le contenu essentiel

Cette recommandation contredit-elle les best practices observées sur le terrain ?

Pas vraiment. Les sites qui performent le mieux en SEO avec des stacks JS modernes font déjà du SSR complet du contenu principal — Next.js, Nuxt, SvelteKit, tous proposent par défaut un rendu serveur de la page entière, pas juste des métadonnées. Ce qui est nouveau, c'est que Splitt le formule explicitement comme une priorité absolue.

Le problème se pose surtout sur des architectures hybrides bricolées maison où les développeurs ont SSR'd uniquement le head pour « faire plaisir au SEO » sans toucher au corps de page. Ces implémentations semi-SSR sont un gouffre : elles donnent l'illusion d'un contenu crawlable alors que Googlebot voit un document quasi vide. Splitt tape précisément sur ce pattern.

Quelles sont les zones d'ombre de cette déclaration ?

Splitt ne précise pas où placer le curseur entre « critique » et « secondaire ». Un carrousel produit en homepage e-commerce, c'est critique ou secondaire ? Un bloc FAQ replié, c'est indexable en CSR ou faut-il le SSR ? Ces questions restent sans réponse officielle. [A vérifier] sur tes propres tests avec Mobile-Friendly Test et l'outil d'inspection d'URL.

Autre flou : la formulation « maximiser les performances » est ambiguë. Performances pour qui ? Si tu SSR 100% du contenu, tu augmentes le TTFB et la charge serveur, ce qui peut dégrader les Core Web Vitals. Splitt sous-entend qu'il faut trouver un équilibre, mais ne donne aucune métrique chiffrée. En pratique, il faut monitorer le compromis entre temps de génération SSR et temps de rendu client.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Les applications pures SaaS derrière login n'ont rien à faire du SSR pour Google — aucune page n'est destinée à être indexée. Les pages purement transactionnelles (checkout, panier) peuvent rester en full CSR sans impact SEO tant qu'elles sont en noindex.

Les sites statiques générés (Gatsby, Hugo, Jekyll) rendent déjà tout côté build, donc la question SSR/CSR ne se pose même pas. Et les sites full SSR classiques (WordPress, Drupal, Rails) n'ont jamais eu ce problème. Cette recommandation vise exclusivement les stacks JS modernes en mode hybride — React, Vue, Angular avec rendu mixte.

Que faut-il modifier concrètement dans une stack Next.js ou Nuxt ?

Si tu utilises getServerSideProps (Next) ou asyncData (Nuxt), vérifie que tu fetch bien les données du contenu principal côté serveur, pas juste les métadonnées. Un pattern courant qui pose problème : SSR le title/description via des props, mais laisser le body se charger avec un useEffect client. C'est exactement ce que Splitt condamne.

Dans Next 13+ avec App Router, privilégie les Server Components par défaut pour tout le contenu textuel critique. Marque explicitement 'use client' uniquement les composants interactifs (formulaires, carousels, accordéons). Ne bascule pas un composant en client juste parce qu'il contient un useState — extrait la logique interactive et laisse le rendu textuel en serveur.

Comment vérifier que Google crawle bien le contenu SSR et pas du vide ?

Utilise l'outil d'inspection d'URL dans Search Console, onglet « Page explorée ». Compare le HTML brut avec le rendu final. Si le HTML source contient déjà tes H1, premiers paragraphes et images hero, tu es bon. Si ces éléments n'apparaissent que dans le rendu final, c'est qu'ils dépendent du JS — donc risque d'indexation partielle.

Teste aussi avec curl ou wget en désactivant JavaScript : curl -A "Googlebot" https://tonsite.com. Le contenu principal doit être lisible dans la sortie HTML brute. Si tu vois des <div id="root"></div> vides, ton SSR est insuffisant. Complète par un test Mobile-Friendly avec l'URL Inspection API pour voir exactement ce que Googlebot renderer voit.

Quelles erreurs éviter lors de la migration SSR/CSR ?

Ne tombe pas dans le piège du « SSR tout à 100% » par dogmatisme. SSR un megamenu de 500 catégories ou une sidebar de filtres produits complexes va plomber ton TTFB sans gain SEO tangible — ces éléments ne portent pas la sémantique principale. Garde-les en CSR ou en lazy load.

Autre erreur classique : SSR le contenu mais oublier les attributs alt, aria-label et structured data. Ces signaux doivent aussi être dans le HTML initial, pas injectés par JavaScript après coup. Vérifie que ton JSON-LD est bien présent dans le source HTML, pas ajouté dynamiquement via un script client.

• Audit du HTML source (curl/wget) pour identifier le contenu manquant côté serveur
• Migration progressive : SSR d'abord H1, intro, premier écran de contenu
• Mesure du TTFB avant/après pour éviter une dégradation des Core Web Vitals
• Test Mobile-Friendly Tool et URL Inspection sur échantillon représentatif de pages
• Monitoring erreurs JS en prod : si le CSR plante, le SSR doit tenir la baraque
• Documentation des choix SSR/CSR pour chaque type de composant (menu, sidebar, CTA, contenu principal)