SEO JavaScript (SSR, CSR, hydratation, rendu)

Le SEO JavaScript désigne l'ensemble des pratiques qui permettent à un site dont le contenu dépend de JavaScript d'être crawlé, rendu et indexé par les moteurs de recherche. Google exécute le JavaScript dans une étape de rendu distincte du crawl, avec ses délais et ses limites. Le choix du mode de rendu (côté client, côté serveur, statique ou hybride avec hydratation) est la décision qui pèse le plus sur la visibilité d'un site construit avec un framework JavaScript.

Définition détaillée du SEO JavaScript

Un site « classique » livre son contenu dans la réponse HTML du serveur : le robot lit le code source et y trouve le texte, les liens, les balises. Un site construit avec un framework JavaScript (React, Vue, Angular, Svelte et les outils bâtis dessus) peut au contraire livrer une page presque vide, dans laquelle un script va chercher les données puis construit le contenu dans le navigateur. Google appelle ce schéma le modèle « app shell » : le HTML initial ne contient pas le contenu réel, et le moteur doit exécuter le JavaScript avant de le voir.

Le SEO JavaScript couvre tout ce qui découle de cette différence : comprendre comment un moteur exécute le code, choisir où le rendu a lieu (navigateur, serveur, ou à la construction du site), éviter les erreurs qui rendent un contenu ou un lien invisibles, et vérifier le résultat avec les outils du moteur. Il ne s'agit pas d'une discipline à part du SEO technique, mais de son application à une architecture particulière.

Quatre familles d'architectures sont traitées dans des définitions dédiées et renvoient vers cette page : la SPA (Single Page Application), la PWA (Progressive Web App), le couple headless CMS et Jamstack, et le lazy loading, qui n'est pas une architecture mais une technique de chargement différé dont les effets sur l'indexation relèvent des mêmes mécanismes.

Comment Google traite le JavaScript

La documentation Search Central décrit un traitement en trois phases : le crawl, le rendu, l'indexation. Ces phases ne s'enchaînent pas immédiatement, et une page attend dans deux files distinctes.

Le crawl

Googlebot commence par lire le fichier robots.txt. Si l'URL est interdite, il ne la demande pas et n'exécutera aucun script sur cette page. Il récupère ensuite la réponse HTTP, en extrait les URL présentes dans les attributs href des liens et les ajoute à la file de crawl. Google précise qu'il ne rendra pas le JavaScript de fichiers bloqués par robots.txt : une règle qui interdit le dossier des scripts ou des feuilles de style prive le moteur des ressources dont il a besoin pour construire la page.

Le rendu

Toute page qui répond en code 200 est placée dans la file de rendu, qu'elle contienne ou non du JavaScript, sauf si une balise ou un en-tête robots demande de ne pas l'indexer. Les pages en erreur (404 par exemple) peuvent ne pas être rendues. Google indique que la page « peut rester quelques secondes dans cette file, mais cela peut prendre plus longtemps ». Quand ses ressources le permettent, un Chromium sans interface (le Web Rendering Service, ou WRS) charge la page, exécute les scripts et produit le HTML rendu. Depuis le 7 mai 2019, ce moteur de rendu est une version « evergreen » de Chromium, mise à jour régulièrement ; auparavant, Googlebot était figé sur Chrome 41 et ignorait la plupart des fonctionnalités modernes du langage.

Une étude publiée par Vercel et MERJ le 31 juillet 2024, à partir de plus de 100 000 requêtes de Googlebot sur nextjs.org, a mesuré ce délai : la moitié des pages étaient rendues en moins de 10 secondes après le crawl, mais les 1 % les plus lentes attendaient environ 18 heures. Toutes les pages HTML de l'échantillon ont fini par être rendues. Ces chiffres valent pour un site à forte autorité et ne sont pas transposables tels quels à un site moins crawlé.

L'indexation

Google utilise le HTML rendu pour indexer la page, et y lit une seconde fois les liens, qu'il ajoute à la file de crawl. Un lien qui n'apparaît qu'après exécution du JavaScript est donc découvert, mais seulement à cette étape, et à condition d'être un élément <a> muni d'un attribut href. Le titre, la meta description et la balise canonical peuvent être posés ou modifiés par JavaScript ; pour la canonical, Google demande de ne jamais indiquer par script une valeur différente de celle du HTML initial.

