Les canonicals JavaScript sont-elles vraiment ignorées par Google ?

Declaration officielle

Les éléments de balise canonique ne sont pas pris en compte lorsqu'ils sont générés dynamiquement par JavaScript. Assurez-vous que la version statique HTML envoie correctement la balise canonique.

9:40

🎥 Vidéo source

Extrait d'une vidéo Google Search Central

⏱ 56:37 💬 EN 📅 15/05/2018 ✂ 14 déclarations

Voir sur YouTube (9:40) →

✂ Autres déclarations de cette vidéo 13 ▾

2:06 Google fusionne-t-il vraiment les pages similaires en une seule version indexée ?
4:34 Le pré-rendu basé sur l'user-agent est-il devenu la seule méthode recommandée par Google ?
5:49 Faut-il vraiment adapter la longueur de ses meta descriptions aux snippets Google ?
7:53 Faut-il bloquer la redirection automatique vers l'app mobile pour préserver son SEO ?
7:53 Les redirections furtives vers les applications mobiles sont-elles un frein au référencement ?
8:32 Google propose-t-il vraiment une révision manuelle SEO de votre site ?
11:17 Les PWA sont-elles vraiment indispensables pour le référencement naturel ?
16:56 Faut-il corriger les URLs marquées 'submitted URL not selected as canonical' ?
17:36 Faut-il supprimer un sitemap qui contient trop d'erreurs ?
19:40 Comment Google distingue-t-il réellement le contenu dupliqué des adresses identiques ?
25:43 Faut-il vraiment rediriger toutes les pages HTTP vers HTTPS pour éviter les problèmes d'indexation ?
37:33 Faut-il craindre de trop lier vers Wikipédia ou des sites d'autorité ?
42:06 Pourquoi les URL avec dièse (#) bloquent-elles l'indexation de vos pages Angular ?

Ce qu'il faut comprendre

Pourquoi Google distingue-t-il le HTML statique du JavaScript ?

Googlebot exécute le JavaScript, c'est un fait établi depuis des années. Mais l'exécution se fait en deux phases distinctes. D'abord, le crawl récupère le HTML brut envoyé par le serveur. Ensuite — parfois avec un délai de plusieurs heures ou jours — vient le rendering, où les scripts modifient le DOM.

La balise canonique sert à désambiguïser les URLs dès la phase de crawl. Si elle n'apparaît qu'après exécution JavaScript, elle arrive trop tard dans le pipeline. Google a déjà pris sa décision d'indexation sur la base du HTML initial. C'est pour ça que Mueller insiste sur le terme "statique" : le signal doit être immédiatement disponible, sans dépendre d'un thread de rendering.

Qu'est-ce que ça change concrètement pour les frameworks JavaScript ?

AngularJS — et par extension Angular, React, Vue — génèrent souvent l'intégralité du contenu côté client. Si votre application inject la balise canonical via JavaScript, le HTML source ne la contient pas. Le serveur envoie un squelette vide, et le framework construit la page ensuite.

Google voit donc une page sans canonical dans le HTML initial. Peu importe que le script ajoute correctement la balise 200ms plus tard : le signal n'est pas pris en compte. Résultat : Google détermine lui-même quelle URL il considère comme canonique, et ça peut être une version avec paramètres, une variante mobile, ou n'importe quelle autre URL qu'il juge pertinente.

Cette règle s'applique-t-elle à tous les éléments de la page ?

Non, et c'est crucial. Google indexe parfaitement du contenu généré en JavaScript : titres, textes, liens internes. Mais certains signaux techniques — canonical, hreflang, certaines métadonnées — doivent être présents dans le HTML statique pour être fiables.

La raison ? Ces balises influencent des décisions prises avant le rendering : choix de la version à indexer, budget de crawl, clustering des pages. Si Google doit attendre le rendering pour les détecter, il risque de prendre des décisions contradictoires entre la phase de crawl et la phase de rendering. Pour éviter ce conflit, il ignore simplement les signaux arrivant trop tard.

Les canonicals JavaScript ne sont pas prises en compte par Googlebot, quelle que soit la qualité du rendering
Le HTML statique envoyé par le serveur (avant exécution JS) est la seule source fiable pour la balise canonical
Les frameworks côté client (AngularJS, React, Vue) nécessitent un rendering côté serveur (SSR) ou une pré-génération (SSG) pour envoyer des canonicals valides
Autres signaux techniques concernés : hreflang, certaines balises meta, certains attributs de liens (nofollow peut être différent)
Le contenu textuel lui-même peut être généré en JavaScript et sera indexé correctement après rendering

Avis d'un expert SEO

Cette affirmation correspond-elle aux observations terrain ?

Oui, et c'est confirmé par des tests répétés. J'ai vu des dizaines de sites en React ou Vue où la canonical était correcte dans le DOM final (visible dans l'inspecteur navigateur), mais Google indexait une autre version. La Search Console affichait "URL alternative avec balise canonical appropriée" alors que la canonical pointait bien vers elle-même.

Le diagnostic ? Un curl de la page montrait un <head> vide. La canonical n'existait que côté client. Google prenait donc sa décision d'indexation sur la base du HTML brut, ignorait totalement la balise JavaScript, et choisissait une URL différente — souvent celle avec des paramètres UTM ou une variante paginée.

Pourquoi Google ne peut-il pas simplement attendre le rendering ?

Question de latence et de cohérence. Le crawl est quasi-instantané : Googlebot récupère le HTML en quelques centaines de millisecondes. Le rendering peut prendre plusieurs secondes, voire être différé de plusieurs heures si le budget de crawl est serré.

Si Google devait attendre le rendering pour connaître la canonical de chaque page, il devrait stocker des décisions provisoires, puis les réviser après rendering. Ça créerait des incohérences massives : une URL serait d'abord considérée comme canonique, puis remplacée par une autre. Les signaux de ranking (backlinks, ancienneté) seraient dilués entre plusieurs versions temporaires. Google a tranché : les signaux techniques doivent être immédiats et stables.

Y a-t-il des exceptions ou des nuances à cette règle ?

Soyons honnêtes : [À vérifier] Google n'a jamais publié de liste exhaustive des éléments ignorés en JavaScript. Mueller parle ici spécifiquement des canonicals, mais les observations terrain suggèrent que les hreflang sont dans le même cas. Les balises meta robots (noindex, nofollow) semblent prises en compte même en JavaScript, mais avec un délai parfois problématique.

La nuance importante : si votre site utilise du rendering dynamique (serving different HTML to bots vs users), Google peut détecter la canonical dans la version servie aux bots. Mais Google déconseille officiellement cette pratique — elle sent le cloaking. La solution propre reste le Server-Side Rendering (SSR) ou la pré-génération statique (SSG), où le HTML envoyé à tout le monde contient déjà la canonical.

Attention : Ne confondez pas "Google n'indexe pas le contenu JavaScript" (faux depuis 2015) et "Google ignore certains signaux techniques en JavaScript" (vrai). Le contenu textuel, les liens, les images générés en JS sont parfaitement indexés. Seuls certains éléments du <head> exigent un envoi côté serveur.

Impact pratique et recommandations

Comment vérifier que ma canonical est bien statique ?

La méthode la plus simple : curl ou l'outil "Afficher la source" du navigateur (clic droit > Afficher le code source, pas l'inspecteur). Si la balise <link rel="canonical"> apparaît dans ce code brut, elle est statique. Si elle n'apparaît que dans l'inspecteur DOM après chargement complet, elle est générée en JavaScript — donc ignorée par Google.

Autre outil fiable : Google Search Console > Inspection d'URL > onglet "HTML envoyé". Cette vue montre exactement ce que Googlebot a reçu avant rendering. Si votre canonical n'y figure pas, c'est raté. Vous pouvez aussi utiliser le test Mobile-Friendly ou le Rich Results Test de Google, qui affichent le HTML brut avant exécution JavaScript.

Quelles solutions techniques pour un site JavaScript ?

Server-Side Rendering (SSR) est la solution la plus robuste. Next.js pour React, Nuxt pour Vue, Angular Universal pour Angular : ces frameworks génèrent le HTML complet côté serveur avant envoi. La canonical est déjà présente dans la réponse HTTP initiale. Googlebot et les utilisateurs reçoivent le même HTML enrichi.

Alternative : Static Site Generation (SSG). Gatsby, Next.js en mode export, Nuxt generate pré-compilent toutes les pages en HTML statique au moment du build. Chaque page est un fichier HTML complet avec sa canonical. Parfait pour les sites dont le contenu change peu. Pour les sites très dynamiques, le SSR reste préférable — ou un hybride (SSG pour les pages stables, SSR pour les pages utilisateur).

Que faire si je ne peux pas migrer vers SSR tout de suite ?

Solution temporaire : pré-rendering via un service comme Prerender.io ou Rendertron. Le serveur détecte les bots (user-agent Googlebot) et sert une version HTML pré-rendue, tandis que les utilisateurs reçoivent la SPA classique. C'est techniquement du cloaking, mais Google tolère cette pratique si les deux versions affichent le même contenu.

Autre option : injecter la canonical côté serveur dans le <head> initial, même si le reste de la page est géré en JavaScript. Beaucoup de frameworks permettent de templatiser le HTML de base avec des variables serveur. Vous pouvez ainsi insérer dynamiquement la canonical correcte avant l'envoi, sans refondre toute votre architecture. Pour des optimisations aussi techniques — surtout sur des stacks complexes — faire appel à une agence SEO spécialisée peut éviter des mois de tâtonnements et sécuriser votre migration.

Vérifier la présence de la canonical dans le HTML source brut (curl ou "Afficher la source")
Utiliser Google Search Console > Inspection d'URL pour confirmer que Google voit bien la canonical
Migrer vers SSR (Next.js, Nuxt, Angular Universal) ou SSG (Gatsby, Next export) si possible
Si migration impossible immédiatement : pré-rendering pour les bots ou injection serveur de la canonical dans le <head> initial
Auditer aussi les hreflang, meta robots et autres signaux techniques potentiellement générés en JavaScript
Tester les modifications avec le Mobile-Friendly Test et le Rich Results Test de Google avant déploiement

La règle est simple : toute balise canonique générée uniquement en JavaScript est invisible pour Google. Le HTML statique envoyé par le serveur doit contenir la canonical complète. Pour les sites en frameworks JavaScript modernes, ça impose soit du Server-Side Rendering, soit de la pré-génération statique, soit une injection côté serveur de la balise avant envoi. Vérifiez systématiquement le HTML brut reçu par Googlebot, et ne vous fiez jamais uniquement à l'inspecteur DOM de votre navigateur — ce dernier vous montre l'état final après JavaScript, pas ce que Google voit en phase de crawl.

❓ Questions frequentes

Est-ce que Google indexe quand même mon contenu si la canonical est en JavaScript ?

Oui, Google indexera le contenu textuel généré en JavaScript après rendering. Mais il ignorera la balise canonical JavaScript et choisira lui-même l'URL canonique, ce qui peut causer des problèmes de duplication ou d'indexation de mauvaises versions.

Les hreflang sont-elles aussi concernées par cette limitation ?

Très probablement oui, bien que Google ne l'ait pas confirmé aussi explicitement que pour les canonicals. Les observations terrain montrent que les hreflang générées en JavaScript sont souvent ignorées. Privilégiez toujours le HTML statique ou les HTTP headers pour les hreflang.

Le Server-Side Rendering ralentit-il mon site ?

Pas nécessairement. Le SSR ajoute une latence serveur (quelques dizaines de millisecondes), mais élimine le délai de rendering côté client. Résultat : le First Contentful Paint est souvent meilleur. Avec du cache serveur et un CDN, les performances restent excellentes.

Puis-je utiliser une balise canonical HTTP header au lieu du HTML ?

Oui, Google supporte les canonicals envoyées via HTTP header (Link: <url>; rel="canonical"). C'est même une solution élégante pour les sites JavaScript : le serveur peut injecter le header sans toucher au HTML. Testez bien que Google la détecte dans la Search Console.

Que se passe-t-il si j'ai à la fois une canonical statique et une JavaScript différente ?

Google prendra en compte la canonical statique et ignorera celle en JavaScript. Si les deux pointent vers des URLs différentes, seule la version HTML initiale sera respectée. Évitez cette situation : elle crée de la confusion et des signaux contradictoires.

🎥 De la même vidéo 13

Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 56 min · publiée le 15/05/2018

🎥 Voir la vidéo complète sur YouTube →