SEO et JavaScript : SSR, SSG, hydratation — ce qui compte vraiment pour l'indexation

« Google exécute JavaScript, donc mon application React/Vue est indexée comme n'importe quel site. » C'est vrai en théorie, incomplet en pratique — et cette incomplétude fait vivre un débat permanent entre équipes front et référenceurs. Posons ce que l'on sait, ce qui relève du risque mesuré, et comment décider sans dogme.

Ce que fait réellement Googlebot

Google indexe en deux temps. Le premier passage lit le HTML renvoyé par le serveur. Si la page nécessite JavaScript pour afficher son contenu, elle entre dans une file de rendu : un Chrome headless l'exécutera plus tard — quelques minutes à parfois beaucoup plus, selon le site et les ressources que Google lui accorde. Le contenu rendu en JavaScript finit donc indexé dans la grande majorité des cas, mais :

• plus tard — pénalisant pour les contenus frais (actualités, annonces, stocks) ;
• à condition que tout se passe bien — un script bloqué par robots.txt, une erreur d'exécution, un contenu chargé au scroll ou après interaction, et la page indexée est vide sans que rien ne l'indique ;
• pour Google surtout — les autres moteurs, les aperçus de liens (réseaux sociaux, messageries) et une partie des crawlers d'IA lisent beaucoup moins bien le JavaScript, voire pas du tout.

Les quatre stratégies de rendu

L'hydratation — le moment où le JavaScript « prend le relais » du HTML serveur — ne concerne pas l'indexation du contenu, mais la performance (INP) : un site SSR mal hydraté est indexé correctement et désagréable à utiliser. Ce sont deux problèmes distincts.

Choisir selon la nature des pages, pas par principe

La bonne question n'est pas « SSR ou pas ? » globalement, mais quelles pages vivent du trafic de recherche ?

• Pages publiques dont le SEO est un canal d'acquisition (fiches produit, articles, pages services, annonces) : le contenu doit être dans le HTML initial. SSR ou SSG selon la fréquence de mise à jour — un blog se génère très bien en statique, un stock temps réel non.
• Application derrière connexion (tableau de bord, back office) : aucun enjeu d'indexation, le rendu client pur est parfaitement adapté — y investir du SSR est du sur-coût sans bénéfice.
• Le cas mixte est la norme : un SaaS a une vitrine et un produit. Les frameworks actuels (Nuxt, Next, SvelteKit…) permettent de régler la stratégie route par route ; c'est leur vrai apport.

Vérifier plutôt que croire

Deux contrôles en cinq minutes disent la vérité sur votre site :

# Le contenu essentiel est-il dans le HTML serveur ?
curl -s https://www.exemple.fr/services/audit | grep -c "Audit de performance"
# 0 = ce texte n'existe que via JavaScript

Et dans la Search Console, l'inspection d'URL montre le rendu et le HTML tels que Google les obtient — y compris les ressources bloquées et les erreurs de script. Si une information doit être indexée, elle doit apparaître dans ce HTML rendu ; sinon, le débat théorique est clos par le fait.

Ce qu'il faut retenir

Le rendu JavaScript n'est ni un péché SEO ni un non-sujet : c'est un risque et un délai, à accepter là où l'indexation n'a pas d'enjeu, à éliminer là où elle en a un. La règle pratique que nous appliquons : contenu destiné à la recherche → présent dans le HTML initial (SSR/SSG) ; application connectée → rendu client sans état d'âme. Et dans tous les cas, une vérification factuelle (curl + inspection d'URL) vaut mieux que toutes les convictions d'équipe.