Un site web entièrement construit en React, Vue ou Angular a un grand avantage utilisateur : il est très rapide, très fluide, l’expérience est quasi-native. L’inconvénient SEO ? Google doit attendre que votre JavaScript s’exécute, les contenus se chargent, les appels API se complètent, avant de voir le contenu final. Pendant ce temps, Googlebot consomme de la puissance CPU, du RAM, du temps limite. Et parfois, le contenu ne charge tout simplement pas à cause d’une erreur JavaScript, et Google ne voit rien.

Pendant 10 ans (2010-2020), Google indexait principalement du HTML. JavaScript ? C’était accessoire, ignoré. Les sites 100 % JavaScript ne se classaient pas. Le changement s’est opéré progressivement. Depuis 2019, Google rend le JavaScript pour la plupart des sites. Mais « pour la plupart » n’est pas « pour tous ». Et même quand Google rend le JavaScript, il y a un délai, un coût computationnel, une limite de temps. Un site qui charge ses contenus via JavaScript prend toujours plus de temps à être crawlé et indexé qu’un site avec du HTML brut.

Chez Propuls’Lead, nous avons vu des sites perdre 60 % de leur trafic organique après une refonte en React. Pas parce que React est mauvais, mais parce que la migration n’a pas prévu le rendu côté serveur. Et aussi parce que le JavaScript avait de nouvelles dépendances externes, des appels API lents, des timeouts qui cassaient l’indexation.

Comment Google crawle le JavaScript

Le processus de crawl de Google pour un site JavaScript a trois étapes. D’abord, Googlebot crawle l’URL et récupère le HTML initial. Cette étape est gratuite, rapide, c’est du crawl standard. Ensuite, Google détecte qu’il y a du JavaScript et place la page dans une file d’attente de « rendu ». Googlebot rend le JavaScript (exécute le code, attend les appels API, construit le DOM final). Cette étape est coûteuse : elle consomme beaucoup de CPU et de ressources. Enfin, Google indexe le contenu rendu. Si le rendu a réussi, Google voit le contenu final. Si le rendu a échoué ou a timeout (dépasse le temps limite), Google indexe le HTML brut sans le JavaScript, et vous perdez le contenu rendu.

Le problème ? Googlebot a un budget limité pour le rendu JavaScript. Chaque page JavaScript rendue consomme 1 unité de « rendu budget » (c’est pas un terme officiel, mais c’est ce qu’on observe). Gogle priorise le rendu pour les pages qu’il juge importantes. Les pages de catégorie, les pages d’accueil, les pages avec beaucoup de backlinks. Les pages profondes, les contenus moins importants ? Elles peuvent attendre des jours ou des semaines avant d’être rendues. Pendant ce temps, elles restent indexées en HTML brut sans contenu JavaScript.

Rendu côté serveur (SSR) vs rendu côté client (CSR)

La solution technique pour éviter ce problème s’appelle SSR (Server-Side Rendering). Au lieu de servir au navigateur du HTML vide + du JavaScript qui construit la page, le serveur exécute le JavaScript et envoie directement le HTML rendu (avec le contenu final). Le navigateur reçoit une page complète avec le contenu déjà là. Google crawle du HTML brut avec du contenu. Pas d’attente, pas de rendu, pas de problème.

CSR (Client-Side Rendering) est l’opposé : le serveur renvoie du HTML vide (juste les scripts), le navigateur exécute le JavaScript et affiche le contenu. Pour l’utilisateur, c’est transparent. Pour Google, c’est du travail supplémentaire.

Propuls’Lead recommande SSR pour tous les sites qui visent le SEO. Next.js (React), Nuxt (Vue), les frameworks modernes offrent tous SSR natif. Si vous utilisez React ou Vue, utilisez un framework qui supporte SSR. Ne construisez pas un site 100 % CSR pour le SEO.

Hydratation et contenu manquant

Un problème courant avec les sites JavaScript est la « famine d’hydratation » (hydration starvation). L’hydratation, c’est quand le JavaScript côté client synchronise son état avec le HTML rendu côté serveur. Si cette synchro échoue, le contenu dynamique disparaît. Google voit du HTML rendu côté serveur avec le contenu A, mais le navigateur reçoit le contenu B après hydratation. C’est un bogue qui tue le SEO.

Propuls’Lead a debuggué un site Next.js où le contenu des articles était rendu côté serveur mais disparaissait après hydratation parce que l’application hydratait avec des données provenant d’une API différente. Le contenu disparaissait 3 secondes après le chargement. Google voyait un article complet. L’utilisateur voyait un article vide. Catastrophe SEO sans que le propriétaire du site le sache.

Contenu chargé via API asynchrone

