Comment éviter les conflits entre canonical et hreflang sur PrestaShop ?

Niveau de lectureAvancé

CMS / OutilPrestaShop

Temps de lecture7 min

Sur un PrestaShop multilingue avec des produits à déclinaisons, un conflit entre canonical et hreflang n’est presque jamais une erreur de configuration isolée : c’est souvent la conséquence directe d’un bug de canonicalisation déjà connu de l’éditeur. Le corriger demande de comprendre l’un pour réparer l’autre.

Sommaire

Pourquoi canonical et hreflang doivent se répondre
Le conflit le plus fréquent sur PrestaShop : les URLs à attributs
Un effet de bord, pas une erreur de configuration
Les 4 autres erreurs hreflang qui cassent tout le cluster
Poser une canonical propre selon votre version PrestaShop
La méthode de correction : générer le hreflang depuis la canonical réelle
Checklist de vérification
Questions fréquentes

Pourquoi canonical et hreflang doivent se répondre

La règle est simple à énoncer et fréquemment violée en pratique : chaque page d’un cluster hreflang doit porter une balise canonical auto-référente, c’est-à-dire pointer vers elle-même, pas vers une autre version linguistique ni vers une variante de la même page. Dès que la canonical d’une page pointe ailleurs que vers elle-même, Google considère cette page comme une simple copie de sa cible canonique, pas comme une variante linguistique légitime : le cluster hreflang tout entier perd sa valeur, puisque Google ignore les alternates d’une page qu’il ne considère plus comme faisant autorité pour elle-même. Une étude de 2023 (Search Engine Land) chiffrait à 31 % la part des sites présentant ce type de conflit, tous CMS confondus.

Le conflit le plus fréquent sur PrestaShop : les URLs à attributs

PrestaShop ajoute un paramètre d’identifiant de déclinaison (id_product_attribute) à l’URL d’une fiche produit dès qu’un visiteur sélectionne une variante (couleur, taille). C’est là que naît le conflit le plus spécifique à ce CMS : une fois la variante sélectionnée, l’URL affichée change, mais les balises hreflang générées pour cette page continuent, sur de nombreuses installations, à pointer vers les URLs génériques du produit dans chaque langue, sans l’identifiant de déclinaison. Le PrestaShop du visiteur se retrouve alors avec une URL réelle (avec attribut) dont le hreflang pointe vers une URL différente (sans attribut) : les deux balises ne se répondent plus.

Un effet de bord, pas une erreur de configuration

Signalé par la communauté, jamais isolé comme correctif

