React, Vue et Angular donnent des interfaces fluides. Par défaut, ils donnent aussi des pages vides aux robots. Le choix du mode de rendu est devenu une décision SEO.
Les frameworks JavaScript modernes ont changé la façon de construire le web. Ils ont aussi créé une catégorie de problèmes SEO : le contenu généré côté client n’existe pas dans le HTML initial, et le robot doit exécuter le code pour le découvrir. Sur une application monopage mal configurée, Google peut indexer une coquille vide.
Ce guide explique comment Google traite le JavaScript, quelles solutions de rendu choisir selon la stack (React, Vue, Angular, Svelte) et quels réglages vérifier pour que chaque page soit vue, comprise et classée.
Le SEO d’un site JavaScript dépend du rendu : en rendu côté client (CSR), Google doit exécuter le script avant de voir le contenu, ce qui retarde ou fait échouer l’indexation. Le rendu côté serveur (SSR) ou statique (SSG) avec Next.js, Nuxt, Astro ou Angular Universal livre le HTML complet dès la première requête. Il faut ensuite des liens <a href> natifs, des balises injectées avant l’exécution, des 404 côté serveur et aucune ressource JS ou CSS bloquée dans le robots.txt.
Advisedonclick ne sont pas suivis. Seule la balise <a> avec un href compte.Le robot lit d’abord le HTML initial. Si le contenu manque, la page passe dans une file d’attente de rendu où le Web Rendering Service exécute le JavaScript. Ce second passage peut prendre du temps et échouer.
Typique des SPA par défaut. Le contenu, la navigation et parfois les balises méta n’existent qu’après exécution du script.
Le serveur exécute le code, génère le HTML complet et l’envoie au navigateur comme au robot. L’hydratation attache ensuite les interactions.
Les pages sont rendues à la construction du site, servies comme du HTML pur. Le plus rapide pour le contenu qui change peu.
Un rendu JavaScript lourd dégrade le LCP et l’INP. La quantité de script envoyée au client est un facteur de performance direct.
<a href="/url"> pour toute la navigation. Pas de lien qui n’existe que dans un onclick.Un site vitrine ou un blog sans équipe de développement n’a pas besoin d’un framework JavaScript : WordPress ou Webflow rendent le HTML sans effort.
Senior en direct, pas de junior qui exécute. Une roadmap priorisée, du SEO Lean 20™ concentré sur ce qui rapporte, et une équipe qui repart autonome.
Crawlabilité, rendu vu par Googlebot, balises, liens, statuts HTTP et impact sur les Core Web Vitals.
Recommandation SSR, SSG ou rendu dynamique selon votre stack, avec les spécifications pour l’équipe de développement.
Chargement différé, découpage du code, réduction du JavaScript client.
Contentful ne génère pas de HTML. En headless, on ne « fait » pas le SEO dans le CMS : on modélise le contenu pour qu’il soit référençable, et le front fait le reste.
Lire la page → E-commerce SEO sur SAP Commerce Cloud (Hybris)SAP Commerce Cloud gère des millions de produits et des dizaines de sites. Son SEO se joue dans le code Java et la configuration, pas dans un plugin. J’en ai migré 23 pour le Groupe SEB.
Lire la page → Constructeurs SaaS SEO sur WebflowWebflow produit un code propre et rapide, sans plugin ni maintenance. Ses limites sont ailleurs : redirections, Schema, pagination, multilingue. Chez LumApps, c’est la plateforme que nous avons choisie pour +188 % de cARR organique.
Lire la page → Hub Toutes les technologiesCMS, e-commerce, headless, constructeurs et frameworks : ce qu’il faut savoir avant de choisir ou d’optimiser.
Voir le hub →Un pré-audit gratuit, sans engagement : je regarde votre configuration, vos pages qui rapportent et les freins techniques, puis je vous réponds sous 24 h.