Les ressources et le budget de crawl

Dans un billet du 3 décembre 2024, Google a détaillé la façon dont le WRS récupère les ressources d'une page. Chaque script et chaque feuille de style référencés sont téléchargés par Googlebot, et ces requêtes consomment le budget de crawl du nom d'hôte qui les héberge. Pour limiter la dépense, le WRS met en cache toutes les ressources JavaScript et CSS pendant une durée pouvant atteindre 30 jours, sans tenir compte des directives de cache HTTP. Deux conséquences pratiques : un site a intérêt à limiter le nombre de ressources nécessaires au rendu, et un paramètre de « cache busting » qui change l'URL des scripts à chaque déploiement force Google à les retélécharger. Une mise à jour du billet, le 6 décembre 2024, déconseille d'héberger les ressources critiques sur un autre nom d'hôte, la connexion supplémentaire ralentissant la page.

Les modes de rendu : CSR, SSR, SSG et hydratation

Le vocabulaire est fixé par l'article de référence « Rendering on the Web » d'Addy Osmani et Jason Miller, publié sur web.dev en février 2019 et mis à jour le 5 janvier 2026. Ses auteurs recommandent d'envisager le rendu côté serveur ou le rendu statique avant une approche fondée sur une hydratation complète.

Le rendu côté client (CSR, Client-Side Rendering)

La page est construite dans le navigateur par JavaScript : logique, récupération des données, gabarits et routage s'exécutent sur l'appareil de l'utilisateur. C'est le modèle par défaut d'une SPA. Il produit le HTML initial le plus léger, mais fait dépendre l'affichage du téléchargement et de l'exécution d'un paquet de code qui grossit avec l'application, ce qui pèse sur le LCP et l'INP. Pour un moteur, c'est le cas où tout repose sur la phase de rendu.

Le rendu côté serveur (SSR, Server-Side Rendering)

Le serveur génère le HTML complet de la page à chaque requête et l'envoie au navigateur, qui affiche le contenu sans attendre le JavaScript. Le robot reçoit un contenu lisible dès la réponse HTTP. La contrepartie est un temps de génération côté serveur, qui peut allonger le TTFB, et une charge de calcul à chaque visite.

Le rendu statique (SSG, Static Site Generation)

Le HTML est produit à la construction du site, une fois pour toutes, sous forme d'un fichier par URL, puis déposé sur un serveur de fichiers ou un CDN. Le TTFB est constant et rapide, le serveur n'a rien à calculer. La limite : il faut connaître toutes les URL à l'avance et régénérer le site à chaque changement de contenu, ce qui devient difficile sur un catalogue de plusieurs centaines de milliers de pages. C'est l'approche de la Jamstack.

Le prérendu (prerendering)

À ne pas confondre avec le rendu statique : le prérendu consiste à exécuter une application côté client au moment de la construction pour capturer son état initial en HTML. La page s'affiche vite, mais reste inerte tant que le JavaScript n'a pas démarré. Le test proposé par web.dev pour distinguer les deux : désactiver JavaScript. Une page statique conserve la plupart de ses fonctions, une page prérendue ne garde que quelques liens.

L'hydratation

L'hydratation est l'exécution des scripts côté client qui ajoutent l'état et l'interactivité à un HTML déjà rendu par le serveur. Le navigateur affiche d'abord le HTML reçu, puis le framework « reprend la main » sur ce DOM. Le contenu est visible tôt, mais la page n'est interactive qu'une fois le JavaScript chargé, ce qui explique l'écart fréquent entre un bon FCP et un INP médiocre. Les frameworks ont développé des variantes pour réduire ce coût : le rendu en flux (streaming SSR), qui envoie le HTML par morceaux, l'hydratation progressive, qui active les composants un à un, et l'hydratation partielle, qui n'envoie du JavaScript que pour les zones réellement interactives (l'architecture dite « en îlots »).

Le rendu dynamique, une solution de contournement

Le rendu dynamique consiste à servir aux robots une version prérendue de la page et aux utilisateurs la version JavaScript, en distinguant les deux par l'user-agent. Google a longtemps présenté cette technique comme acceptable et ne la considère pas comme du cloaking quand le contenu est identique. Sa documentation la qualifie désormais de « solution de contournement et non de solution à long terme », qui « crée des complexités et des besoins en ressources supplémentaires », et recommande à sa place le rendu côté serveur, le rendu statique ou l'hydratation.

