SEO JavaScript : Next.js, React et Vue sans perte de positions

Les frameworks JavaScript comme Next.js, React et Vue permettent de créer des sites rapides et interactifs. Mais la technologie qui rend votre application si fluide peut aussi éroder vos positions en silence. La réponse courte : ce n’est pas le framework qui se positionne, c’est la stratégie de rendu. Dès qu’un moteur de recherche ou un crawler IA récupère votre page et n’y trouve qu’une <div id="root"> vide, vous perdez une visibilité que ni le netlinking ni le contenu ne vous rendront. Dans cet article, vous découvrez où se cachent les pièges propres à chaque framework et comment les éviter.

Pourquoi les frameworks JavaScript posent un problème SEO

Une page classique rendue côté serveur renvoie du HTML prêt à l’emploi : un bot récupère l’URL et lit immédiatement vos titres, votre texte et vos liens. Une single-page app typique fait l’inverse. Le serveur envoie une coquille HTML quasiment vide, et le contenu n’apparaît qu’une fois que le navigateur a téléchargé et exécuté le bundle JavaScript.

Google sait rendre le JavaScript, mais il le fait dans un second passage, après avoir récupéré le HTML. Ce passage de rendu coûte du temps et de la puissance de calcul, et son exécution rapide n’est garantie pour aucune page. D’autres crawlers, dont une partie des bots derrière les moteurs de recherche IA comme ChatGPT et Perplexity, ne rendent pas du tout le JavaScript ou le font de façon bien plus limitée. Pour un site B2B qui veut non seulement se positionner mais aussi être cité, le risque est double : ce qui n’est pas dans le premier HTML n’existe tout simplement pas pour une grande partie du paysage de recherche.

Ce n’est pas un débat abstrait. Cela touche au cœur du SEO : un bot peut-il lire votre contenu, le comprendre et suivre les liens vers vos pages de services ? Chez nous, chaque audit technique commence par là, parce qu’un choix de framework qui sabote le premier crawl affaiblit tous les autres efforts.

L’hydratation : le tueur silencieux

L’hydratation, c’est le processus par lequel votre framework « réveille » le HTML statique envoyé par le serveur en y attachant les écouteurs d’événements JavaScript. Le problème : une page peut sembler entièrement chargée alors qu’elle n’est pas encore interactive, parce que l’hydratation est toujours en cours.

Pour les utilisateurs, cela ressemble à une page qui se fige brièvement. Pour vos Core Web Vitals, c’est plus dommageable encore. Une hydratation lourde déplace du travail vers le thread principal et pousse votre Interaction to Next Paint et votre Largest Contentful Paint dans la mauvaise direction. Or ce sont précisément ces signaux qui pèsent dans la manière dont Google évalue l’expérience utilisateur de votre page.

Il y a plus subtil encore : les hydration mismatches. Quand le HTML rendu par le serveur ne correspond pas exactement à ce que le client attend, le framework jette la version serveur et refait le rendu depuis zéro côté client. L’effet net : vous perdez le bénéfice SEO du rendu serveur précisément sur les pages où vous en avez besoin. Ces erreurs, vous ne les voyez que rarement dans votre propre navigateur, parce qu’il finit par tout exécuter proprement. Un bot qui récupère la page une seule fois, et plus vite, voit souvent la version à moitié terminée.

La leçon pratique : envoyer moins de JavaScript au client est presque toujours meilleur pour le SEO qu’en envoyer plus. Chaque framework abordé ci-dessous offre des moyens d’y arriver, mais encore faut-il les choisir en conscience.

Next.js : puissant, mais tout se joue à la configuration

Next.js est souvent présenté comme « le choix React SEO-friendly », et à juste titre, à condition de choisir le bon mode de rendu page par page. Next.js vous laisse arbitrer, route par route, entre static generation, server-side rendering et client-side rendering, auxquels s’ajoutent les server components plus récents, qui tournent par défaut sur le serveur et envoient moins de JavaScript au client.

Le piège, c’est que cette flexibilité est aussi la façon dont tout dérape. Une erreur fréquente consiste à charger le contenu dans un useEffect : il n’apparaît alors qu’après l’hydratation et sort donc du premier HTML. Une deuxième est la mauvaise gestion des erreurs pendant le rendu serveur : une erreur non interceptée sur le serveur fait basculer Next.js vers un rendu client, et votre HTML rendu côté serveur disparaît sans bruit. Une troisième est la métadonnée définie dynamiquement côté client plutôt que côté serveur, ce qui empêche vos balises title et meta d’être reprises de façon fiable par les crawlers.

