JavaScript SEO en 2026 — rendu et indexation

1. Comment Google rend le JavaScript

Depuis 2019, Googlebot utilise un Chromium evergreen (mis à jour automatiquement vers la dernière stable de Chrome). Le rendu se fait en deux passes documentées publiquement par Google :

Premier crawl : Googlebot récupère le HTML brut, suit les liens, indexe le contenu HTML statique immédiatement disponible.
Mise en file d'attente : si la page contient du JavaScript significatif, elle est ajoutée à la queue de rendu. Le délai varie de quelques secondes à plusieurs jours selon le crawl budget et la charge serveur Google.
Rendu JS : Chromium exécute le JS, produit le DOM final, qui est ensuite indexé en complément ou remplacement du HTML brut.

Conséquence pratique : tout contenu qui dépend du JavaScript pour apparaître est retardé dans l'index. Pour une page event (news, lancement produit), ce délai peut être fatal. Pour une page evergreen (article guide, page service), c'est moins critique mais reste suboptimal.

C'est pourquoi le SSR (rendu côté serveur) reste la stratégie SEO la plus sûre : Google reçoit du HTML déjà rendu, indexe immédiatement, pas de rendu JS différé nécessaire.

2. SPA / SSR / SSG / ISR : quoi choisir

SPA (Single Page App) — Client-Side Rendering pur

HTML quasi-vide envoyé au navigateur, contenu généré 100 % côté client par JavaScript. À éviter pour le SEO sauf pour les zones non-indexables (admin, app SaaS). Frameworks classiques : Vue/React/Angular en mode SPA. Performance médiocre, indexation retardée.

SSR (Server-Side Rendering)

HTML rendu côté serveur à chaque requête, envoyé pré-rempli au navigateur. Standard SEO solide. Coût : serveur plus chargé que SSG/CDN. Nuxt 3 et Next 13 le font par défaut en mode "universal".

SSG (Static Site Generation)

HTML pré-rendu à la build, servi en static depuis CDN. Optimum SEO et performance. Limitation : contenu statique, rebuild nécessaire pour mise à jour. Nuxt generate, Next export, Astro, Hugo, Jekyll.

ISR (Incremental Static Regeneration)

Hybride SSG + SSR : pages statiques au build, regénérées en arrière-plan selon TTL ou trigger. Idéal pour les e-commerces et blogs avec contenu fréquemment updaté. Next.js native, Nuxt via routeRules.

3. Nuxt et Next en pratique

Nuxt 3+ et Next 13+ rendent server-side par défaut, ce qui résout 80 % des problèmes SEO classiques des SPA. Reste 20 % de pièges spécifiques.

Nuxt 3+/4 :

useFetch / useAsyncData : par défaut server-side, le contenu fetch arrive dans le HTML rendu. Bien.
<ClientOnly> : tout ce qui est dedans est exclu du SSR. Critique pour le SEO : si vous mettez votre contenu money dans ClientOnly, il n'est pas indexé.
routeRules : permet de mixer SSR, SSG, ISR par page dans nuxt.config.ts. Sweet spot pour les sites avec mix.
@nuxtjs/seo : module qui regroupe sitemap, robots, schema-org, og-image. À utiliser systématiquement.

Next 13+/14 :

App Router : Server Components par défaut, hydratation sélective. SEO-friendly par design.
'use client' : à utiliser uniquement quand interactivité réelle nécessaire. Mettre tout en client casse les bénéfices.
Metadata API : generateMetadata permet du SEO dynamique élégant.
Edge runtime vs Node : Edge plus rapide mais limitations. Pour SEO, Node runtime souvent plus simple.

4. Les 5 pièges classiques

01
Contenu critique dans <ClientOnly>. Tout ce qui est dans ce composant n'est pas SSR. Si vous y mettez votre H1, votre meta description dynamique, ou vos prix, Google ne les voit pas dans le premier crawl.
02
Hydration mismatch. Le HTML SSR différe du HTML rendu côté client. Causes typiques : Date.now() utilisé dans le template, content différent selon utilisateur connecté ou non, randomness. Casse l'hydration, Google peut indexer du contenu inattendu.
03
Bundle JS trop lourd. Plus le JS pèse, plus le INP et LCP se dégradent. Code splitting et lazy loading non négociables. Cible : moins de 200 KB de JS critique par page.
04
Routing 100 % JS sans href. Liens internes générés via JavaScript onClick au lieu de <a href>. Googlebot ne les suit pas (ou avec gros délai). Toujours utiliser <NuxtLink> ou <Link> qui résolvent en vrai <a>.
05
Lazy loading agressif sur le contenu above-the-fold. Image hero ou H1 lazy-loaded = pas rendu au premier paint = LCP catastrophique. Lazy uniquement below-the-fold.

