L’essentiel
- Le rendu JavaScript est l'étape où Google exécute le code JS pour voir le contenu final d'une page
- Googlebot crawle d'abord le HTML brut, puis rend le JavaScript dans un second temps
- Ce processus en deux étapes peut retarder l'indexation du contenu généré en JS
- Les frameworks SPA (React, Angular, Vue) sont particulièrement concernés
- Le Server-Side Rendering (SSR) est la solution la plus fiable pour le SEO
Comment Google traite le JavaScript#
Google utilise un processus en deux phases pour traiter les pages qui dépendent du JavaScript :
- Phase de crawl : Googlebot télécharge le HTML brut de la page. À ce stade, il voit uniquement ce qui est présent dans le code source initial, avant l’exécution de tout script.
- Phase de rendu : la page est placée dans une file d’attente, puis le Web Rendering Service (WRS) de Google exécute le JavaScript avec une version de Chromium. C’est à ce moment que le contenu généré dynamiquement devient visible pour Google.
Le problème réside dans le délai entre ces deux phases. La file d’attente de rendu dépend des ressources que Google alloue à votre site, autrement dit, de votre crawl budget. Dans la plupart des cas, Google indique que le rendu intervient rapidement après l’exploration. Sur de gros sites qui dépendent entièrement du JavaScript, le décalage peut être plus long et retarder la prise en compte des nouveaux contenus.
Pourquoi le rendu JavaScript pose problème en SEO#
Si votre contenu principal (texte, liens internes, données structurées) dépend du JavaScript pour s’afficher, vous prenez plusieurs risques :
- Indexation retardée : le contenu n’apparaît dans l’index qu’après le rendu, pas après le crawl. Les nouvelles pages ou les mises à jour de contenu mettent plus de temps à être prises en compte.
- Contenu invisible : si le rendu échoue (erreur JS, timeout, ressource bloquée par le robots.txt), Google indexe une page vide ou incomplète.
- Liens internes non détectés : les liens générés dynamiquement en JS ne sont découverts qu’au moment du rendu. Cela peut créer des pages orphelines du point de vue du crawl initial.
- Coût en crawl budget : Google doit à la fois télécharger le HTML, les fichiers JS, les appels API, puis exécuter le tout. C’est beaucoup plus coûteux qu’une page HTML statique.
Les stratégies de rendu pour le SEO#
Trois approches principales existent pour gérer le rendu JavaScript dans une optique SEO :
Server-Side Rendering (SSR)#
Le serveur exécute le JavaScript et envoie le HTML complet au navigateur (et à Googlebot). C’est la solution la plus fiable pour le SEO : le contenu est immédiatement visible dans le code source, sans attendre de phase de rendu. Des frameworks comme Next.js (React) ou Nuxt (Vue) facilitent la mise en place du SSR.
Static Site Generation (SSG)#
Les pages sont pré-générées en HTML au moment du build, puis servies comme des fichiers statiques. Idéal pour les sites dont le contenu ne change pas à chaque requête (blogs, documentations, catalogues stables). Les performances sont excellentes et le crawl est optimal.
Dynamic Rendering#
Le serveur détecte si la requête vient d’un bot ou d’un utilisateur, et sert une version pré-rendue aux robots de recherche. Google a longtemps recommandé cette approche comme solution de contournement, mais la considère désormais comme un palliatif temporaire. Le SSR ou le SSG restent préférables à long terme.
| Stratégie | SEO | Complexité | Cas d’usage |
|---|---|---|---|
| SSR | Excellent | Moyenne | Applications web dynamiques |
| SSG | Excellent | Faible | Blogs, docs, sites vitrines |
| Dynamic Rendering | Bon (temporaire) | Élevée | Migration progressive |
| Client-Side Rendering seul | Risqué | Faible | Apps privées (derrière login) |
Vérifier si Google rend correctement votre JavaScript#
Pour savoir ce que Google voit réellement sur vos pages, utilisez l’outil d’inspection d’URL dans Google Search Console. Cliquez sur « Afficher la page explorée » puis comparez l’onglet HTML et la capture d’écran rendue. Si le contenu principal est absent du HTML mais visible sur la capture, votre contenu dépend du rendu JavaScript.
Autre test rapide : désactivez JavaScript dans votre navigateur et rechargez votre page. Ce que vous voyez correspond approximativement à ce que Googlebot voit lors de la phase de crawl initiale. Si la page est vide ou incomplète, il y a un problème de dépendance au JS.
Rendu JavaScript et moteurs IA#
Google rend le JavaScript, mais ce n’est pas le cas de tous les robots. Plusieurs robots des moteurs IA, comme ceux d’OpenAI ou d’Anthropic, lisent surtout le HTML initial. Un contenu affiché uniquement après exécution du JavaScript risque de leur échapper. Servir le contenu principal et les liens dans le HTML (SSR ou SSG) règle la question pour tous les robots à la fois. Voir la fiche GEO et mon audit SEO technique.
Questions fréquentes#
Google peut-il exécuter tout le JavaScript ?
Google utilise une version récente de Chromium pour le rendu, ce qui lui permet d’exécuter la plupart du JavaScript moderne. Cependant, certains cas restent problématiques : les scripts qui nécessitent une interaction utilisateur (clic, scroll), les timeouts trop longs, ou les ressources bloquées par le robots.txt.
Un site en React ou Angular est-il pénalisé par Google ?
Pas directement pénalisé, mais plus risqué si le rendu n’est pas géré correctement. Un site React en Client-Side Rendering pur oblige Google à rendre chaque page, ce qui ralentit l’indexation. Avec du SSR ou du SSG, le problème disparaît.
Le Dynamic Rendering est-il du cloaking ?
Non. Google distingue le Dynamic Rendering du cloaking car le contenu servi est identique, seul le format diffère (HTML pré-rendu vs JS à exécuter). En revanche, si vous servez un contenu différent aux robots et aux utilisateurs, cela devient du cloaking.