Declaration officielle
Autres déclarations de cette vidéo 9 ▾
- □ Pourquoi Google ignore-t-il vos balises meta placées dans le <body> ?
- □ Les balises hreflang dans le <body> sont-elles vraiment ignorées par Google ?
- □ Le code HTML valide W3C améliore-t-il vraiment le référencement ?
- □ Pourquoi modifier les canonicals en JavaScript crée-t-il des signaux contradictoires pour Google ?
- □ Faut-il optimiser les hints de préchargement pour Googlebot ?
- □ Le markup sémantique HTML5 est-il vraiment inutile pour le SEO ?
- □ La performance web améliore-t-elle vraiment votre référencement naturel ?
- □ Google parse-t-il vraiment le HTML comme un navigateur ?
- □ Pourquoi Googlebot ignore-t-il vos hints de préchargement des ressources ?
Google ignore délibérément toute balise link rel=canonical située dans le <body> d'une page, même si le HTML5 l'autorise techniquement. Cette restriction vise à empêcher des utilisateurs malveillants d'injecter des canonicals via des commentaires ou du contenu généré, détournant ainsi le référencement d'une page. La balise doit impérativement se trouver dans le <head>.
Ce qu'il faut comprendre
Google applique-t-il strictement les standards HTML pour le canonical ?
Non, et c'est assumé. HTML5 autorise techniquement les balises <link> dans le <body>, mais Google a fait un choix applicatif délibéré de les ignorer. Gary Illyes l'explique sans détour : accepter un canonical dans le corps de page ouvrirait une faille de sécurité évidente.
Imaginons un forum, un site e-commerce avec avis clients, ou tout système acceptant du contenu généré par les utilisateurs. Si Google prenait en compte un canonical situé n'importe où dans la page, un commentaire malveillant suffirait à rediriger tout le jus SEO vers un site tiers. La restriction au <head> limite drastiquement ce risque, car cette zone est rarement exposée aux contributions externes.
Cette règle concerne-t-elle uniquement le canonical ou d'autres balises aussi ?
La logique s'applique probablement à d'autres directives SEO critiques, même si Gary Illyes ne cite explicitement que le canonical. Les balises hreflang, alternate pour les versions AMP, ou encore certaines métadonnées structurées suivent vraisemblablement le même principe : seules celles du <head> sont fiables.
Google ne documente pas exhaustivement ces restrictions — il faut souvent déduire les règles d'usage via des déclarations ponctuelles comme celle-ci. C'est frustrant pour qui cherche une documentation complète, mais c'est le jeu.
Pourquoi cette clarification arrive-t-elle maintenant ?
Parce que le malentendu persiste depuis des années. Nombre de développeurs découvrent HTML5, constatent que les <link> peuvent légalement être placés dans le <body>, et en déduisent que Google les acceptera. Certains CMS mal configurés génèrent même des canonicals en plein milieu de page.
Cette déclaration coupe court : ce n'est pas un bug, c'est une décision consciente et justifiée par la sécurité. Si votre canonical se retrouve dans le <body> — par accident ou par méconnaissance — Google l'ignore purement et simplement.
- Seul le
<head>est pris en compte pour les baliseslink rel=canonical - Décision applicative de Google, pas une limitation technique du HTML
- Objectif : éviter l'injection malveillante via du contenu généré par les utilisateurs
- Applicable probablement à d'autres balises critiques (hreflang, alternate)
- CMS mal configurés : vérifiez où vos balises sont générées
Avis d'un expert SEO
Cette restriction est-elle cohérente avec ce qu'on observe sur le terrain ?
Absolument. Tout SEO ayant déjà audité un site mal configuré a déjà croisé des canonicals perdus dans le <body>, systématiquement ignorés par Google. Les outils de crawl comme Screaming Frog ou OnCrawl les détectent d'ailleurs comme anomalies — pas par hasard.
Ce qui est nouveau, c'est la justification officielle. Avant cette déclaration, beaucoup supposaient que Google les ignorait par commodité de parsing, ou par respect strict du standard historique (HTML 4.01 imposait le <head>). La vraie raison — la sécurité contre l'injection malveillante — change la perspective.
Peut-on vraiment exploiter cette faille si Google acceptait les canonicals dans le ?
Oui, sans aucune difficulté. Prenons un cas concret : vous gérez un site acceptant des commentaires ou des contributions textuelles. Un utilisateur mal intentionné poste un commentaire contenant <link rel="canonical" href="https://site-malveillant.com">. Si votre CMS n'échappe pas correctement les balises HTML (chose encore fréquente), ce code se retrouve dans le DOM.
Si Google honorait cette directive, chaque page avec ce commentaire transmettrait son autorité vers le site tiers. Multipliez ça par des milliers de pages, forums, blogs mal sécurisés : c'est un vecteur de piratage SEO massif. La restriction au <head> n'est donc pas paranoïaque, elle est nécessaire.
Tous les moteurs appliquent-ils cette règle ?
Probablement, mais [À vérifier] pour Bing, Yandex et consorts — aucune documentation publique ne le confirme explicitement. Bing suit généralement les conventions de Google sur ce type de directive, mais il arrive que des écarts existent.
Si vous opérez sur des marchés où Bing ou d'autres moteurs ont un poids significatif, testez empiriquement. Placez un canonical dans le <body> sur une page de staging, indexez-la, et vérifiez si le moteur l'honore. Ne présumez rien.
<head>. Un audit technique régulier est indispensable — cette erreur passe inaperçue jusqu'à ce qu'une page stratégique ne soit pas indexée correctement.Impact pratique et recommandations
Que faut-il vérifier immédiatement sur son site ?
Première action : crawler votre site avec un outil comme Screaming Frog, Sitebulb ou OnCrawl, et filtrer les pages où un canonical apparaît dans le <body>. La plupart de ces outils signalent cette anomalie comme un warning ou une erreur. Si vous en trouvez, c'est critique : ces directives sont ignorées, vos pages risquent des problèmes de canonicalisation.
Ensuite, inspectez le code source de vos templates principaux (page produit, article de blog, page catégorie). Repérez où le canonical est injecté. S'il apparaît après la balise </head>, vous avez un problème. Corrigez immédiatement dans le template ou le plugin responsable.
Quelles erreurs éviter lors de l'implémentation ?
Ne vous fiez jamais à la validation HTML seule. Un validateur W3C vous dira que placer un <link> dans le <body> est légal en HTML5 — mais Google s'en fiche. Ce qui compte, c'est la compatibilité avec les moteurs de recherche, pas la conformité académique au standard.
Autre piège : les frameworks JavaScript qui injectent dynamiquement des balises après le chargement de la page. Si votre canonical est ajouté via React, Vue ou Angular après le rendu initial, il se retrouve souvent dans le <body> du DOM final. Google, qui crawle de plus en plus le JavaScript, pourrait théoriquement le voir — mais l'ignorera quand même. Privilégiez le server-side rendering ou le rendu statique pour ces balises critiques.
Comment s'assurer que la configuration est correcte sur le long terme ?
Mettez en place un monitoring automatisé. Des outils comme ContentKing, Oncrawl ou des scripts custom via l'API de Screaming Frog peuvent alerter en temps réel si un canonical se retrouve en dehors du <head>. Ne comptez pas sur une vérification manuelle ponctuelle : un changement de thème, une mise à jour de plugin, un nouveau développeur dans l'équipe… et l'erreur réapparaît.
Intégrez ce contrôle dans votre pipeline de déploiement si possible. Un test automatisé avant chaque mise en production qui vérifie la position des balises SEO critiques évite 90 % des régressions.
- Crawler le site avec un outil professionnel et filtrer les canonicals dans le
<body> - Inspecter manuellement le code source des templates principaux (produit, article, catégorie)
- Vérifier que le canonical est injecté avant la fermeture du
</head> - Tester les pages générées en JavaScript : s'assurer que le canonical est en server-side ou pré-rendu
- Mettre en place un monitoring automatisé pour détecter les régressions
- Former les développeurs : un canonical dans le
<body>est une erreur critique, pas un détail - Auditer régulièrement après chaque changement de CMS, thème ou plugin
<head>, point final. Tout placement dans le <body> est ignoré, quelles que soient les raisons. Corrigez cette erreur si elle existe sur votre site, puis prévenez sa réapparition par du monitoring. Pour les sites complexes ou les migrations techniques où ces subtilités peuvent avoir des conséquences lourdes, un accompagnement par une agence SEO spécialisée permet de sécuriser la démarche et d'éviter les écueils techniques qui passent souvent inaperçus jusqu'à ce qu'il soit trop tard.❓ Questions frequentes
Un canonical dans le <body> cause-t-il une pénalité Google ?
HTML5 autorise les balises link dans le body, pourquoi Google refuse ?
Les autres moteurs de recherche appliquent-ils la même règle ?
Mon CMS génère le canonical après le <head>, que faire ?
Le canonical HTTP header est-il une alternative fiable ?
🎥 De la même vidéo 9
Autres enseignements SEO extraits de cette même vidéo Google Search Central · publiée le 26/02/2026
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.