5. Comment débugger

view-source: dans le navigateur — donne le HTML brut envoyé par le serveur. Si votre contenu n'est pas dedans, c'est SPA, c'est mauvais pour le SEO.
GSC Inspection d'URL → Tester en direct → HTML rendu — montre ce que Googlebot voit après rendu JS. À comparer avec view-source.
Mobile-Friendly Test — donne aussi le HTML rendu, utile pour les vérifications rapides.
Screaming Frog en mode JavaScript Rendering — crawl complet avec rendu JS. Identifie les pages où le rendu casse.
Lighthouse en mode "Performance" — détecte les JS bloquants, les bundles trop lourds, les images non-optimisées.

Pour aller plus loin

FAQ — JavaScript SEO

01Google rend-il vraiment le JavaScript en 2026 ?

Oui, depuis 2019 Googlebot utilise un Chrome récent (Chromium evergreen) pour rendre le JavaScript. Mais le rendu se fait en deux passes : premier crawl du HTML brut, mise en file d'attente pour rendu JS, second crawl avec le DOM final. Le délai entre les deux peut être de quelques secondes à plusieurs semaines selon le crawl budget de la page.

02SPA, SSR, ISR : quelle stratégie privilégier en SEO ?

Pour le SEO sérieux : SSR (Server-Side Rendering) ou ISR (Incremental Static Regeneration) systématiquement sur les pages money. SPA pur (Client-Side Rendering uniquement) à éviter sauf pour les zones administrateur ou applications type SaaS où l'indexation n'est pas l'objectif.

03Nuxt et Next gèrent-ils bien le SEO ?

Oui, par défaut depuis Nuxt 3 / Next 13. Les deux frameworks rendent server-side ou statique par défaut. Les pièges : composants Client-only (<ClientOnly> chez Nuxt), data fetching mal placé, hydration mismatches. Tester en regardant le HTML source (view-source:) sans JavaScript activé.

04Comment vérifier si Google rend bien mon JavaScript ?

Trois outils : (1) Google Search Console "Inspection d'URL" → "Tester l'URL en direct" → "Afficher la page testée" → onglet HTML rendu (vs HTML source). (2) Mobile-Friendly Test qui donne aussi le HTML rendu. (3) Screaming Frog en mode JavaScript Rendering pour crawl complet. Comparer le HTML source vs rendu identifie ce qui dépend du JS.

05Faut-il prerender les SPA pour Googlebot ?

Le prerendering (Prerender.io, Rendertron) reste une option pour les SPA legacy qui ne peuvent pas migrer vers SSR. Mais c'est un workaround vieillissant, fragile, qui multiplie les sources de vérité. Mieux vaut migrer vers SSR/SSG si le SEO compte vraiment. Pour les applications type Angular/React legacy : prerendering acceptable comme transition.

06JavaScript et Core Web Vitals : le rapport ?

Critique. Un JavaScript trop lourd dégrade le LCP (Largest Contentful Paint) et le INP (Interaction to Next Paint). Code splitting, lazy loading, defer non-critique, tree shaking : les optimisations classiques bundle ont un impact direct sur les CWV, qui sont eux-mêmes un signal de ranking.

En résumé

JavaScript et SEO ne sont plus incompatibles, mais le SSR ou SSG reste la voie royale. Les frameworks modernes (Nuxt 3+, Next 13+) résolvent 80 % des cas par défaut, mais 20 % de pièges techniques peuvent casser le SEO d'un site SPA mal converti.

Si vous avez un site SPA legacy (Angular, React CRA) avec un enjeu SEO sérieux, la migration vers SSR (Nuxt, Next) est presque toujours rentable. Le coût de migration se rembourse en quelques mois de trafic récupéré.

· audit technique

Audit SEO technique en 2 semaines

Audit complet incluant rendu JS, CWV, schema, indexation. Particulièrement pertinent pour les sites SPA, SaaS, applications Vue/React/Angular legacy.

Découvrir le SEO technique Yvarn

Mattis Bétourné

Fondateur d'Yvarn, agence SEO à Bordeaux. Développeur senior (Thales, Capgemini, Betclic, Maincare). Spécialité : SEO technique sur stacks modernes (Nuxt, Next, headless). À propos.