JavaScript SEO: rendu, hydration et indexation

Janvier 2025, un e-commerce de mode nous appelle en panique: 18 000 URLs de PDP indexees en 'soft 404'. Le HTML servi contenait trois lignes dans , et le contenu reel n'apparaissait qu'apres le mount de React cote client. Googlebot executait bien le JS, mais avec un delai moyen de 9 jours dans la file de rendu. Resultat: catalogue invisible pendant presque deux semaines apres chaque deploiement. C'est le genre de probleme qui n'apparait jamais dans un audit de copy ou de backlinks. Avant tout, il vaut la peine de revisiter Comment auditer le SEO on-page sans tomber dans les conjectures pour comprendre ou le rendu JS s'inscrit dans le diagnostic.

La confusion commence avec la terminologie. CSR (Client-Side Rendering) livre un HTML presque vide et delegue tout au navigateur. SSR (Server-Side Rendering) genere le HTML a la requete, par utilisateur. SSG (Static Site Generation) genere tout au build et sert des fichiers prets. ISR (Incremental Static Regeneration), popularise par Next.js, est hybride: statique mais revalide a la demande. Chacun porte ses trade-offs de TTFB, complexite de cache et cout serveur. Pour le SEO, la vraie question n'est pas 'lequel est meilleur', mais 'dans lequel de mes templates le contenu critique doit-il vivre dans le HTML initial'.

L'hydration est l'etape ou la plupart des equipes derapent. Vous servez un HTML SSR parfait, Google l'indexe, mais le JavaScript qui 'hydrate' la page pese 800 Ko et bloque l'interactivite pendant 4 secondes en 4G. Le contenu se classe, puis le LCP fait s'effondrer le classement. Astro, Qwik et les React Server Components attaquent precisement ce point, avec hydration partielle et resumability. Avant de migrer de stack, mesurez: quelle part du JS actuel est necessaire above-the-fold? La majorite decouvre que 70% peut devenir du HTML statique. Ce travail offre un double gain sur Core Web Vitals: au-dela du LCP, ce qui fait bouger l'aiguille et sur l'indexation.

Le mythe 'Google execute deja le JavaScript' doit mourir avec nuance. Oui, le Web Rendering Service utilise un Chromium headless a jour. Mais il existe deux files: celle de crawl (HTML brut) et celle de rendu (avec JS). Sur les gros sites, la file de rendu peut accuser plusieurs jours de retard. Pire: les liens decouverts uniquement dans le DOM post-JS n'entrent dans la file de crawl qu'apres le rendu. Une architecture SPA pure penalise donc la decouverte de nouvelles URLs. Combinez cela avec des problemes de Crawl budget : quand s'inquieter et comment le mesurer et vous obtenez des catalogues ou 30% des pages ne sont jamais indexees, meme presentes dans le sitemap.

Comment decider concretement? Utilisez une matrice simple par template. Landing pages institutionnelles a faible frequence de changement: SSG, sans debat. PLPs d'e-commerce avec filtres: SSR avec cache en edge (Vercel Edge, Cloudflare Workers) sur la cle des filtres les plus utilises, fallback SSR pur. PDPs: SSG avec ISR d'une heure couvre 90% des cas. Zones connectees (dashboards, checkout): CSR convient parfaitement, vous ne voulez pas les indexer. L'erreur classique est d'appliquer la meme strategie a tout le site parce que le framework 'le recommande'. Ce mapping rejoint directement les decisions de On-page e-commerce: PLP vs PDP sans cannibalisation.

Outils pour valider avant de deployer: URL Inspection dans Search Console montre exactement le HTML rendu que Google a vu, avec timestamp. Le Rich Results Test utilise le meme moteur. Pour auditer a grande echelle, Screaming Frog en mode 'JavaScript rendering' compare HTML brut et rendu, et expose le contenu qui n'existe que post-JS. Les logs serveur sont la verite terrain: filtrez par user-agent Googlebot et observez la proportion reelle entre Googlebot Smartphone et Googlebot. Qui n'a jamais ouvert ses logs prend souvent un choc au premier mois de Log file analysis : ce que Googlebot fait vraiment.

Trois pieges que je vois encore en 2026: lazy-load avec IntersectionObserver sur le contenu principal (Googlebot ne scrolle pas, donc rien ne charge), routage client-side sans History API correcte (URLs avec hash # non indexees), et meta tags injectees via JS apres le load (titles et canonicals modifies dans le DOM peuvent etre honores ou non, selon le timing). Pour ce troisieme cas, il vaut la peine de revoir Canonical tags : les erreurs frequentes qui saignent le trafic organique car le probleme n'est presque jamais le canonical lui-meme, mais le moment ou il apparait dans le document.

A retenir, concretement: lancez aujourd'hui un audit de 10 URLs strategiques. Comparez 'view-source' et 'Inspect Element' dans Chrome. Si le contenu critique, les liens de navigation et les meta tags ne sont pas dans view-source, vous avez un probleme de rendu, pas de contenu. Documentez le gap par template, priorisez SSR ou SSG sur les templates qui generent du revenu organique, et laissez CSR la ou cela n'a pas d'importance. Une stack moderne n'est pas une excuse pour du HTML vide sur une page qui doit se classer.