JS SEO

JavaScript SEO : se faire indexer malgré le rendu

Frameworks modernes, contenu injecté dynamiquement, applications monopages : le JavaScript a transformé le web. Il a aussi introduit un décalage entre ce que voit l’utilisateur et ce qu’indexe Google.

  • Difficulté Avancé
  • Impact SEO Très élevé
  • Lecture 8 min
  • À jour 15 juillet 2026
L’INDEXATION EN DEUX VAGUES VAGUE 1 — HTML immédiate Contenu présent dans le HTML initial → indexé tout de suite file d’attente VAGUE 2 — JS différée & coûteuse Contenu injecté après exécution JS → indexé plus tard, ou pas

À retenir

  • Google explore le HTML puis rend le JavaScript dans une seconde vague, différée.
  • Le contenu qui n’apparaît qu’après exécution JS est indexé plus tard, ou pas du tout.
  • Le rendu côté serveur (SSR) ou le prérendu fiabilise l’indexation des sites en JS.
  • On teste le rendu réel (HTML rendu) plutôt que le code source affiché.

Le rendu en deux vagues

Voici le point clé, souvent mal compris : Google traite une page en deux temps. Il explore d’abord le HTML brut et en indexe le contenu immédiatement. Puis, quand ses ressources le permettent, il exécute le JavaScript dans une seconde vague, plus tardive et plus coûteuse. Le contenu qui n’existe qu’après cette exécution est donc indexé avec retard — ou pas, si le rendu échoue.

Ce qui peut mal tourner

Sur un site fortement dépendant du JS, plusieurs contenus deviennent fragiles :

  • Le contenu principal injecté après chargement : invisible dans le HTML initial.
  • Les liens simulés par JavaScript (clics sur des div) au lieu de vrais <a href>.
  • Les balises (title, canonical, meta) modifiées tardivement par le JS.
  • Les données structurées ajoutées côté client.
Symptôme typique : la page est parfaite dans le navigateur, mais Google n’indexe qu’une coquille vide. Le contenu dépend d’un rendu JS que Google n’a pas (encore) exécuté.

Les stratégies de rendu

Plusieurs approches fiabilisent l’indexation :

  • Rendu côté serveur (SSR) : le serveur renvoie un HTML déjà complet, puis le JS « hydrate » la page. Le contenu est présent dès la vague 1.
  • Rendu statique / prérendu : les pages sont générées à l’avance en HTML complet (l’approche de ce site).
  • Rendu dynamique : servir une version prérendue aux robots — solution de transition, moins recommandée aujourd’hui.

Le principe commun : que le contenu important soit dans le HTML initial, sans dépendre de l’exécution JS.

Des vrais liens, toujours

Un lien n’est suivi de façon fiable que s’il est un véritable <a> avec un href présent dans le HTML. Les navigations reposant sur des gestionnaires d’événements ne sont pas des liens pour Google : elles n’assurent ni la découverte des pages ni la transmission d’autorité. La navigation et le maillage doivent reposer sur de vrais liens.

Tester le rendu réel

Ne jugez jamais le SEO d’un site JS sur ce que le navigateur affiche. On compare le code source brut (ce que Google voit en vague 1) au HTML rendu (après JS). L’inspection d’URL de la Search Console et les outils de test de rendu montrent ce que Google obtient réellement. Tout écart sur le contenu, les liens ou les balises est un risque à traiter.

En résumé

Le JavaScript n’est pas l’ennemi du SEO — le rendu tardif l’est. En plaçant le contenu essentiel dans le HTML initial (SSR, prérendu), en utilisant de vrais liens et en testant le rendu réel, on obtient des sites modernes et fiablement indexés. C’est un enjeu majeur lors d’une migration vers un CMS ou un framework JavaScript.

FAQ

Questions fréquentes

Google lit-il le JavaScript ?

Oui, Google exécute le JavaScript, mais en deux temps : il explore d’abord le HTML brut, puis rend le JS dans une seconde vague, plus tardive et plus coûteuse. Le contenu injecté par JS peut donc être indexé avec retard, et tout ce qui échoue au rendu (erreur, ressource bloquée) reste invisible.

Le rendu côté client est-il mauvais pour le SEO ?

Pas mauvais en soi, mais plus risqué : il fait dépendre le contenu de l’exécution réussie du JavaScript par Google. Pour du contenu important, le rendu côté serveur (SSR), le prérendu ou un rendu statique offrent une indexation plus fiable, car le contenu est présent dès le HTML initial.

Comment vérifier ce que Google voit d’une page en JS ?

On compare le code source brut au HTML rendu (via l’inspection d’URL de la Search Console ou un outil de test de rendu). Si un contenu, un lien ou une balise n’apparaît que dans le code affiché après exécution mais pas dans le HTML initial, il dépend du rendu JS — à sécuriser.

Les liens en JavaScript sont-ils suivis ?

Un lien n’est fiablement suivi que s’il est un vrai lien <a> avec un attribut href dans le HTML. Les « liens » simulés par des gestionnaires d’événements (onclick sur un div) ne sont pas des liens pour Google et ne transmettent ni découverte ni autorité. La navigation doit reposer sur de vrais liens.

Sources officielles

Un site en JavaScript mal indexé ?

On audite le rendu de votre site (SSR, prérendu, hydratation) pour fiabiliser l’indexation de votre contenu et de vos liens.

Auditer mon rendu
Discutons sur WhatsApp