Google rend-il vraiment TOUT le JavaScript, même sans contenu initial server-side ?

Pourquoi cette déclaration casse-t-elle une idée reçue tenace ?

Pendant des années, la communauté SEO a cru que Google sautait le rendu JavaScript si la page ne contenait aucun contenu HTML initial. L'hypothèse était simple : pas de contenu visible dans le HTML source, pas de rendu.

Martin Splitt balaye cette croyance. Le moteur ne conditionne pas le rendu JS à la présence de contenu server-side. Concrètement : même si votre page renvoie un HTML vide avec juste <div id="root"></div>, Google va quand même exécuter le JavaScript et indexer le contenu généré côté client.

Qu'est-ce que cette heuristique legacy dont parle Google ?

Splitt évoque une heuristique pour certains domaines legacy, sans préciser lesquels ni dans quelles conditions elle s'active. C'est typiquement le genre de formulation vague qui laisse les SEO sur leur faim.

On peut supposer qu'il s'agit de très vieux sites jamais migrés, ou de domaines connus pour des pratiques obsolètes. Mais sans données chiffrées, impossible de savoir si cette exception concerne 0,1 % ou 5 % du crawl. [A vérifier] sur le terrain avec des tests empiriques.

Cela signifie-t-il que le SSR est inutile pour le SEO ?

Non. La déclaration dit que Google rend le JS de toute façon, mais elle ne dit pas que le SSR n'apporte aucun bénéfice. Le rendu côté serveur reste un levier de performance : réduction du temps de premier affichage, meilleur passage des crawlers tiers (réseaux sociaux, agrégateurs), économie de crawl budget.

En d'autres termes : si votre site est en full CSR (client-side rendering), Google va indexer votre contenu. Mais vous perdez des opportunités d'optimisation sur la vitesse, l'UX et la compatibilité multi-plateformes. Le SSR ou l'hydratation statique restent des best practices pour les sites à fort enjeu SEO.

• Google rend pratiquement toutes les pages JS, même sans contenu HTML initial
• Une heuristique existe pour certains domaines legacy, mais son périmètre reste flou
• Le SSR n'est pas obligatoire pour l'indexation, mais il reste recommandé pour la performance et l'UX
• Ne pas confondre « Google indexe le JS » et « Google indexe tout le contenu JS sans délai ni limite »

Cette affirmation est-elle cohérente avec les observations terrain ?

Oui et non. On observe effectivement que Google indexe la majorité des contenus JS, y compris sur des SPAs totalement vides en HTML source. Mais la vraie question n'est pas « est-ce que Google rend ? », c'est « quand et avec quelle fiabilité ? ».

En pratique, le délai de rendu peut varier de quelques heures à plusieurs semaines selon le crawl budget, l'autorité du domaine, la fréquence des mises à jour. Sur un site e-commerce avec 10 000 pages JS, on constate souvent des écarts d'indexation importants entre les pages prioritaires et les fiches produits longue traîne. [A vérifier] avec des tests de monitoring réguliers.

Quelles nuances faut-il apporter à cette déclaration ?

Splitt dit « pratiquement toutes les pages » — ce « pratiquement » est crucial. Il admet implicitement qu'il existe des cas où Google ne rend pas le JS, mais il ne détaille pas lesquels. Est-ce lié au timeout du rendu ? Aux erreurs JS critiques ? Aux sites avec un robots.txt bloquant les ressources ?

Autre point : la déclaration ne parle que de la décision de rendre, pas de la qualité du rendu ni du passage en indexation. Google peut très bien rendre une page, échouer à extraire le contenu si le JS plante, ou décider de ne pas indexer le résultat si le contenu est jugé pauvre. Ce sont deux étapes distinctes du pipeline.

Dans quels cas cette règle ne s'applique-t-elle pas ?

On sait que certains contenus dynamiques chargés après interaction utilisateur (clic, scroll infini, onglets masqués) ne sont pas forcément rendus. Google simule un utilisateur basique, pas un power user qui clique partout.

De même, si votre JS génère du contenu différent selon la géolocalisation ou les cookies, Google verra une version « neutre » qui peut ne pas correspondre à la réalité de vos utilisateurs. Enfin, les sites avec des dépendances externes lentes (API tierces, CDN overloadés) peuvent voir leur rendu échouer par timeout.

Que faut-il faire concrètement si mon site est en full CSR ?

D'abord, tester l'indexation réelle. Utilisez Search Console pour vérifier que vos pages JS sont bien indexées, avec le bon contenu. L'outil d'inspection d'URL vous montre le HTML rendu tel que Google le voit — c'est votre référence terrain.

Ensuite, optimisez le temps de rendu. Même si Google rend votre JS, il le fait avec un timeout strict. Réduisez la taille des bundles, différez les scripts non critiques, utilisez le lazy loading intelligent. Chaque milliseconde compte pour garantir que le contenu stratégique est bien extrait.

Quelles erreurs éviter absolument ?

Ne vous reposez pas sur l'assertion « Google rend tout » pour négliger le contenu HTML initial. Même si Google indexe votre JS, les autres crawlers (réseaux sociaux, agrégateurs de flux, outils de monitoring) ne le feront pas. Vous perdez du trafic indirect.

Évitez aussi de bloquer les ressources JS/CSS dans le robots.txt. C'est une erreur classique qui empêche Google de rendre correctement la page. Vérifiez que tous les assets critiques sont accessibles au crawler.

Comment vérifier que mon site est correctement rendu par Google ?

Mettez en place un monitoring régulier de l'indexation. Comparez le nombre de pages soumises (sitemap XML) avec le nombre de pages indexées (Search Console). Si l'écart est important, creusez : est-ce un problème de crawl budget, de rendu, ou de qualité du contenu ?

Utilisez des outils comme Oncrawl, Botify ou Screaming Frog en mode « rendu JS activé » pour simuler le comportement de Googlebot. Comparez le contenu extrait avec et sans JS. Si vous constatez des différences majeures, c'est un signal d'alerte.

• Vérifiez l'indexation réelle de vos pages JS dans Search Console
• Optimisez le temps de rendu JS pour rester sous les timeouts de Google
• Ne bloquez jamais les ressources critiques (JS, CSS) dans le robots.txt
• Testez régulièrement avec l'outil d'inspection d'URL pour voir le HTML rendu
• Envisagez le SSR ou la pré-génération statique pour les pages stratégiques (fiches produits, landing pages)
• Surveillez les écarts entre pages soumises et pages indexées pour détecter les problèmes de rendu