En B2B, nous recommandons en général la static generation ou le rendu serveur pour tout ce qui doit se positionner : pages de services, articles de fond, études de cas. Réservez le rendu client pur à ce qui se trouve réellement derrière un login ou une interaction. Vos pages commerciales restent ainsi lisibles dès le tout premier fetch.

React : client-side par défaut, et c’est là le risque

Une application React nue (pensez à un montage Create React App ou à un build Vite client-only) fait par défaut l’intégralité du rendu dans le navigateur. Le serveur livre une coquille vide, et sans exécution du JavaScript, un bot ne voit aucun contenu. Pour un site marketing, c’est le pire point de départ imaginable.

React ne résout pas cela tout seul ; il vous faut un framework ou une couche de rendu autour. En pratique, cela signifie utiliser React via un méta-framework comme Next.js ou Remix, ou ajouter du rendu serveur avec renderToString et votre propre serveur. Garder React purement client-side, c’est choisir implicitement le pre-rendering ou le dynamic rendering comme pansement, autant de pièces mobiles supplémentaires susceptibles de casser.

Le signal le plus lourd : si votre contenu principal n’apparaît qu’après le retour d’un appel API depuis le navigateur, vous pariez sur le fait que chaque crawler exécute votre JavaScript et attend votre API. C’est un pari à ne pas prendre sur vos pages qui rapportent. Pour savoir si votre site souffre de ce problème, il est utile de vérifier que Google indexe bien vos pages et à quoi ressemble le HTML rendu.

Vue : la même ligne de partage, d’autres noms

Vue connaît exactement la même dichotomie. Une application Vue standard fait son rendu côté client, avec les mêmes problèmes de coquille vide que React. Ici, la solution s’appelle Nuxt, le méta-framework qui apporte à Vue le rendu serveur, la static generation et le rendu hybride, un peu comme Next.js le fait pour React.

Les pièges sont parallèles : un data fetching client-only qui pousse le contenu hors du premier HTML, des hydration mismatches quand l’état serveur et l’état client divergent, et des métadonnées non définies côté serveur. Les noms changent, pas le cadre de réflexion. Si vous optez pour Vue, optez en conscience pour Nuxt avec un rendu serveur ou statique pour tout ce qui doit générer de la visibilité.

Comment évaluer un framework sur son impact pipeline

Le choix d’un framework n’est pas une affaire de goût réservée à l’équipe de développement. La question qui compte : un bot peut-il lire vos pages commerciales dès le premier fetch, sans exécuter de JavaScript ? Un test simple consiste à récupérer le code source d’une page sans rendu (par exemple via « afficher la source » ou un fetch sans JavaScript) et à vérifier que votre contenu clé, vos titres et vos liens internes y figurent.

Quelques règles empiriques que nous appliquons :

• Faites le rendu de tout ce qui doit se positionner sur le serveur ou en amont (SSR ou SSG), pas dans le navigateur.
• Gardez les métadonnées côté serveur, pour que title, meta description et canonical soient lus de façon fiable.
• Limitez le JavaScript côté client : moins d’hydratation signifie de meilleurs Core Web Vitals et moins de risques de mismatches.
• Testez avec le vrai HTML rendu, pas avec ce que votre propre navigateur finit par afficher.
• Traitez votre refonte ou votre migration comme un moment à risque, car un changement de framework est exactement l’endroit où les positions s’effondrent après une refonte de site.

Le point plus profond : chez nous, le SEO est la couche d’acquisition d’une seule machine de croissance pilotée, pas une checklist technique isolée. Un framework qui donne de belles démos mais rend vos pages de services illisibles pour les crawlers vous coûte du pipeline, pas seulement des positions dans un rapport. C’est pourquoi nous intégrons toujours le choix technique de rendu à la stratégie globale, avec les décisions connexes comme votre architecture headless CMS. Et si vous travaillez sans adresse de visite fixe tout en voulant être trouvé localement, votre approche du SEO local sans adresse physique compte autant que le rendu.

Vous vous demandez si votre site Next.js, React ou Vue est bien lisible dès le premier crawl, et si votre contenu est aussi repris par les moteurs de recherche IA ? Notre spécialiste SEO cartographie votre rendu, votre hydratation et votre indexation, et relie le tout à une croissance concrète. Prenez contact et nous regardons ensemble où fuit votre visibilité.