Oui, Google exécute votre JavaScript. Mais pas comme vous
Je viens du développement web, alors cette conversation, je l'ai eue des deux côtés de la table. Côté développeur : « React, Vue, Angular, aucun souci, Google lit le JavaScript depuis des années. » Côté SEO, devant la Search Console du même site : des pages découvertes mais pas indexées, des descriptions vides, un trafic qui plafonne. Les deux ont raison, et c'est bien le problème.
Techniquement, le robot de Google rend les pages avec une version récente de Chromium, maintenue à jour en continu depuis 2019. Il exécute donc votre JavaScript et construit le DOM, comme le décrit la documentation officielle de Google sur le JavaScript. Sur ce point, le débat est clos.
Ce qui se joue vraiment, c'est le « comment ». Googlebot n'est pas un internaute : il ne clique sur rien, ne fait défiler aucune liste, n'attend pas indéfiniment qu'une API réponde. Il prend une photo de votre page à un instant donné, puis il indexe cette photo. Tout le SEO en JavaScript tient dans l'écart entre cette photo et ce que voit un humain.
Le rendu en deux temps, et pourquoi ça change tout
Pour comprendre les pièges, il faut visualiser la chaîne. Quand Google découvre une URL, il récupère d'abord le HTML brut envoyé par le serveur, celui d'« Afficher le code source ». Si la page a besoin de JavaScript pour afficher son contenu, elle part ensuite dans une file d'attente de rendu : un Chromium sans interface l'ouvre, exécute les scripts, et le HTML final repart vers l'indexation. J'ai détaillé la chaîne complète dans mon article sur le fonctionnement du référencement Google, du crawl au classement ; le rendu vient simplement s'intercaler au milieu.
Première conséquence, le délai : le rendu arrive après le crawl, parfois vite, parfois nettement plus tard quand le site n'est pas prioritaire. Dans l'intervalle, Google ne connaît de votre page que son HTML brut. Si c'est une coquille vide, votre page est jugée sur une coquille vide.
Ensuite le coût. Rendre une page demande beaucoup plus de ressources que lire un fichier HTML, et Google n'en alloue pas des quantités infinies à chaque site. Sur un gros site en rendu client, des pages peuvent attendre longtemps leur tour, ou être re-rendues trop rarement pour suivre vos mises à jour. Le sujet rejoint ce qu'est le budget de crawl et les cas où il mérite d'être optimisé : le rendu JavaScript est l'un des postes qui le consomment le plus vite.
La vraie question : que contient votre HTML avant JavaScript ?
Le test que je fais dans les premières minutes de n'importe quel audit : clic droit sur la page, « Afficher le code source ». Pas l'inspecteur, le code source. Si j'y trouve le titre, le texte et les liens du menu, le site part avec un HTML solide, le JavaScript ne fait qu'enrichir. Si j'y trouve une div racine vide et une pile de scripts, tout le contenu dépend de la file de rendu, avec les délais et les aléas qu'on vient de voir.
C'est la distinction entre rendu côté serveur et rendu côté client, et c'est elle qui détermine votre exposition au risque. Un site WordPress classique envoie tout son contenu dans le HTML initial : Google peut l'indexer dès la première passe. Une application montée entièrement dans le navigateur envoie une page blanche que seul le rendu complètera.
Les pièges que je retrouve dans les audits de sites en framework
Sur les sites en React, Vue ou Angular que j'audite, ce sont presque toujours les mêmes mécanismes qui coincent. Vérifiez chaque point sur votre propre site.
- Le contenu derrière une interaction : onglets, accordéons chargés au clic, boutons « voir plus », scroll infini. Googlebot ne déclenche aucun événement. Ce qui n'est pas dans le DOM au chargement n'est pas indexé, point.
- Les liens qui n'en sont pas : une div avec un gestionnaire de clic, un routeur qui change la vue sans écrire de vraie URL. Google suit les balises a avec un attribut href, et à peu près rien d'autre.
- Les routes en dièse (monsite.fr/#/produits) : pour Google, tout ce qui suit le dièse appartient à la même page. Ces « pages » n'existent pas séparément dans l'index.
- Les balises critiques injectées en JavaScript : title, description, canonical ou meta robots modifiés après coup sont pris en compte tard, ou pas du tout. Cas vicieux entre tous : un noindex présent dans le HTML initial fait sauter l'étape de rendu, donc le script censé le retirer ne s'exécute jamais.
- Les ressources bloquées : un script ou une API interdits au robot dans le robots.txt, et le rendu se fait sans eux. Résultat, une page à moitié vide dans l'index, sans erreur visible pour vous.
- Une erreur JavaScript au chargement : votre navigateur la tolère souvent, le rendu de Google peut s'arrêter net dessus.
Aucun de ces problèmes n'est une fatalité, mais aucun ne se voit en naviguant sur le site. C'est ce qui rend le sujet traître : tout fonctionne parfaitement pour les humains, alors personne ne cherche le problème.
SSR, pré-rendu, hydratation : le bon choix selon votre site
La parade porte plusieurs noms mais une seule idée : envoyer le contenu dans le HTML initial, sans attendre le rendu. Le rendu côté serveur (SSR) génère la page sur le serveur à chaque requête, c'est le mode par défaut des frameworks comme Next.js ou Nuxt. La génération statique va plus loin en fabriquant les fichiers HTML à l'avance, imbattable pour du contenu qui change peu. Dans les deux cas, le JavaScript reprend ensuite la main dans le navigateur pour l'interactivité : c'est l'hydratation. L'article de référence Rendering on the web compare bien ces approches.
Reste le pré-rendu à la volée : servir une version HTML générée aux robots, l'application classique aux humains. Google a longtemps documenté cette approche sous le nom de rendu dynamique avant de la déclasser : une rustine acceptable sur un site qu'on ne peut pas refondre, pas une architecture d'avenir.
Mon arbitrage tient en une phrase : tout ce qui doit se positionner sur Google (pages éditoriales, fiches produits, catégories) doit arriver rendu dans le HTML ; tout ce qui vit derrière une connexion (tableau de bord, espace client) peut rester en rendu client sans impact SEO. Et ce n'est pas qu'une affaire de Google : la plupart des robots des moteurs secondaires et des assistants IA n'exécutent pas ou peu le JavaScript. Un contenu servi en HTML est lisible par tout le monde, aujourd'hui et demain.
Vérifier ce que Google voit, concrètement
Pas besoin de croire sur parole, ni moi ni votre développeur. Dans la Search Console, l'inspection d'URL permet de tester une URL en direct puis d'afficher le HTML rendu tel que le robot l'a vu. Comparez-le avec votre page réelle : chaque bloc manquant est un bloc que Google n'indexera pas. Complétez avec un test simple : désactivez JavaScript dans votre navigateur et rechargez la page. Ce qui survit est votre socle garanti ; ce qui disparaît dépend de la file de rendu.
Faites ce contrôle sur trois ou quatre gabarits (accueil, catégorie, fiche, article), pas seulement sur la page d'accueil : les problèmes se nichent souvent dans un seul type de gabarit. La démarche s'insère dans une revue plus large : j'ai décrit comment mener un audit SEO technique vous-même avec des outils gratuits, et le rendu JavaScript y est un des contrôles qui rapportent le plus. Une heure de vérification vous dira de quel côté de la photo se trouve votre contenu.