« Google n'exécute pas le JavaScript. » Cette phrase, on me la sort encore en 2026, généralement par quelqu'un qui a lu un article de 2017 et qui a arrêté de se mettre à jour. Spoiler : c'est faux depuis des années. Le rendu JavaScript pour le SEO n'est plus une question de « est-ce que Google voit mon contenu », mais de « quand est-ce qu'il le voit, et est-ce qu'il s'embête à le faire ».
La nuance change tout. Parce que oui, Googlebot lit vos SPA. Il les lit même avec un vrai navigateur. Mais il les lit en différé, dans une file d'attente, et c'est précisément là que la moitié des sites en React ou Vue se tirent une balle dans le pied sans s'en rendre compte.
Sous le capot : Chromium headless qui tourne en vrai#
Quand Google rend une page, il n'utilise pas un parseur HTML maison qui ignore les scripts. Il utilise une version headless de Chromium. La doc officielle est explicite là-dessus : Google « uses an evergreen version of Chromium to process JavaScript ». Le terme WRS (Web Rendering Service) que les SEO balancent partout, c'est juste un raccourci communautaire pour désigner ce truc.
« Evergreen », ça veut dire que le moteur se met à jour en continu. Concrètement, les fonctionnalités JS modernes (ES modules, async/await, et compagnie) finissent par être supportées sans que Google annonce une date précise de déploiement. C'est un vrai Chrome, pas une version d'il y a cinq ans. Donc non, votre framework dernier cri ne va pas casser à cause d'un moteur préhistorique.
Le piège n'est pas dans la capacité de rendu. Il est dans le timing.
Les trois phases : crawl, rendu, indexation#
La plupart des gens imaginent que Google fait tout en un passage : il arrive, il lit, il indexe. C'est plus tordu que ça. Le process se découpe en trois étapes distinctes.
D'abord le crawl : Googlebot vérifie le robots.txt, puis récupère la ressource en HTTP. Ensuite le rendu : toutes les pages avec un statut HTTP 200 partent en file d'attente pour être rendues par le Chromium headless. Enfin l'indexation : le HTML obtenu après exécution du JavaScript est analysé et indexé.
Le détail qui tue, c'est la file d'attente. La doc dit que la page « may stay on this queue for a few seconds, but it can take longer ». Combien de temps exactement ? Google ne donne aucun chiffre. Pas d'heures, pas de jours, rien de précis. « Quelques secondes, parfois plus. » C'est tout ce qu'on a, et honnêtement, je préfère ça à un chiffre bidon qui traînerait sur dix blogs SEO recopiés les uns sur les autres.
Ce que ça implique : avec un site en rendu côté serveur, votre contenu est dispo dès le crawl. Avec un site qui dépend du JS pour afficher quoi que ce soit, il faut attendre que la page sorte de cette file. Et tant qu'elle y est, votre contenu n'existe pas pour l'index.
Petit rappel au passage : si votre JavaScript est bloqué par robots.txt, c'est mort. « Google Search won't render JavaScript from blocked files or on blocked pages. » Bloquez vos fichiers JS et CSS dans le robots.txt, et Googlebot rend une page vide. Ça arrive plus souvent qu'on croit. C'est même un classique des migrations bâclées. Vérifiez ce point avant de vous arracher les cheveux sur le reste.
SSR, CSR, SSG, hydration : le match qui décide de votre indexation#
C'est là que ça se complique et que les choix d'architecture pèsent vraiment. Quatre stratégies, quatre comportements face à Googlebot.
Le SSR (Server-Side Rendering) envoie du HTML au client plutôt que du JavaScript. La page est générée côté serveur, le navigateur reçoit du contenu prêt à lire. FCP rapide, TBT réduit, et surtout : pas de dépendance à la file de rendu. La doc Google le dit sans détour, le pré-rendu serveur « makes your website faster for users and crawlers, and not all bots can run JavaScript ». Parce que oui, tous les bots ne sont pas Google. Bing, les crawlers IA, les bots sociaux qui génèrent vos aperçus de partage : beaucoup ne rendent pas le JS du tout.
Le CSR (Client-Side Rendering) fait l'inverse : le navigateur reçoit du JavaScript qui fabrique le DOM à la volée. C'est le mode par défaut d'une SPA classique. Problème : tant que le JS n'a pas fini de s'exécuter, le contenu n'existe pas. FCP lent, TTI à la traîne, et « the amount of JavaScript required tends to grow as an application grows ». Indexable par Google ? Oui. Mais via la file de rendu, avec son délai variable et non garanti.
Le SSG (Static Site Generation) génère le HTML au build, un fichier par URL. TTFB ultra-rapide et constant, parce qu'il n'y a rien à générer dynamiquement. Cacheable sur CDN. La limite : « It must generate individual HTML files for every possible URL. » Inadapté aux contenus dynamiques à très grande échelle, mais imbattable pour un blog ou un site vitrine.
L'hydration, c'est l'hybride à la mode. On envoie du HTML rendu côté serveur, puis le JS client « réveille » la page pour la rendre interactive. Sur le papier, le meilleur des deux mondes. En pratique, web.dev appelle ça « one app for the price of two » : la page « look ready but none of its interactive features work » jusqu'à ce que le JS client ait fini son boulot. Et là, attention : « It can have a significant negative impact on TBT and INP, even if it improves FCP. » Vous gagnez en visibilité, vous pouvez perdre en interactivité mesurée.
Si je devais résumer le rapport TTFB / FCP / INP par stratégie :
| Stratégie | TTFB | FCP | TBT / INP |
|---|---|---|---|
| SSR | Moyen-lent | Rapide | Bon |
| CSR | Rapide | Lent | Mauvais |
| SSG | Rapide | Rapide | Bon |
| SSR + hydration | Moyen | Rapide | Variable (risque TBT) |
Pour creuser le volet performances pure, on a un guide dédié sur optimiser LCP, CLS et INP en 2026. Et si la partie file d'attente vous inquiète, l'indexation retardée pour les petits sites explique pourquoi tout le monde n'est pas logé à la même enseigne.
Le dynamic rendering ? Mort et enterré#
Pendant un temps, Google recommandait le « dynamic rendering » : servir une version pré-rendue aux bots, la SPA normale aux utilisateurs. En 2026, oubliez. La page officielle s'appelle carrément « Dynamic rendering as a workaround », et la doc enfonce le clou : « Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. »
À la place, Google recommande trois trucs : server-side rendering, static rendering, hydration. Dans cet ordre. Petite précision utile pour les paranos du cloaking : « Googlebot generally doesn't consider dynamic rendering as cloaking », à condition que le contenu servi aux bots et aux humains reste substantiellement identique. Mais peu importe, c'est déprécié, ne construisez plus rien dessus.
Les six pièges qui sabotent une SPA#
Voilà où la plupart des sites JS se plantent. Du vécu, pas de la théorie.
Le soft 404 d'abord. Une SPA avec routage client peut renvoyer un HTTP 200 pour une URL qui n'existe pas. Google déteste ça. La solution propre : rediriger en JavaScript vers une URL qui renvoie un vrai 404, ou poser un <meta name="robots" content="noindex"> sur la page d'erreur.
Le hash routing ensuite. Les URLs avec # ne sont pas crawlées de façon fiable. Utilisez l'History API (window.history.pushState()), pas les fragments. C'est non négociable.
Le canonical injecté par JS. Google prévient : ne « shouldn't use JavaScript to change the canonical URL to something else than the URL you specified ». Mettez votre canonical en HTML statique, point.
Les liens non crawlables. Vos liens doivent vivre dans des balises <a href>. Un div cliquable avec un onClick, Googlebot ne le suit pas de façon fiable. Ça paraît évident, et pourtant.
Le noindex et le JS. Google « may skip rendering » quand il détecte un noindex. Donc votre JavaScript ne peut pas retirer ou modifier de façon fiable un noindex posé côté serveur. Si la balise est là au crawl, le rendu peut ne jamais arriver.
Enfin les Web Components. Bonne nouvelle pour une fois : le contenu dans le Shadow DOM est aplati et indexé s'il est visible. Pas de piège ici, juste à savoir.
Le mot de la fin#
Le vrai sujet, ce n'est pas « est-ce que Google lit mon JavaScript ». La réponse est oui depuis longtemps. Le vrai sujet, c'est de ne pas dépendre d'un rendu différé et incertain pour du contenu que vous voulez voir indexé vite et bien.
Mon conseil tranché : SSR ou SSG par défaut, hydration seulement si vous maîtrisez le coût en INP, CSR pur uniquement pour des écrans applicatifs derrière un login que vous ne voulez de toute façon pas indexer. Et testez toujours le HTML rendu, pas le HTML brut, avec l'outil d'inspection d'URL de la Search Console. Si vous voulez auditer le reste de votre stack technique, notre checklist SEO technique 2026 couvre les 50 points à vérifier.
Le JavaScript n'est pas l'ennemi du SEO. Une architecture qui ignore comment Googlebot fonctionne, par contre, ça oui.
