Hreflang PrestaShop : erreurs fréquentes et méthode de vérification

Le hreflang est la balise la plus mal comprise du SEO international, et PrestaShop n’aide pas : aucune génération native, une syntaxe stricte, et un piège spécifique au CMS qu’aucun guide généraliste ne mentionne. Voici les erreurs qui reviennent le plus souvent et une méthode de vérification complète, y compris pour un mismatch que les audits classiques ne voient jamais.

Les erreurs hreflang les plus fréquentes

Les guides généralistes s’accordent tous sur un socle d’erreurs récurrentes. Sur une boutique PrestaShop multilingue ou multiboutique, ce socle se retrouve à l’identique, avec une fréquence souvent plus élevée parce que le hreflang y est presque toujours ajouté après coup, par un module ou un développement maison, plutôt que pensé dès la structure du site.

Erreurs de réciprocité et de syntaxe

L’erreur la plus documentée dans les audits de sites, toutes plateformes confondues, est l’absence de réciprocité : si la version française pointe vers la version espagnole, la version espagnole doit pointer en retour vers la version française, et vers elle-même. Sans ce lien retour, Google ignore purement et simplement l’annotation, ce qui revient à n’avoir posé aucun hreflang. Viennent ensuite les codes de langue et de pays mal formés : un code pays utilisé seul (be ne désigne pas la Belgique mais la langue biélorusse), un ordre inversé (us-en au lieu de en-US), ou un code qui ne respecte pas les normes ISO 639-1 pour la langue et ISO 3166-1 Alpha-2 pour le pays.

Erreurs de cohérence avec le reste de la page

Une balise hreflang posée sur une page en noindex, ou bloquée par le robots.txt, n’a aucune valeur puisque Google ne peut ni la lire ni indexer la page qu’elle décrit. Autre incohérence fréquente, un canonical qui pointe vers une autre version linguistique que celle sur laquelle il est posé : ce signal contredit directement le hreflang et l’un des deux finit par l’emporter, généralement le canonical, ce qui annule l’effet du travail international. Enfin, l’absence de balise x-default, censée orienter les visiteurs dont la langue ne correspond à aucune version disponible, reste l’une des omissions les plus courantes recensées dans les audits de sites multilingues.

Comment implémenter le hreflang sur PrestaShop

Contrairement à d’autres CMS qui proposent une génération automatique dès l’activation du multilingue, PrestaShop ne pose jamais la moindre balise hreflang de lui-même, comme nous le détaillons dans notre article sur le SEO international PrestaShop. Deux voies concrètes existent pour combler ce vide.

Éditer manuellement le template du thème

La balise link rel="alternate" hreflang s’ajoute dans le fichier head.tpl du thème actif, à l’intérieur de la balise head du document. Cette solution ne coûte rien en licence mais demande de boucler sur toutes les langues actives et de reconstruire dynamiquement l’URL de chaque version, ce qui devient fragile dès que le thème est mis à jour ou que le nombre de langues augmente. Sur un catalogue de plusieurs centaines de références, une erreur de boucle affecte instantanément l’intégralité des fiches produit.

Installer un module dédié

Un module de génération hreflang lit la table des langues et des correspondances de produits/catégories pour injecter automatiquement les balises correctes sur chaque page, y compris les nouvelles fiches créées après l’installation. C’est l’option qui limite le risque d’erreur humaine et qui reste maintenable au-delà de quelques dizaines de pages, au prix d’une dépendance à un composant tiers qu’il faut vérifier après chaque montée de version de PrestaShop.

Le point que personne ne dit : la traduction incomplète, invisible aux audits classiques

Les trois méthodes de vérification recommandées par la quasi-totalité des guides, à savoir contrôler la réciprocité, valider les codes ISO et vérifier les statuts HTTP, ont toutes un point commun : elles contrôlent la STRUCTURE des balises, jamais ce que la page affiche réellement. Sur PrestaShop, cette limite ouvre une faille bien réelle.

Sur une fiche produit, chaque champ traduisible (nom, description courte, description longue, méta-titre) est indépendant des autres. Si le nom du produit a été traduit en italien mais que la description longue a été oubliée, PrestaShop n’affiche ni erreur ni page vide : il retombe silencieusement sur le contenu de la langue par défaut de la boutique pour le champ manquant. La documentation officielle le confirme sans ambiguïté à propos de la création d’une nouvelle langue, en prévenant que tout texte non traduit apparaît dans la langue par défaut à sa place.

Concrètement, une URL déclarée hreflang="it-it", parfaitement réciproque, avec un code ISO valide et un statut HTTP 200, peut afficher une fiche produit dont le nom est en italien mais dont la moitié du texte reste en français. Aucun des trois contrôles standards ne détecte cette anomalie, puisqu’ils vérifient la présence et la cohérence des balises, jamais la langue réelle du contenu qu’elles décrivent. Pour Google, le signal envoyé est pourtant trompeur : une page qui prétend cibler un marché italien tout en mélangeant deux langues, ce qui dégrade la pertinence perçue de cette version aux yeux du moteur de recherche et, à terme, sa capacité à se positionner sur ce marché.

Méthode de vérification, étape par étape

Une vérification hreflang complète sur PrestaShop combine les contrôles structurels classiques et un contrôle de contenu propre au CMS, que les outils génériques ne couvrent pas.

Cette dernière étape, souvent sautée parce qu’elle ne s’automatise pas facilement, est aussi celle qui évite de déclarer une version internationale terminée alors qu’elle reste, pour Google comme pour vos visiteurs, à moitié traduite. Sur un catalogue volumineux, la même logique d’échantillonnage manuel complète utilement le travail effectué pour détecter les problèmes de canonicalisation avec Screaming Frog, deux contrôles qui gagnent à être menés dans la même session d’audit.

Ce qu’il faut retenir

Les erreurs hreflang classiques (réciprocité, codes ISO, x-default, cohérence canonical) touchent PrestaShop comme n’importe quelle autre plateforme et se corrigent avec les mêmes outils. Le piège propre à ce CMS se situe ailleurs, dans l’indépendance de chaque champ traduisible qui peut créer un mismatch de langue totalement invisible aux audits structurels. Notre article sur les URL canoniques PrestaShop détaille la mécanique de consolidation des signaux qui doit systématiquement accompagner le hreflang, et notre guide pour vérifier les balises canonical sur les fiches produit complète la méthode d’audit présentée ici.