Beaucoup de sites JavaScript chargent le contenu via API asynchrone. Le HTML arrive vide, puis une requête API fetch récupère les données (articles, produits, commentaires), et le JavaScript affiche les données. Google peut attendre cette API, mais avec des limites. Il attend environ 5 à 10 secondes. Si votre API prend 15 secondes, Google ne l’attend pas et indexe le HTML vide.

Pour Propuls’Lead, la solution est le préchargement côté serveur. Chargez les données de l’API côté serveur pendant le rendu, injectez-les dans le HTML, et pas d’appel API côté client pour le contenu critique. Gardez les appels API pour les contenus non essentiels (recommandations, commentaires, suggestions). Une bonne implémentation de lazy loading peut aussi optimiser le chargement des ressources sans penaliser Google.

Core Web Vitals et JavaScript

JavaScript mal implémenté tue vos Core Web Vitals. Un site qui charge 2 MB de JavaScript et l’exécute sur chaque page aura un INP (Interaction to Next Paint) lent parce que la main thread du navigateur est occupée à interpréter et exécuter le code. Google utilise les Core Web Vitals comme signal de classement depuis 2021. Donc JavaScript lent = mauvais Core Web Vitals = mauvais classement, mécaniquement.

Propuls’Lead mesure toujours la taille du JavaScript et l’INP avant une migration vers une stack JavaScript. Si vous passez de WordPress statique (200 KB de JS total) à Next.js personnalisé (2 MB de JS), vous perdrez du classement même si le contenu est identique. Les trois Core Web Vitals affectés par le JavaScript sont : LCP (Largest Contentful Paint, le temps avant que le plus gros élément visible ne charge), INP (le temps de réaction du site aux interactions utilisateur), CLS (Cumulative Layout Shift, la stabilité visuelle). Un script JavaScript qui se charge après le rendu et qui modifie la layout crée du CLS. Un script qui bloque l’exécution ralentit l’INP. Un site qui charge du JavaScript avant les contenus critiques ralentit le LCP.

La solution technique est à trois niveaux : (1) Code splitting (charger le JS par page, pas tout à la fois), (2) lazy loading (charger le JS quand l’utilisateur en a besoin), (3) minification agressive et compression gzip. Pour les sites de Propuls’Lead, nous visons un bundle JavaScript de moins de 100 KB (gzipped) pour la page d’accueil et 50 KB par page additionnelle. C’est faisable avec une bonne architecture. Pour vérifier ces éléments, consultez notre audit SEO technique qui inclut une checklist de vérifications JavaScript.

Quand JavaScript est acceptable pour le SEO

JavaScript n’est pas interdit pour le SEO. Google rend le JavaScript sur la plupart des sites modernes. Mais il y a des conditions strictes. Première condition : le contenu critique doit être en HTML. Les titres, les paragraphes, les descriptions de produits doivent être dans le HTML côté serveur, pas chargés en JavaScript asynchrone. Deuxième condition : le JavaScript ne doit pas causer de rechargements ou de flashing de contenu qui désoriente l’utilisateur ou confond Google. Troisième condition : les appels API doivent être rapides (moins de 3 secondes). Quatrième condition : le code doit être testé sur de vraies conditions de réseau lent (3G sur le terrain), pas juste sur une connexion fiber du bureau.

Propuls’Lead utilise Next.js SSR (Server-Side Rendering) pour la plupart de ses sites modernes. Next.js mélange SSR (contenu critique rendu serveur) et CSR (contenu non critique chargé client), c’est le meilleur des deux mondes. Votre article blog est rendu côté serveur, Google le voit complètement et immédiatement. Les commentaires, les suggestions d’articles liés, les widgets sociaux, se chargent côté client après le rendu initial (Google peut les voir mais ce n’est pas critique pour l’indexation). Cette stratégie hybride donne à Google tout le contenu important en HTML, et aux utilisateurs une expérience fluide et réactive. Les balises HTML essentielles doivent toujours être présentes et bien structurées, indépendamment du framework JavaScript utilisé.

L’alternative est Astro ou 11ty si vous préférez un site statique généré au build time. Ces outils génèrent du HTML pur zéro JavaScript par défaut, ce qui est parfait pour le SEO si vos contenus ne changent pas en temps réel. Pour un site e-commerce avec inventaire dynamique ou un site d’actualités actualisé en permanence, SSR (Next.js, Nuxt) est nécessaire.

Sources

JavaScript SEO — Google Search Central

Rendering strategies : CSR vs SSR — Web.dev

Core Web Vitals et JavaScript — Google Developers

Next.js et SEO — Vercel Documentation

JavaScript et SEO : pourquoi les sites trop dynamiques posent problème à Google