Les frameworks et leur réponse au problème

Les principaux frameworks intègrent aujourd'hui le rendu côté serveur ou statique, souvent au choix par route. La documentation de React recommande de démarrer un projet avec un framework complet (Next.js, React Router v7), qui gère CSR, SSG et SSR par page. Angular livre ses applications en rendu client par défaut mais propose un « rendu hybride » où chaque route est déclarée client, prérendue ou serveur. Vue documente son SSR en citant expressément un meilleur référencement, « les robots des moteurs voyant directement la page entièrement rendue ». Le choix n'est donc plus entre « SPA » et « site classique » : il se fait route par route, en réservant le rendu client aux écrans qui n'ont pas besoin d'être indexés (espace connecté, configurateur, tableau de bord).

Les erreurs classiques

• Des liens sans href. Un élément qui déclenche une navigation par un gestionnaire d'événement (onclick, routerLink sans attribut href, <span> cliquable) n'est pas un lien pour Google. Le maillage interne d'un site JavaScript ne fonctionne qu'avec de vraies ancres.
• Des URL en fragment (/#/produits). Le schéma de crawl AJAX qui les rendait lisibles est abandonné depuis 2015 ; Google demande d'utiliser l'API History, qui change l'URL sans recharger la page.
• Des soft 404. Une SPA répond 200 sur toutes ses routes, y compris les pages inexistantes. Google propose deux remèdes : rediriger en JavaScript vers une URL qui répond 404 côté serveur, ou injecter une balise meta robots noindex quand la donnée demandée n'existe pas.
• Un noindex dans le HTML initial que le script retire ensuite. La page porteuse d'un noindex dans la réponse serveur n'est pas envoyée au rendu ; le script qui devait le supprimer ne s'exécute jamais.
• Compter sur un état persistant. Le WRS charge chaque URL à neuf : Local Storage, Session Storage et cookies sont effacés entre deux chargements. Un contenu qui dépend d'un choix mémorisé (langue, consentement, panier) n'est pas vu.
• Un cache trompeur. Googlebot peut ignorer les en-têtes de cache et réutiliser un script périmé. La parade recommandée est l'empreinte de contenu dans le nom de fichier (main.2bb85551.js), qui change à chaque version.
• Des fonctionnalités non prises en charge. Googlebot refuse les demandes de permission (géolocalisation, caméra), ne gère ni WebSockets ni WebRTC et ne prend pas en charge WebGL. Le contenu doit rester accessible par une requête HTTP ordinaire, avec une détection de fonctionnalité et une solution de repli.
• Des composants web sans slot. Le WRS aplatit le shadow DOM ; un composant qui n'expose pas son contenu par le mécanisme de <slot> peut se rendre vide.
• Un paywall côté client. Envoyer le contenu complet puis le masquer en JavaScript ne le protège pas et brouille l'évaluation du contenu ; l'accès doit être tranché côté serveur.

Comment tester le rendu d'une page

L'outil d'inspection d'URL de la Search Console est la référence : son test en direct affiche le HTML rendu par le WRS, la capture d'écran, les ressources chargées ou bloquées, et les messages de la console JavaScript. Le test des résultats enrichis donne les mêmes informations sans propriété vérifiée. La méthode consiste à comparer trois états d'une même page : le code source brut (ce que reçoit le robot au crawl), le HTML rendu par Google, et la page vue dans un navigateur. Tout contenu ou lien présent dans le navigateur et absent du HTML rendu est un problème à traiter.

Deux compléments : le rapport de statistiques de crawl de la Search Console, que Google désigne comme la source fiable de l'activité de Googlebot et du WRS, les outils d'analyse côté client ne les mesurant pas correctement ; et l'analyse des logs serveur, seule à montrer quelles ressources sont réellement demandées et à quel rythme. Les crawlers SEO du marché proposent enfin un mode « rendu JavaScript » qui permet de comparer, à l'échelle du site, le HTML brut et le HTML rendu.

Au-delà de Google : les autres robots

La documentation Search Central le rappelle : le rendu côté serveur ou le prérendu « reste une bonne idée », parce qu'il accélère le site pour les utilisateurs et les robots, et parce que « tous les robots ne peuvent pas exécuter JavaScript ». Le point a pris de l'importance avec les moteurs de réponse. Une analyse publiée par Vercel le 17 décembre 2024 sur le trafic de son réseau concluait que les robots d'OpenAI (GPTBot, OAI-SearchBot), d'Anthropic (ClaudeBot), de Meta, de ByteDance et de Perplexity téléchargent les fichiers JavaScript mais ne les exécutent pas, et ne lisent donc pas un contenu rendu côté client ; Gemini fait exception, en s'appuyant sur l'infrastructure de Googlebot. Un contenu qui n'existe que dans le DOM construit par le navigateur est ainsi invisible pour la plupart des assistants qui citent des sources. Pour un site qui veut apparaître dans ces réponses, le HTML servi par le serveur redevient la seule version qui compte.

FAQ

Google indexe-t-il les sites en JavaScript ?

Oui. Google exécute le JavaScript dans une étape de rendu fondée sur un Chromium à jour, et toutes les pages en code 200 passent par cette étape. Le risque n'est pas l'absence d'indexation mais le délai, les erreurs d'implémentation (liens sans href, soft 404, contenu conditionné à un état) et l'invisibilité auprès des robots qui ne rendent pas le JavaScript.

Faut-il abandonner le rendu côté client pour être bien référencé ?

Pas nécessairement, mais il faut le réserver aux pages qui n'ont pas besoin d'être indexées. Les frameworks actuels permettent de choisir le mode de rendu route par route : serveur ou statique pour les pages de contenu et de catalogue, client pour les écrans applicatifs. Google et web.dev recommandent le rendu côté serveur ou statique plutôt qu'une hydratation complète.

Quelle est la différence entre SSR et hydratation ?

Le SSR est la production du HTML sur le serveur. L'hydratation est l'étape suivante, côté navigateur, où le framework attache son état et ses gestionnaires d'événements à ce HTML déjà affiché. On peut faire du SSR sans hydratation (page statique enrichie de quelques scripts) ; l'hydratation suppose toujours un rendu préalable.

Le rendu dynamique est-il encore recommandé ?

Non. Google le décrit comme une solution de contournement, qui n'est pas du cloaking si le contenu est identique, mais qui ajoute une infrastructure à maintenir. Les alternatives recommandées sont le rendu côté serveur, le rendu statique ou l'hydratation.

Comment savoir si Google voit mon contenu JavaScript ?

Avec l'outil d'inspection d'URL de la Search Console, en mode test en direct : il montre le HTML rendu, la capture d'écran et les ressources bloquées. Si le contenu ou un lien manque dans ce HTML rendu, Google ne le voit pas. Le test des résultats enrichis donne le même aperçu sans propriété vérifiée.

Les robots des assistants IA exécutent-ils le JavaScript ?

D'après l'analyse publiée par Vercel en décembre 2024, les robots d'OpenAI, d'Anthropic, de Meta, de ByteDance et de Perplexity téléchargent les scripts sans les exécuter. Gemini s'appuie sur l'infrastructure de Googlebot et bénéficie du rendu. Un contenu rendu uniquement côté client est donc absent des réponses de la plupart de ces assistants.

En résumé

• SEO JavaScript : les pratiques qui permettent à un site dépendant de JavaScript d'être crawlé, rendu et indexé.
• Traitement par Google : trois phases (crawl, rendu, indexation), une file de rendu aux délais variables, un Chromium à jour depuis mai 2019, des ressources mises en cache jusqu'à 30 jours.
• Modes de rendu : côté client (CSR), côté serveur (SSR), statique (SSG), prérendu, et hydratation qui rend interactif un HTML déjà servi.
• Recommandation : Google et web.dev privilégient le rendu serveur ou statique ; le rendu dynamique n'est plus qu'une solution de contournement.
• Erreurs à éviter : liens sans href, URL en fragment, soft 404, état persistant, cache périmé, fonctionnalités non prises en charge par Googlebot.
• Autres robots : la plupart des crawlers d'assistants IA n'exécutent pas le JavaScript ; le HTML servi par le serveur est ce qu'ils lisent.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !