JavaScript SEO — Next.js, Astro, et le mythe du SSR obligatoire
Faut-il SSR partout pour le SEO en 2026 ? Réponse nuancée selon votre contenu et votre framework.
Google rend désormais le JavaScript correctement (depuis ~2019), mais avec une latence et un budget. Faut-il SSR pour autant ? Pas toujours.
Ce que Google fait en 2026
- Première vague : crawl HTML brut. Indexation immédiate.
- Deuxième vague : rendu JS (Chrome headless 120). Re-crawl asynchrone, parfois 24-48h plus tard.
- Si le HTML brut suffit : indexé tout de suite. Si tout est en client-side, attente.
SSR vs SSG vs CSR — le bon choix
| Type de contenu | Stratégie 2026 |
|---|---|
| Marketing pages, blog | SSG (Astro, Next.js export) |
| E-commerce catalogue | SSG + ISR (Next.js, Hydrogen) |
| App authentifiée | CSR avec auth, peu de SEO |
| Recherche dynamique | SSR ou Edge SSR |
| Pages produit lourdes | SSR + ISR |
Le cas Astro
Astro Islands = HTML statique + petits îlots interactifs. Vous obtenez SEO parfait avec 95% de JS en moins. C’est la stack idéale pour un site marketing en 2026.
Le cas Next.js 15
App Router + RSC : les composants serveur ne déchargent aucun JS côté client. SEO parfait sur les pages publiques. Mais attention :
- Hydratation lourde dans les Client Components → INP qui explose
- Streaming SSR (
Suspense) — bien pour LCP, pas idéal pour les bots qui attendent le HTML complet
Erreurs fréquentes
- Tout en
'use client'parce que c’est plus simple → JS énorme, INP ruiné - Liens en
<button onClick={navigate}>au lieu de<Link>→ invisible pour les crawlers - Lazy load des images dans le viewport initial → LCP catastrophique
Le test ultime
view-source: sur votre URL. Si le H1 et la description sont dans le HTML servi, vous êtes bon. Sinon, SSR.