Ce problème a été signalé formellement au cœur de PrestaShop (issue #27638 du dépôt officiel, version 1.7.7.7) : absence de hreflang auto-référent et conflit entre hreflang et canonical sur les URLs à attributs produit. L’équipe de maintenance l’a fermée avec les étiquettes « Duplicate » et « Invalid », c’est-à-dire qu’elle ne le traite pas comme un bug isolé à corriger, mais comme une conséquence d’un problème déjà répertorié ailleurs : le bug de canonicalisation des déclinaisons, où la canonical d’une fiche produit avec variantes peut pointer vers l’URL de la PREMIÈRE combinaison plutôt que vers l’URL parente que PrestaShop désigne pourtant lui-même comme référence.

Concrètement, cela signifie qu’il ne sert à rien de corriger le hreflang seul en espérant que le conflit disparaisse : tant que la canonical d’une fiche à déclinaisons pointe vers une cible incohérente, tout hreflang posé par-dessus héritera du même défaut. Le diagnostic doit donc commencer par la canonical, pas par le hreflang, sur ce cas précis, contrairement à l’intuition qui pousse à corriger d’abord la balise la plus visible dans l’erreur.

Les 4 autres erreurs hreflang qui cassent tout le cluster

Au-delà du cas spécifique des déclinaisons, ces erreurs restent les plus fréquentes, avec leur fréquence mesurée sur un échantillon de sites en 2023 :

Erreur	Fréquence observée	Conséquence
Balises non réciproques (A pointe vers B, B ne pointe pas vers A)	—	Google ignore l’ensemble du cluster
Absence d’auto-référencement	16 %	La page « oublie » sa propre version dans son propre hreflang
Codes langue/région invalides (ex. `en_UK` avec underscore, `sp` au lieu de `es`)	8 %	Balise ignorée silencieusement, sans erreur visible
Absence de x-default	48 %	Perte de contrôle sur les visiteurs dont la langue ne correspond à aucune version

Une règle d’implémentation limite une partie de ces erreurs mécaniquement : n’utilisez qu’une seule méthode de déclaration du hreflang par ensemble d’URL (balise HTML dans le <head>, en-tête HTTP, ou sitemap XML), jamais deux à la fois. Un double dispositif HTML et sitemap qui se contredit produit le même résultat qu’une absence totale de hreflang : Google ignore l’ensemble par précaution.

Poser une canonical propre selon votre version PrestaShop

La correction du conflit passe nécessairement par une canonical fiable, avant même de toucher au hreflang.

PrestaShop 1.6 (thèmes Smarty)

La balise canonical n’est pas générée automatiquement dans header.tpl : elle doit être ajoutée manuellement, avec des conditions Smarty distinctes pour la page d’accueil, les fiches produit et les catégories. Utilisez la méthode native {$link->getProductLink($product)} plutôt que de reconstruire l’URL à la main à partir de $smarty.server.REQUEST_URI, qui conserve les paramètres parasites (tri, filtres, identifiant de déclinaison) que vous cherchez justement à éliminer.

PrestaShop 1.7 et 8.x (thème Classic)

La canonical est générée nativement via la variable {$urls.canonical_url}, présente dans templates/_partials/head.tpl. Vérifiez néanmoins dans le code source de vos pages (recherche de rel="canonical") que ce bloc n’a pas été retiré ou commenté par une personnalisation de thème, et que la pagination reçoit son propre traitement : une page paginée qui affiche des produits différents doit avoir sa propre canonical, pas systématiquement celle de la page 1.

La méthode de correction : générer le hreflang depuis la canonical réelle

La correction durable n’est pas de renseigner le hreflang à partir de l’URL générique du produit (celle sans déclinaison), mais de le générer dynamiquement à partir de l’URL canonique RÉELLEMENT utilisée sur la page consultée, déclinaison comprise si la canonical de cette fiche pointe légitimement vers une URL avec attribut. Concrètement : si la canonical de la page affiche id_product_attribute=12, les hreflang alternates de cette page doivent, pour chaque langue disponible, pointer vers l’équivalent de cette MÊME déclinaison dans chaque langue, pas vers la fiche produit générique. Sans cette cohérence, la correction du hreflang seul ne fait que déplacer le conflit au lieu de le résoudre.

Checklist de vérification

Vérifier l’auto-référencement de la canonicalChaque page doit porter une canonical qui pointe vers elle-même, jamais vers une autre langue ni vers une autre déclinaison sans raison.
Tester une fiche produit à déclinaisons dans chaque langueSélectionnez une variante, notez l’URL affichée, et vérifiez que les hreflang de cette page précise pointent vers l’équivalent de CETTE déclinaison dans les autres langues.
N’utiliser qu’une seule méthode de déclaration hreflangHTML, en-tête HTTP ou sitemap XML : jamais deux méthodes différentes sur le même ensemble d’URL.
Vérifier la réciprocité et l’auto-référencement de chaque paire de languesSi la version FR pointe vers la version EN, la version EN doit pointer vers la version FR, et chacune doit s’auto-référencer.
Poser un x-defaultPour orienter les visiteurs dont la langue ne correspond à aucune version explicitement ciblée.

Questions fréquentes

Comment savoir si mon site PrestaShop est concerné par ce conflit ?

Sélectionnez une déclinaison sur une fiche produit multilingue, notez l’URL réelle affichée, puis inspectez le code source (recherche hreflang) : si les URLs listées ne correspondent pas à la déclinaison actuellement affichée, le conflit est présent.

Un module tiers peut-il corriger ce conflit ?

Plusieurs modules PrestaShop dédiés au hreflang et à la canonical existent et peuvent aider, mais aucun ne dispense de vérifier concrètement, sur une fiche à déclinaisons, que la logique de génération respecte bien l’URL réellement affichée : un module mal configuré peut reproduire le même conflit qu’une implémentation manuelle.

Faut-il corriger le hreflang ou la canonical en premier ?

La canonical, systématiquement. Un hreflang correctement posé au-dessus d’une canonical incohérente ne fait qu’hériter du même défaut : le diagnostic et la correction doivent partir de la canonical avant de vérifier le hreflang qui en dépend.

Ce conflit affecte-t-il aussi les fiches produit sans déclinaison ?

Beaucoup moins souvent : sans sélection de variante, l’URL du produit reste stable et correspond directement à celle utilisée par le hreflang. Le risque se concentre sur les catalogues avec des produits à déclinaisons (couleur, taille, capacité) sur un site multilingue.

À propos de l’auteur

Aymeric Maingé

Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des boutiques PrestaShop et des catalogues e-commerce sur des problématiques de SEO technique, d’indexation, de contenu et de structure de liens. Mon approche croise audit terrain, priorisation métier et recommandations actionnables pour les équipes marketing et IT. Besoin d’un référenceur Google pour PrestaShop pour résoudre ce type de conflit technique ? Je propose aussi un diagnostic technique PrestaShop complet pour vérifier l’ensemble de votre cluster hreflang et canonical.