JavaScript SEO
Glossaire – Définition
Le JavaScript SEO regroupe les pratiques d’optimisation qui permettent aux moteurs de recherche de découvrir, crawler, rendre et indexer les contenus générés ou modifiés par du JavaScript côté client, en tenant compte du délai de rendu imposé par le Web Rendering Service de Google et des limitations des robots d’exploration face au code dynamique.
La majorité des sites web modernes s’appuient sur JavaScript pour afficher du contenu : React, Angular, Vue.js, Next.js. Dans les années 2000, les moteurs de recherche lisaient du HTML statique. Ce n’est plus le cas, mais leur capacité à exécuter du JavaScript reste fondamentalement différente de celle d’un navigateur classique.
Google crawler en deux temps. Lors du premier passage, Googlebot récupère le HTML brut. Si le contenu est injecté par JavaScript, il n’est pas encore visible. Google place alors la page dans une file d’attente de rendu. Son Web Rendering Service (WRS), basé sur Chrome headless, exécute le JavaScript dans un second passage. Ce délai peut aller de quelques heures à plusieurs semaines selon la popularité du site et la charge de rendu.
Martin Splitt, Developer Advocate chez Google spécialisé sur le sujet depuis 2018, a répété que Google peut rendre JavaScript, mais que le coût de ce rendu est réel. Les sites qui dépendent entièrement du JavaScript côté client pour afficher leur contenu principal prennent un risque d’indexation mesurable.
Pour bien comprendre :
- Comment Google crawle et rend le JavaScript
- Les erreurs JavaScript qui bloquent l’indexation
- SSR, SSG, prérendu : quelle architecture choisir ?
- Les 5 vérifications pour un site JavaScript bien indexé
- L’avis de l’expert B-Strong
- Questions fréquentes
Comment Google crawle et rend le JavaScript
Google traite les pages JavaScript en deux passages distincts, séparés dans le temps. Le premier récupère le HTML brut ; le second exécute le JavaScript via Chrome headless pour obtenir le DOM final. Entre les deux, le contenu dynamique reste invisible à l’index. Ce délai est le risque numéro un du JavaScript SEO.
En pratique, voici ce que Googlebot voit lors du premier passage sur une Single Page Application (SPA) React typique : un fichier HTML avec un <div id= »root »></div> vide et des balises <script> qui chargent l’application. Aucun contenu textuel, aucun lien navigable, aucune balise meta remplie.
Le WRS (Web Rendering Service) de Google prend la relève, mais ses ressources sont partagées entre tous les sites. Les pages moins populaires attendent plus longtemps dans la queue. Bartosz Goralewicz, consultant SEO, a documenté en 2016 des délais de rendu allant jusqu’à trois semaines pour certaines pages JavaScript peu crawlées.
- HTML brut vide : Googlebot ne voit rien lors du premier crawl. Le contenu n’est indexé qu’après le rendu, parfois bien plus tard.
- Lazy loading non optimisé : si les images ou les blocs de texte se chargent à l’intersection de la viewport, le WRS peut ne jamais les déclencher faute de simulation de scroll.
- JavaScript bloquant : les scripts tiers (chat, analytics, A/B testing) qui retardent le rendu de la page principale font aussi attendre Googlebot.
- Liens générés dynamiquement : un menu ou un fil d’Ariane construit par JavaScript peut ne pas être suivi lors du premier crawl, ce qui coupe le budget de crawl pour les pages en aval.
Pour diagnostiquer ce que Google voit réellement, l’outil « Inspecter l’URL » dans Google Search Console permet de comparer le HTML source et la version rendue. C’est souvent là que le problème devient visible.
Les erreurs JavaScript qui bloquent l’indexation
Les sites qui échouent en JavaScript SEO partagent généralement les mêmes erreurs de configuration. Aucune d’elles n’est complexe à corriger une fois identifiée ; le problème est qu’elles restent invisibles jusqu’à ce qu’on audite spécifiquement le rendu.
La première erreur, et la plus fréquente, est de placer des balises meta (title, description, canonical, robots) dans le JavaScript plutôt que dans le HTML initial. Si Googlebot lit le HTML brut avant le rendu, il voit des balises vides ou absentes. Résultat : des pages indexées sans titre, ou pire, avec un canonical pointant vers la mauvaise URL.
- Contenu principal injecté par JS : texte, titres H1-H2, corps de l’article généré après chargement. Google peut finalement l’indexer, mais avec retard.
- URLs avec hash (#) : les SPAs qui utilisent des fragments d’URL (<a href= »#/produit/123″>) ne sont pas crawlables par Google. Seule la partie avant le # est prise en compte.
- Redirections en JavaScript : un <script> qui redirige via window.location est moins fiable qu’une redirection 301 côté serveur. Googlebot peut ignorer la redirection.
- Erreurs JavaScript non catchées : un script qui plante en cours d’exécution laisse le rendu incomplet. Le WRS ne réessaye pas, contrairement à un navigateur classique.
- Contenu derrière des actions utilisateur : onglets, accordéons, chargement « voir plus ». Google ne clique pas. Ce qui n’est pas dans le DOM initial au chargement a peu de chances d’être indexé.
SSR, SSG, prérendu : quelle architecture choisir ?
La solution la plus fiable au JavaScript SEO est de livrer du HTML prêt à lire au premier crawl, sans attendre l’exécution du JS !
Trois approches permettent ça, avec des compromis différents selon le type de site.
Server-Side Rendering (SSR) : le serveur exécute le JavaScript et renvoie du HTML complet à chaque requête. Next.js (React), Nuxt.js (Vue) et SvelteKit implémentent le SSR nativement. Le contenu est visible dès le premier crawl, sans délai de rendu. Inconvénient : chaque requête consomme des ressources serveur.
Static Site Generation (SSG) : le HTML est généré une fois au build, puis servi comme fichiers statiques. Gatsby, Next.js en mode export, Astro fonctionnent sur ce principe. Idéal pour les blogs, les pages marketing, les contenus peu fréquemment mis à jour. Très rapide à crawler, aucun délai de rendu.
Prérendu (prerendering) : un middleware détecte les bots et leur envoie une version HTML pré-générée, pendant que les utilisateurs reçoivent l’application JS complète. Des outils comme Prerender.io ou Rendertron automatisent cette approche. Acceptable pour les sites existants difficiles à migrer, mais à surveiller : Google pénalise le cloaking si le contenu livré aux bots diffère trop de celui livré aux utilisateurs.
En règle générale, si le contenu de la page est important pour le référencement, SSR ou SSG sont préférables. Le prérendu est un compromis temporaire, pas une solution pérenne.
Les 5 vérifications pour un site JavaScript bien indexé
Un audit JavaScript SEO suit un ordre logique : d’abord vérifier ce que Google voit, ensuite corriger ce qu’il ne voit pas. Ces cinq points couvrent les problèmes rencontrés sur 80% des sites audités.
| Vérification | Comment la faire | Signe de problème | Correction |
|---|---|---|---|
| Comparer HTML source et rendu | Google Search Console > Inspecter l’URL > Voir la page rendue | Contenu absent dans la version rendue | Passer en SSR ou SSG pour le contenu indexable |
| Vérifier les balises meta dans le source | Afficher le code source HTML brut (Ctrl+U) | Balises title, canonical, robots vides ou absentes | Injecter ces balises côté serveur dans le HTML initial |
| Auditer les liens crawlables | Screaming Frog en mode JavaScript ON vs OFF | Moins de liens détectés en mode JS OFF | S’assurer que les liens de navigation sont en HTML statique |
| Tester le lazy loading | Désactiver JS dans le navigateur et observer le contenu visible | Images ou blocs de texte non chargés | Utiliser l’attribut loading= »lazy » natif HTML plutôt que des solutions JS |
| Surveiller la couverture d’index | Search Console > Couverture de l’index | Écart entre pages explorées et pages indexées | Identifier les pages avec erreurs de rendu dans le rapport détaillé |
L’avis de l’expert B-Strong
Le JavaScript SEO est le domaine où j’observe le plus grand écart entre ce que les développeurs pensent que Google voit et ce qu’il voit réellement. J’ai audité des sites e-commerce avec 50 000 fiches produits dont 30 000 n’étaient jamais indexées, simplement parce que le titre H1 et la description étaient injectés par React après le chargement initial.
Mon premier réflexe en audit : j’ouvre le code source HTML brut du site (Ctrl+U sur Chrome) et je cherche le texte principal de la page d’accueil ou d’une fiche produit. S’il n’y est pas, on a un problème de rendu.
Je recommande systématiquement Next.js avec SSR ou SSG pour les nouveaux projets e-commerce ou blog. Pour les sites existants en SPA pure, la migration est parfois longue, mais le prérendu via Prerender.io peut débloquer la situation en attendant. Ce que je déconseille : rester en attente en espérant que Google finira par rendre correctement les pages. Il le fait, mais pas pour toutes, et pas au bon moment.
Ce qu’on nous demande souvent
Google peut-il indexer une application React ou Angular ?
Oui, Google peut indexer les SPAs React, Angular ou Vue, à condition que son Web Rendering Service arrive à exécuter le JavaScript correctement. Le vrai problème n’est pas la capacité de Google à rendre le JS, c’est le délai : entre le premier crawl (HTML brut) et le rendu effectif, il peut s’écouler des jours ou des semaines. Pour les sites où le contenu change souvent ou dont les pages sont peu populaires, ce délai nuit à l’indexation. SSR ou SSG restent les solutions les plus fiables.
Comment savoir si Google rend correctement mes pages JavaScript ?
Google Search Console est l’outil de référence : utilisez la fonctionnalité « Inspecter l’URL » sur une page représentative, puis cliquez sur « Tester l’URL en direct » et « Voir la page rendue ». Vous obtenez une capture de ce que Google voit après exécution du JavaScript. Comparez-la avec la version visible dans votre navigateur. Tout contenu absent de la version rendue ne sera pas indexé à ce moment-là. Screaming Frog avec le mode JavaScript activé permet d’automatiser ce contrôle à l’échelle du site entier.
Le JavaScript SEO s’applique-t-il aussi aux images et aux vidéos ?
Oui. Les images chargées via JavaScript (lazy loading JS, carrousels dynamiques, galeries construites après le DOM) peuvent ne pas être indexées par Google Images si elles ne sont pas présentes dans le HTML initial. Google recommande d’utiliser l’attribut HTML natif loading= »lazy » sur les balises <img> plutôt que des solutions JavaScript tierces. Pour les vidéos, une balise <video> ou un embed YouTube directement dans le HTML reste plus fiable que du contenu injecté dynamiquement.