Guide des frameworks JavaScript côté client
React, Vue, Angular, Svelte et SolidJS partagent un risque SEO : le rendu côté client livre une coquille vide. La correction associe gestion du head et stratégie de rendu.
Langues
React, Vue, Angular, Svelte et SolidJS peuvent livrer une coquille HTML presque vide, puis construire la page dans le navigateur. Google sait rendre ces applications dans une file différée, mais Bing et les robots IA sont moins fiables. La correction commune associe des métadonnées uniques par route et une stratégie de prérendu, SSR ou méta-framework correspondant.
En bref — React, Vue, Angular, Svelte et SolidJS servent à créer des sites interactifs. Par défaut, ils envoient au navigateur une page HTML presque vide, puis construisent le contenu en JavaScript. Un robot peut donc rencontrer une page blanche. La correction est commune : gérer
<title>et les balises meta par page, puis faire apparaître le contenu dans le HTML avant l’exécution de JavaScript.
Définition des frameworks côté client
Les frameworks côté client peuvent rendre le contenu d’une route dans le navigateur après la réponse HTML initiale. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks Google peut exécuter JavaScript, mais les ressources disponibles et le rendu influencent toujours ce qui est traité. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
Un framework côté client est une bibliothèque JavaScript qui construit la page dans le navigateur du visiteur. Les plus courants sont React, Vue, Angular, Svelte et SolidJS ; ils servent à créer la plupart des applications web et tableaux de bord modernes.
Le risque tient aux mots côté client. Par défaut, ces outils livrent un petit fichier HTML qui ressemble à ceci :
<body>
<div id="root"></div>
<script src="/bundle.js"></script>
</body>Ce HTML ne contient aucun contenu, seulement un conteneur vide et un script. Le navigateur télécharge et exécute le script, puis fait apparaître titre, texte, liens et reste de la page. Ce comportement est le rendu côté client, ou CSR, et le site prend souvent la forme d’une application monopage, ou SPA.
Pourquoi cela pose un problème SEO
Un robot n’est pas une personne qui clique. Lorsque Googlebot ou un autre robot récupère la page, il reçoit d’abord la coquille vide. S’il n’exécute pas JavaScript, il ne voit aucun contenu à indexer.
Google peut exécuter JavaScript et finit généralement par voir le contenu. Cependant :
- Le rendu intervient avec un délai, dans une file distincte.
- Bing et les robots IA qui alimentent des outils comme ChatGPT exécutent JavaScript de manière bien moins fiable.
« Cela fonctionne dans mon navigateur » ne signifie donc pas « les moteurs peuvent le voir ».
Une correction commune aux cinq outils
Quel que soit le framework, la solution comporte deux volets :
- Gérer le head. Chaque page doit avoir son propre
<title>et sa description meta. Une application CSR simple partage un seul fichier HTML et donc, sans aide, un seul titre. Chaque outil propose une petite bibliothèque pour corriger cela. - Choisir une stratégie de rendu. Placez le contenu dans le HTML avant JavaScript par prérendu, par rendu côté serveur, ou SSR, ou avec le méta-framework correspondant, comme Next.js pour React et Nuxt pour Vue.
Pour les bibliothèques et options propres à chaque outil, passez à l’onglet Avancé, puis au guide dédié.
En bref — React, Vue, Angular, Svelte et SolidJS utilisent par défaut le rendu côté client : une coquille HTML presque vide, puis un DOM construit dans le navigateur. Le problème SEO est identique : le contenu n’existe qu’après JavaScript. Google effectue ce rendu plus tard dans une file ; Bing et les robots IA sont moins fiables. La correction associe gestion du head par route et stratégie de rendu : prérendu, SSR ou méta-framework correspondant. Les différences concernent surtout le nom des bibliothèques et les options détaillées dans chaque guide.
Des bibliothèques plutôt que des frameworks complets : origine du problème
Les architectures varient ; un rendu côté client n’entraîne donc pas automatiquement un échec d’indexation. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks Le rendu serveur ou le prérendu réduit la dépendance à l’exécution de JavaScript par le robot sans garantir l’indexation. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
React, Vue, Angular, Svelte et SolidJS sont surtout des bibliothèques de rendu d’interface. Elles transforment les données en DOM et le synchronisent avec l’état. Par défaut, ce DOM naît dans le navigateur, ce qui donne une sensation d’application rapide tout en créant le risque SEO.
Une compilation standard livre une coquille HTML avec un point de montage vide — <div id="root">,
<div id="app"> ou <app-root> — et un bundle JavaScript. Titres, texte, liens internes et données structurées
n’apparaissent qu’après téléchargement et exécution du bundle.
Il s’agit du rendu côté client, comportement initial des bibliothèques seules avant ajout d’un méta-framework ou d’un prérendu. Ce n’est pas un bogue. Mais ce défaut varie selon la version, l’outil de démarrage et la route : une page marketing peut être prérendue tandis qu’un tableau de bord reste en CSR. Vérifiez toujours le HTML réel livré par chaque route au lieu de déduire son mode du nom du framework.
Problème commun : la coquille vide
Google décrit un traitement en phases — exploration, rendu, indexation — et précise que “without rendering Google might not see that content.” (traduction) « sans rendu, Google risque de ne pas voir ce contenu. » Dans une application CSR, tout dépend de cette phase. Trois conséquences suivent :
- Le rendu est différé, sans délai fixe. Google sépare exploration, rendu et indexation, mais ne garantit aucune attente universelle. Le délai dépend de l’URL et des ressources disponibles ; avant la fin du rendu, le contenu n’existe pas pour l’indexation.
- Les autres robots ne sont pas acquis. Bing rend JavaScript de façon irrégulière et la plupart des robots IA l’exécutent peu ou pas. Chaque fournisseur doit être vérifié séparément ; un site uniquement CSR risque de rester invisible aux robots qui ne rendent pas.
- Les métadonnées par page manquent. Un fichier HTML unique partage
<title>et description meta entre toutes les routes si le head n’est pas géré activement.
Correction commune, première partie : gérer le head
Une SPA n’ayant qu’un document HTML, du code doit actualiser son head au changement de route. Chaque écosystème possède une bibliothèque ou une API de référence :
- React →
react-helmet-async, ou l’API Metadata de Next.js. - Vue →
@unhead/vue, moteur des utilitaires SEO de Nuxt. - Angular → services intégrés
TitleetMetade@angular/platform-browser. - Svelte → élément intégré
<svelte:head>. - SolidJS →
@solidjs/meta, puis SolidStart pour le SSR.
La gestion du head produit des balises uniques, mais ne résout pas seule la coquille vide : les balises n’apparaissent toujours qu’après JavaScript. Une stratégie de rendu reste nécessaire.
Correction commune, deuxième partie : choisir le rendu
Trois approches placent contenu et balises dans le HTML avant JavaScript, classées par réduction du risque SEO :
- Prérendu ou génération statique, SSG. Construire un fichier HTML par route à la compilation. C’est le risque le plus faible pour le contenu stable ; chaque bibliothèque propose un chemin de prérendu.
- Rendu côté serveur, SSR. Produire le HTML à chaque requête, puis l’hydrater dans le navigateur. Les méta-frameworks sont Next.js, Nuxt, Angular SSR, SvelteKit et SolidStart. Pour un site de contenu destiné au classement, c’est souvent la correction la plus nette.
- Rester entièrement en CSR tout en assurant l’exploration. Acceptable pour une interface derrière une connexion sans besoin de classement, mais mauvais choix par défaut pour le contenu public.
Décidez par route, pas par application. Une page marketing et un tableau de bord connecté peuvent suivre des stratégies différentes. Pour chaque route, examinez :
- Sortie : le contenu doit-il figurer dans la réponse initiale ?
- Actualité : peut-il être construit une fois ou change-t-il à chaque requête ?
- Personnalisation : varie-t-il par visiteur, ce qui exclut le prérendu ?
- Coût serveur : le SSR calcule à chaque requête ; le prérendu déplace le coût à la compilation.
- Dépendance à JavaScript : quelle part de l’utilité exige son exécution ?
- Échec : sans JavaScript, la route reste-t-elle utilisable ou devient-elle vide ?
La question est la même partout : ce contenu doit-il être classé ou cité ? Si oui, placez-le dans le HTML serveur ou prérendu. Pour une interface purement applicative, le CSR convient.
Traitement par Google et différences avec les autres robots
Google peut rendre ces cinq technologies avec un Chrome sans interface et récent, mais dans une file
différée. Le moteur est sans état : pas de cookies ou localStorage persistants, de service workers ni
d’interactions. Les règles du SEO JavaScript restent donc valables : vrais
liens <a href>, parité HTML brut/rendu, contenu non conditionné à un clic et absence de noindex injecté.
Chez les autres fournisseurs, Bing rend JavaScript de manière plus irrégulière et les robots IA ne le rendent souvent pas du tout. Un contenu CSR peut donc finir par exister pour Google mais rester absent ailleurs. SSR et prérendu ferment cet écart pour tous les robots, meilleur argument contre un contenu public uniquement CSR.
Les cinq outils en un coup d’œil
| Outil | Défaut | Gestion du head | SSR ou méta-framework | Remarque SEO |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js | SPA CSR très courante ; Next.js est la correction habituelle |
| Vue | CSR | @unhead/vue | Nuxt avec useSeoMeta() | Nuxt utilise le SSR par défaut ; Vue seul exige Nuxt ou un prérendu |
| Angular | CSR, SPA | services Title et Meta | Angular SSR | Les versions modernes ajoutent SSR et hydratation incrémentale |
| Svelte | CSR ; SvelteKit en SSR | <svelte:head> | SvelteKit | SSR par défaut ; attention au piège statique ssr:false |
| SolidJS | CSR | @solidjs/meta | SolidStart | Réactivité fine ; SolidStart apporte SSR et prérendu |
Le schéma reste constant : défaut CSR, outil de gestion du head et stratégie de rendu, généralement via le méta-framework correspondant. Seuls les noms et quelques pièges changent.
Guides détaillés par framework
Cette page sert de carte. Chaque outil dispose d’un guide consacré aux bibliothèques, réglages et pièges :
- SEO React — risques du CSR, React Router, History API,
react-helmet-asyncet choix de Next.js. - SEO Vue — défaut CSR de Vue 3,
createWebHistory(),@unhead/vue, prérendu et recours à Nuxt. - SEO Angular — défaut SPA,
@angular/ssr, servicesTitleetMeta, prérendu et hydratation incrémentale. - SEO Svelte — Svelte et SvelteKit, SSR,
<svelte:head>, piègeadapter-staticavecssr: falseet robots IA. - SEO SolidJS — défaut CSR,
@solidjs/meta, SolidStart, prérendu et effet de la réactivité fine sur le HTML.
Pour CSR, SSR, SSG, ISR, hydratation, rendu dynamique et règles de parité, consultez le guide parent SEO JavaScript.
Résumé par l’IA
Version condensée de l’onglet Avancé :
- Point de départ commun. React, Vue, Angular, Svelte et SolidJS utilisent souvent le rendu côté client :
coquille HTML presque vide (
<div id="root">) et DOM construit dans le navigateur. Le défaut varie par version, démarreur, méta-framework et route ; inspectez la sortie réelle. - Google rend, mais sans délai fixe. Cette étape en file après l’exploration varie par URL ; le moteur est sans état et n’effectue ni défilement ni clic.
- Les autres robots ne sont pas garantis. Bing est irrégulier et la plupart des robots IA n’exécutent pas JavaScript ; vérifiez chaque fournisseur.
- Deux volets communs. Premièrement, gérer
<title>et meta par route avecreact-helmet-async,@unhead/vue,Title/Meta,<svelte:head>ou@solidjs/meta. Deuxièmement, choisir prérendu, SSG, SSR ou le méta-framework Next.js, Nuxt, Angular SSR, SvelteKit ou SolidStart. - Le head seul ne suffit pas : sans stratégie de rendu, les balises attendent toujours JavaScript.
- Décidez par route selon sortie, actualité, personnalisation, coût serveur, dépendance JS et comportement en cas d’échec. Le contenu à classer doit être rendu serveur ou prérendu ; une interface connectée peut rester CSR.
Documentation officielle
Documentation de première main des moteurs et frameworks.
- Principes du SEO JavaScript — phases exploration, rendu et indexation, liens explorables et test du HTML rendu.
- Corriger les problèmes JavaScript liés à la recherche — soft 404, routage client, History API et contraintes du moteur.
- Guide détaillé du fonctionnement de Google Search — place du rendu dans exploration, indexation et diffusion.
Bing / Microsoft
- Série bingbot : JavaScript, rendu dynamique et cloaking — point de vue de Bing sur le rendu JavaScript et la raison d’être du rendu dynamique.
Frameworks : head et rendu
Citations des sources
Déclarations publiques qui établissent le problème CSR commun et sa correction. Les liens des moteurs mènent au passage cité.
Google — le rendu et l’importance de la coquille
- “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traduction) « Google traite les applications JavaScript en trois phases : exploration, rendu et indexation. » Accéder à la citation
- “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (traduction) « Le rendu est important, car les sites s’appuient souvent sur JavaScript pour ajouter le contenu ; sans rendu, Google risque de ne pas le voir. » Accéder à la citation
- “Google can only discover your links if they are <a> HTML elements with an href attribute.” (traduction) « Google ne peut découvrir vos liens que s’il s’agit d’éléments HTML <a> munis d’un attribut href. » — valable pour tous les routeurs. Accéder à la citation
- “Google Search does not interact with your page.” (traduction) « Google Search n’interagit pas avec votre page. » — le moteur ne fait ni défilement ni clic. Accéder à la citation
Patrick Stox (mon propre article : guide complet du SEO JavaScript)
- “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (traduction) « Toute configuration SSR, statique ou prérendue conviendra aux moteurs de recherche. » — principe commun aux frameworks de ce guide.
- Le moteur retient la directive robots la plus restrictive entre HTML brut et rendu ; un
noindexinjecté côté client peut donc désindexer une page dont la coquille indiquaitindex.
Liste de contrôle SEO pour les frameworks côté client
Elle s’applique à React, Vue, Angular, Svelte et SolidJS :
- Vous connaissez le mode actuel, CSR, SSR ou prérendu, en vérifiant si la source HTML contient le contenu.
- Le contenu à classer ou citer figure dans le HTML serveur ou prérendu.
-
<title>et description meta sont uniques par route dans le HTML rendu. - Les liens du routeur sont de vrais éléments
<a href>, et non un routage par fragment#, un gestionnaireonclickou un élément<div>cliquable. - JavaScript et CSS ne sont pas bloqués dans
robots.txt. - Aucun contenu n’exige défilement, clic ou survol.
- Les vues absentes renvoient un vrai
404ou portentnoindex. - Aucun script n’injecte un
noindexcontradictoire. - Bing et les robots IA ont été pris en compte ; SSR ou prérendu reste le choix fiable.
- Le résultat a été vérifié dans l’inspection d’URL, HTML rendu, capture et console compris.
Ces contrôles couvrent plusieurs sorties distinctes. Vérifiez chaque étape séparément, car une route peut réussir l’une et échouer à la suivante :
| Étape | Vérification |
|---|---|
| Réponse directe, JS désactivé | Le titre et le texte uniques sont-ils présents, ou seulement le point de montage ? |
| Morceaux diffusés en streaming | Le contenu arrive-t-il progressivement ou un morceau lent bloque-t-il la suite ? |
| DOM rendu | Après le bundle, titres, liens et données structurées sont-ils complets ? |
| Hydratation | Le client prend-il le relais sans erreur ni divergence ? |
| Navigation interne | URL, titre et canonique évoluent-ils comme lors d’un chargement direct ? |
| Codes d’état | Une route 404, 410 ou 5xx renvoie-t-elle ce statut plutôt qu’un message dans une réponse 200 ? |
| Métadonnées | Titre, description, canonique et robots sont-ils corrects par route ? |
Frameworks et correction en un coup d’œil
| Outil | Rendu par défaut | Gestion du head | SSR ou méta-framework | Prérendu |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js | SSG Next.js ou react-snap |
| Vue | CSR | @unhead/vue | Nuxt | nuxi generate ou extension de prérendu |
| Angular | CSR, SPA | Title et Meta intégrés | Angular SSR | prérendu avec ng build |
| Svelte | CSR ; SvelteKit en SSR | <svelte:head> | SvelteKit | adapter-static, attention à ssr:false |
| SolidJS | CSR | @solidjs/meta | SolidStart | prérendu SolidStart |
Correction en deux parties à retenir
- Gestion du head →
<title>et meta uniques par route. - Stratégie de rendu → prérendu, SSG, SSR ou méta-framework correspondant. Le head seul ne remplit pas la coquille vide.
Échelle du risque SEO, du plus faible au plus élevé
| Approche | Risque SEO | Usage |
|---|---|---|
| Prérendu ou SSG | Le plus faible | Contenu stable par requête |
| SSR, méta-framework | Faible | Contenu dynamique à classer |
| Hydratation isomorphe | Faible | Hybride application et contenu |
| CSR complet | Le plus élevé | Interface connectée sans besoin de classement |
Réalité des robots
| Robot | Exécute-t-il JavaScript ? |
|---|---|
| Googlebot | Oui, mais plus tard, dans une file et sans état |
| Bingbot | De manière irrégulière |
| Robots IA | Le plus souvent non |
Le contenu uniquement CSR constitue un pari partout sauf chez Google, où il reste différé. SSR et prérendu retirent ce pari pour tous.
Problèmes SEO courants
Les outils de recherche voient une page vide ou la coquille
Symptôme : le HTML brut ne contient qu’un point de montage tel que #root, #app ou app-root, alors
que le navigateur affiche le texte. Cause probable : route entièrement rendue côté client. Correction :
prérendez les routes stables ou utilisez le méta-framework SSR. Confirmez en récupérant l’URL sans JavaScript
et en trouvant son titre et son contenu uniques dans la réponse.
Toutes les routes partagent le même titre ou canonique
Symptôme : plusieurs URL ont des vues différentes mais le même titre, la même description ou canonique. Cause : la coquille commune contrôle le head sans mise à jour par route. Correction : utilisez l’API head du framework et les données de route. Vérifiez un canonique autoréférent et un titre propre dans chaque DOM final.
Les liens fonctionnent, mais les robots ne découvrent pas les routes
Symptôme : la navigation fonctionne alors que les routes liées restent inconnues. Cause : gestionnaires
de clic sur boutons ou div à la place d’ancres. Correction : rendez de vrais liens <a href="..."> et laissez
le routeur les enrichir. Confirmez la présence de l’href sans cliquer.
La console signale des erreurs d’hydratation
Symptôme : le HTML serveur est correct, mais la console signale une divergence ou le contenu change après
chargement. Cause : premier rendu serveur et client différents, souvent à cause des dates, langues,
identifiants aléatoires ou de window. Correction : rendez la sortie déterministe et exécutez la logique
propre au navigateur après l’hydratation. Confirmez l’absence d’erreurs dans la console.
La navigation interne et l’URL chargée directement diffèrent
Symptôme : un clic interne fonctionne, mais un accès direct ou une actualisation renvoie coquille générique, mauvais statut ou métadonnées périmées. Cause : la navigation client n’a pas d’équivalent serveur. Correction : rendez chaque route directement accessible avec le même contenu, statut et métadonnées. Testez l’URL fraîche, d’abord sans JavaScript puis avec.
Testez-vous : frameworks côté client
Cinq questions rapides sur le problème SEO commun à React, Vue, Angular, Svelte et SolidJS, puis sa correction.
Ressources recommandées
Mes articles connexes
- Guide complet du SEO JavaScript — rendu, parité DOM, règle de la directive la plus restrictive et choix d’une stratégie.
- Guide du débutant en SEO technique — place du rendu côté client dans l’ensemble du SEO technique.
Ma conférence
- Fonctionnement de la recherche (SlideShare) — exploration, rendu, indexation et classement, avec mon avertissement habituel : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Ceci reflète ma compréhension des systèmes ; elle ne sera pas complète ni exacte à 100 %. »
Ailleurs dans le secteur
- web.dev — rendu sur le Web — explication de référence de CSR, SSR, SSG et hydratation.
- Google Search Central — principes du SEO JavaScript — documentation officielle sur exploration, rendu, indexation et liens.
- Google Search Central — résoudre les problèmes JavaScript — soft-404s, routage client et History API.
- Série vidéo de Martin Splitt sur le SEO JavaScript — vidéos officielles de Google sur les applications JavaScript.
- Onely — dossier SEO JavaScript — analyses techniques d’une agence spécialisée.
Journal des modifications
Mis à jour le 11 août 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.
Mis à jour le 11 août 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.
Mis à jour le 17 juil. 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.