JavaScript et SEO : ce que Google voit vraiment de votre site
Clic droit sur la page, « afficher le code source ». Une balise <div id="root"> vide, trois balises <script>, rien d'autre.
Ouvrez l'inspecteur du navigateur au même instant. Un article de deux mille mots, un fil d'Ariane, douze liens internes. Le contenu existe.
Il n'est simplement pas là où le premier robot venu ira le chercher.
C'est toute la question du SEO JavaScript. Pas « Google sait-il lire le JS ? », il sait. Mais « qui d'autre le lit, à quel prix, et que se passe-t-il quand ça casse ? »
La question concerne à peu près tout le monde : 98,9 % des sites web utilisent JavaScript côté client, selon le relevé W3Techs d'août 2026 sur le top 10 millions de sites. Ce qui change d'un site à l'autre, ce n'est pas l'usage du JS, c'est le moment où il s'exécute.
En 2026, la réponse a bougé, et pas dans le sens que raconte la moitié des articles sur le sujet.
Ce que Googlebot fait vraiment de votre JavaScript
La documentation de Google est explicite : « Google traite les applications Web JavaScript en trois phases principales : 1. Exploration 2. Affichage 3. Indexation. » Trois étapes distinctes, et c'est la deuxième qui pose problème.
À l'exploration, Googlebot récupère le fichier HTML brut. Exactement ce que vous voyez dans « afficher le code source ». Sur un site rendu côté client, ce fichier est presque vide.
La page part alors dans une file d'attente. Google ouvre un Chromium headless, un navigateur Chrome sans interface, piloté par la machine. Le JavaScript s'exécute là, et construit le DOM, la version finale de la page telle qu'un visiteur la voit. C'est le rendu.
L'indexation vient après. Google n'indexe pas le code source : il indexe le rendu final d'une page, une fois le code JavaScript exécuté.
Comment Google arbitre-t-il entre ces trois phases ? Il les découple. Le contenu généré par JavaScript entre donc dans l'index avec un temps de retard sur le HTML servi directement. Et tout ce qui casse l'exécution du JS casse l'indexation, sans message d'erreur nulle part.
La règle vaut pour tout contenu injecté après coup. Un balisage de données structurées généré en JavaScript est lu au rendu, pas à l'exploration, donc plus tard, et seulement si le script s'exécute correctement.
Le reste des bonnes pratiques du SEO JavaScript documentées par Google découle de là. Rien d'ésotérique : servir le bon code d'état HTTP, ne pas bloquer les ressources, poser des liens que le robot puisse suivre.
Rendu et indexation : le délai n'est pas celui qu'on vous a raconté
Deux récits circulent en français. Le premier annonce des délais de plusieurs semaines. Le second parle d'une limite de cinq secondes au-delà de laquelle Google abandonne. Les deux sont faux.
Vercel et MERJ ont mesuré le comportement réel de Googlebot pendant un mois complet, en avril 2024. Sur plus de 100 000 récupérations de Googlebot, 100 % des pages HTML ont donné lieu à un rendu complet, y compris les pages à interactions JavaScript complexes.
Le délai entre exploration et rendu, lui, se distribue ainsi : 4 secondes au 25e centile, 10 secondes à la médiane, 26 secondes au 75e centile. Le 90e centile grimpe à environ 3 heures.
Une réserve honnête sur ce chiffre : l'échantillon principal est nextjs.org, un site à forte autorité et techniquement irréprochable. L'étude prouve que Google sait rendre du JavaScript à grande échelle. Elle ne prouve pas que votre site sera traité aussi bien.
Ces chiffres cachent une asymétrie de coût. Récupérer un fichier HTML est quasi gratuit pour Google ; ouvrir un navigateur et exécuter des scripts ne l'est pas.
Sur un site de trente pages, personne ne le remarque. Sur un catalogue de cinquante mille URL, ce coût se traduit en fréquence de passage. Les pages profondes sont revisitées plus rarement, et vos mises à jour mettent plus longtemps à remonter dans l'index.
C'est là que le budget de crawl entre dans la discussion, pas comme une pénalité, comme une file d'attente qui s'allonge.
Ce que ça change en pratique : arrêtez de chercher le coupable du côté de la recherche Google. Si les pages de votre site web n'apparaissent pas, le problème est presque toujours dans votre code.
CSR, SSR, SSG : l'arbitrage qui décide de votre référencement
Trois façons de fabriquer une page web, trois contrats différents avec les moteurs de recherche.
Le rendu côté client, ou CSR, envoie un HTML vide et laisse le navigateur tout construire. Le rendu côté serveur, ou SSR, exécute le JavaScript sur le serveur et envoie une page HTML déjà complète. La génération statique, ou SSG, produit ces pages une fois pour toutes au moment du build et les sert depuis un CDN.
| Critère | CSR | SSR | SSG |
|---|---|---|---|
| Contenu dans le HTML initial | Non | Oui | Oui |
| Visible par les crawlers IA | Non | Oui | Oui |
| Coût d'infrastructure | Le plus faible | Le plus élevé | Faible |
| Contenu qui change souvent | Adapté | Adapté | Rebuild nécessaire |
| Contenu personnalisé ou connecté | Adapté | Adapté | Inadapté |
| Effort de migration depuis un SPA | — | Élevé | Moyen |
Le tableau se lit de haut en bas, pas de gauche à droite. Il n'y a pas de gagnant.
Un tableau de bord derrière authentification n'a rien à gagner au SSG : ses pages sont personnalisées et rien n'oblige à les indexer. Un blog ou une documentation, à l'inverse, gagne tout au statique.
La question utile n'est donc pas « quel est le meilleur rendu ». Elle est plus simple : quelles pages de votre site web doivent exister dans un index public ?
La réponse dicte l'architecture, page par page. Beaucoup d'applications JavaScript gagnent à mélanger les trois modes.
React, Angular, Vue : où le problème SEO se pose vraiment
Aucun de ces frameworks n'est mauvais pour le référencement. C'est la configuration de rendu qui décide, et elle est indépendante du framework.
Un projet React en génération statique et un projet React en rendu client sont deux sites différents pour Google. Même bibliothèque, même code applicatif, résultat opposé dans l'index.
C'est précisément pour ça que Next.js et Nuxt existent. Ils ajoutent le rendu serveur et la génération statique par-dessus React et Vue. Angular fait la même chose avec son moteur de rendu serveur intégré.
Le piège que je vois le plus souvent en audit n'est pas le choix du framework. C'est un projet démarré en CSR par défaut, jamais rebasculé, sur lequel personne n'a rouvert le sujet depuis la mise en production.
Le symptôme est reconnaissable. L'équipe a bien installé Next.js, mais chaque page utile est marquée en rendu client parce qu'elle appelle une API au montage du composant. Le framework est capable de servir du HTML complet ; la façon dont les données sont chargées l'en empêche.
Un sitemap XML limite les dégâts en attendant. Quand le maillage repose sur des composants que le robot ne sait pas suivre, le sitemap devient son seul chemin de découverte. C'est un filet de sécurité, pas une réparation.
Cinq erreurs de balises et d'URL qui cassent le rendu
Le rendu échoue rarement en bloc. Il échoue par endroits, silencieusement, et les blocages techniques invisibles que ça produit ne remontent dans aucun rapport.
Les fichiers .js bloqués dans le robots.txt. Une règle Disallow héritée d'une ancienne version suffit. Google ne peut plus charger les scripts dont il a besoin, rend une page cassée, et l'indexe telle quelle.
Les liens sans attribut href. Google est catégorique : il ne découvre vos liens que s'il s'agit d'éléments HTML <a> avec un attribut href. Un <div onClick={navigate}> fonctionne pour l'utilisateur et n'existe pas pour le robot. Toute une section du site peut rester invisible pour cette seule raison.
Le noindex manipulé en JavaScript. C'est le plus vicieux des cinq. Si Google détecte une balise noindex dans le HTML initial, il peut ignorer l'affichage et l'exécution du JavaScript.
Votre script qui devait la retirer ne s'exécutera donc jamais. La page reste désindexée, sans que rien ne l'explique.
La balise canonique en double. Google récupère bien l'URL canonique insérée pendant le rendu. Encore faut-il qu'elle soit la seule sur la page. Un canonical dans le HTML plus un autre injecté par le JS, et le signal devient contradictoire.
Les soft 404 dans les applications monopages. Une route inexistante affiche « page introuvable » en JavaScript, mais le serveur a répondu 200. Google indexe des dizaines de pages d'erreur comme du contenu valide.
Ces cinq erreurs ont un point commun : le site fonctionne parfaitement pour un humain. Seuls les robots voient la casse.
Les moteurs de recherche IA ne rendent pas une ligne de votre JavaScript
Voilà le vrai déplacement, et il est presque absent des articles français sur le sujet.
Vercel a mesuré le comportement de GPTBot, ClaudeBot et PerplexityBot sur son réseau, en décembre 2024. Le résultat est net : ces robots téléchargent des fichiers JavaScript sans jamais les exécuter.
11,50 % des requêtes pour le crawler de ChatGPT, 23,84 % pour celui de Claude. Ils récupèrent les scripts et s'arrêtent là.
Ce qu'ils voient d'un site en rendu client, c'est le HTML brut. Une balise <div> vide.
La conséquence est brutale. Votre contenu n'est pas « moins bien classé » dans ChatGPT ou Claude : il n'y existe pas. Sur une requête où votre expertise devrait faire autorité, un concurrent en HTML servi sera cité à votre place.
Une exception : Gemini s'appuie sur l'infrastructure de rendu de Googlebot et exécute donc le JavaScript, avec les mêmes délais.
Le rendu serveur cesse d'être une optimisation de performance. Il devient une condition d'existence dans les moteurs de recherche génératifs.
Le poids de votre bundle se paie deux fois
Un bundle lourd, le paquet de fichiers JavaScript que le navigateur télécharge, ne coûte pas qu'en secondes de chargement.
Les ordres de grandeur ont dérivé. Le relevé HTTP Archive de juillet 2025 donne 632 Ko de JavaScript sur la page d'accueil médiane en mobile, pour 2,56 Mo au total.
Dix ans plus tôt, la page mobile médiane pesait 845 Ko en tout. Le Web Almanac, qui apparie les deux relevés, mesure 2 362 Ko en juillet 2025 : quel que soit le compteur, la page a triplé.
Le premier coût est visible : le contenu s'affiche plus tard, sur des connexions plus lentes que celle de votre poste de développement.
Le second est passé inaperçu chez beaucoup d'équipes. Depuis mars 2024, Google mesure la réactivité avec l'INP (Interaction to Next Paint), qui a remplacé l'ancien FID.
L'INP observe chaque interaction de la visite, pas seulement la première, et il compte le temps d'exécution de vos scripts. Le seuil à tenir est de 200 millisecondes.
Autrement dit : le JavaScript qui bloquait le fil d'exécution après le premier clic échappait à l'ancienne métrique. Il ne lui échappe plus.
Sur ce site, ramener le CLS de 0,255 à 0 et le score Lighthouse de 78 à 93 n'a rien demandé d'exotique. Réserver l'espace des éléments avant leur chargement, différer ce qui n'est pas nécessaire au premier rendu, supprimer deux dépendances devenues inutiles.
Cinq vérifications de SEO technique sur un site JavaScript
Ce diagnostic ne demande pas d'accès au code. Vingt minutes suffisent, et c'est ce genre de protocole reproductible qui sépare une vraie expertise SEO technique d'un rapport d'outil recopié.
- Comparez le code source et le DOM.
view-source:votredomaine.comd'un côté, l'inspecteur de l'autre. Si le texte de votre page n'apparaît que dans le second, vous êtes en rendu client. - Désactivez JavaScript dans Chrome. Menu des paramètres du site, JavaScript sur « bloquer », rechargez. Ce qui reste à l'écran sans JavaScript est le socle sur lequel travaillent les robots les plus limités.
- Passez par l'inspection d'URL de la Google Search Console. Testez l'URL en direct, puis ouvrez l'onglet du HTML rendu. C'est littéralement ce que Google a vu après exécution des scripts.
- Lancez un
curlbrut sur la page.curl -s votredomaine.com/une-page. Le résultat est exactement ce qui parvient à GPTBot et à ClaudeBot. - Crawlez deux fois, avec et sans rendu JavaScript. Screaming Frog le fait nativement. Un écart important dans le nombre d'URL découvertes signale un maillage interne construit sans balises
<a href>.
Quand les cinq tests concordent, il n'y a pas de problème de rendu. Quand le test 3 réussit mais que le test 4 renvoie une page vide, vous êtes visible pour Google et absent des IA.
Quand le rendu serveur est hors de portée
Reste le cas réel : une application JavaScript métier existante, une équipe réduite. Et une migration vers le rendu côté serveur qui n'entrera dans aucun budget.
Deux voies tiennent debout. Générer statiquement les seules pages que vous avez besoin d'indexer, pages publiques, fiches, documentation, en laissant le reste en client. Ou hydrater partiellement, en servant le HTML des zones de contenu et en réservant le JavaScript aux parties interactives.
Une voie ne tient plus : l'affichage dynamique, qui consistait à servir une version pré-rendue aux robots. Google l'a officiellement rangé au placard. Sa documentation parle d'une solution de contournement, et non d'une solution à long terme, et pointe vers le rendu serveur, le rendu statique ou l'hydratation.
Dans les deux voies qui restent, l'ordre de priorité compte plus que l'ampleur du chantier. Servez d'abord en HTML ce qui doit être trouvé et cité. Le titre, le texte principal, les liens de navigation, le prix ou la référence quand il y en a un.
Le reste, filtres, carrousels, widgets, zone connectée, peut rester en client sans conséquence. Personne n'indexe un sélecteur de tri.
Ce découpage transforme une migration en série de chantiers courts. C'est la seule version du problème qu'une petite équipe peut réellement traiter.
Questions fréquentes
Mon site en React est-il pénalisé par Google ?
Non. Il n'existe aucune pénalité de classement liée à l'usage de JavaScript.
Le risque est ailleurs : un contenu qui n'entre jamais dans l'index, ou qui y entre en retard. Pas une sanction, une absence.
Le lazy loading empêche-t-il l'indexation du contenu ?
Pas s'il est bien implémenté. Google ne fait pas défiler la page et ne clique pas : il la rend dans une fenêtre très haute, ce qui déclenche ce qui doit l'être. En revanche, un contenu qui n'apparaît qu'après un clic ou un défilement piloté par un script maison a de fortes chances de rester invisible.
Faut-il utiliser la balise noscript ?
Elle ne remplace pas le rendu serveur. Google exécute le JavaScript, donc il verra la version rendue, pas le noscript.
Elle garde un intérêt pour les robots qui n'exécutent rien, dont les crawlers IA. Mais dupliquer un article entier dedans n'est pas tenable.
Combien de temps avant que Google réindexe après un passage en SSR ?
Ça dépend de la fréquence de crawl du site, pas du changement lui-même. Sur un site visité quotidiennement, les premiers effets se voient en quelques jours. Demander une réindexation via la Search Console accélère les pages prioritaires, pas l'ensemble du site.
JavaScript et SEO : le problème n'est plus le rendu, c'est l'implémentation
Google rend votre JavaScript. Les moteurs génératifs, non. Entre les deux, une poignée d'erreurs d'implémentation décide de ce qui existe et de ce qui disparaît.
J'ai passé huit ans à écrire du Angular et du Java avant de faire du SEO. Sur un site web en JavaScript, une stratégie SEO se joue autant dans la configuration de rendu que dans les balises. Je lis les deux.
Un seul interlocuteur, pas d'agence. J'audite le rendu de votre site avant qu'on se parle, et je vous cite des blocages précis dès le premier échange. Premier mois remboursé si vous n'êtes pas convaincu.
Réserver un appel de 30 minutes, ou voir le détail de l'accompagnement.