Les canonicals et en-têtes rendus en JavaScript sont-ils réellement ignorés par Google ?

Pourquoi cette distinction entre HTML initial et rendu JavaScript ?

Google crawle et indexe les pages en deux phases distinctes. Le HTML brut est analysé en premier, avant tout traitement JavaScript. Les balises canonical, les en-têtes Link rel="canonical" et autres directives critiques doivent impérativement figurer dans cette première réponse serveur.

Si votre framework (React, Vue, Angular, Next.js) injecte ces éléments après coup via JavaScript, Google les verra potentiellement lors du rendering différé, mais ne les appliquera pas. Le robot ne fait pas confiance aux modifications post-chargement pour les directives de canonicalisation ou de redirection.

Quels éléments sont concernés par cette règle stricte ?

Les balises canonical (<link rel="canonical">) et les en-têtes HTTP Link doivent être présents dans la réponse serveur initiale. Cela vaut aussi pour les en-têtes de redirection, les directives hreflang, et potentiellement certains headers de cache ou sécurité.

Les métadonnées ajoutées dynamiquement (title, meta description, Open Graph) peuvent fonctionner en JavaScript pour l'affichage social, mais pour le SEO strict, mieux vaut ne pas miser uniquement sur le rendering différé. Google peut indexer avant rendering complet.

Comment vérifier ce que Google voit en HTML brut ?

Utilisez curl -I ou wget --server-response pour inspecter les en-têtes HTTP bruts. Pour le HTML initial, désactivez JavaScript dans Chrome DevTools (Cmd+Shift+P > Disable JavaScript) et rechargez la page.

Si vos canonicals disparaissent sans JS, vous avez un problème. L'outil d'inspection d'URL Search Console affiche à la fois le HTML brut et le rendu, mais ne montre pas toujours clairement quel élément provient de quelle phase.

• Les balises canonical doivent être présentes dans le HTML source avant tout script
• Les en-têtes HTTP Link (rel="canonical") doivent figurer dans la réponse serveur initiale
• Tout élément critique pour le crawl ou l'indexation ne doit pas dépendre de JavaScript pour son existence
• Les frameworks JavaScript modernes nécessitent un rendu côté serveur (SSR) ou une pré-génération statique pour garantir la présence de ces éléments
• Les SPA (Single Page Applications) pures sont particulièrement vulnérables à ce problème si elles n'utilisent pas de SSR

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même un rappel bienvenu. Trop de sites migrent vers des architectures JavaScript-first sans comprendre que Google ne fait pas confiance au rendering pour les directives critiques. On voit régulièrement des sites Next.js ou Nuxt mal configurés qui perdent leur canonicalisation pendant des semaines.

Le problème, c'est que Google rend effectivement le JavaScript pour d'autres aspects (contenu, liens internes), ce qui crée une confusion légitime. Les développeurs pensent que si Google voit le contenu rendu, il voit aussi les canonicals rendus. Faux.

Quelles sont les zones grises non clarifiées ?

Google ne précise pas le timing exact. Si une canonical apparaît après 50ms de JS mais avant le passage du renderer, est-elle prise en compte ? [A vérifier] sur des cas réels. La documentation officielle reste floue sur le délai entre crawl initial et rendering.

Autre point : les modifications de canonicals en cours de session (SPA navigation). Si l'utilisateur navigue d'une page A à une page B sans rechargement, et que la canonical change via JS, Google ignore-t-il ce changement lors d'un crawl ultérieur de cette URL ? Probablement, mais aucune donnée officielle ne le confirme explicitement.

Dans quels cas cette règle pose-t-elle le plus de problèmes ?

Les sites e-commerce avec filtres dynamiques sont piégés. Si vos facettes génèrent des URLs paramétrées et que la canonical pointe vers la version sans filtre uniquement via JavaScript, Google indexera potentiellement toutes les variantes.

Les sites multilingues utilisant du routing client-side (SPA) pour changer de langue sans SSR perdront leurs hreflang si celles-ci sont injectées post-rendu. Résultat : cannibalisation inter-langues et mauvais ciblage géographique dans les SERPs.

Que faut-il faire concrètement pour rester conforme ?

Première étape : auditez votre stack technique. Si vous utilisez React, Vue ou Angular, assurez-vous que le rendu côté serveur (SSR) ou la génération statique (SSG) est activé. Next.js avec getServerSideProps ou getStaticProps, Nuxt en mode universal, Angular Universal sont vos amis.

Deuxième action : vérifiez que vos balises canonical apparaissent dans le <head> du HTML source brut. Testez avec curl, avec JavaScript désactivé, et via l'outil d'inspection d'URL Search Console. Si elles n'apparaissent pas dans les trois, vous avez un souci.

Quelles erreurs éviter absolument ?

Ne déléguez jamais l'injection des canonicals à un plugin JavaScript ou à un gestionnaire de tags (GTM, Segment). Ces outils chargent trop tard dans le cycle de vie de la page. Google aura déjà lu le HTML brut.

Évitez les solutions hybrides bancales où une partie des pages utilise SSR et d'autres du CSR pur. Vous créez une incohérence de traitement qui complique le diagnostic et multiplie les risques d'erreurs d'indexation.

Comment tester que votre implémentation fonctionne ?

Utilisez un monitoring continu des en-têtes HTTP et du HTML source sur vos templates critiques. Un script Lighthouse CI ou un test Puppeteer peut automatiser la vérification que les canonicals sont présents avant tout JS.

Comparez systématiquement ce que vous voyez dans le navigateur (avec JS) et ce que curl renvoie (sans JS). Si la différence est significative sur des éléments SEO critiques, corrigez immédiatement côté serveur.

• Activez le rendu côté serveur (SSR) ou la génération statique (SSG) pour tous les templates stratégiques
• Vérifiez que les balises canonical apparaissent dans le HTML brut (test curl ou JS désactivé)
• Configurez les en-têtes HTTP Link rel="canonical" directement au niveau serveur pour les pages critiques
• Auditez vos frameworks JavaScript : Next.js, Nuxt, Angular Universal doivent être correctement configurés
• Testez avec l'outil d'inspection d'URL Search Console la présence des canonicals avant rendering
• Évitez d'injecter des directives SEO via GTM, Segment ou tout gestionnaire de tags tiers