Balises hreflang : indiquer à Google quelle version linguistique afficher

Révisé en juin 2026, s’applique à PrestaShop 1.7, 8 et au thème par défaut basé sur Hummingbird en 9.x, qui génèrent tous un bloc hreflang natif qu’il faut vérifier plutôt que supposer correct.

Vous avez déjà fait la partie coûteuse : votre boutique parle allemand aux acheteurs allemands, français aux acheteurs français, polonais aux acheteurs polonais. La partie la moins coûteuse, dire à Google quelle version s’adresse à qui, est pourtant celle que la plupart des marchands PrestaShop configurent mal, et elle peut discrètement réduire à néant tout le travail de traduction. Sans signaux hreflang corrects, Google doit deviner, et il se trompe souvent : il affiche votre page anglaise à un internaute allemand, ou considère vos cinq versions linguistiques comme cinq quasi-doublons qui se disputent le même mot-clé, en en classant une et en reléguant les autres. Hreflang est le petit élément technique qui transforme « nous avons traduit la boutique » en « le bon acheteur arrive sur la bonne langue ». Ce guide explique comment le mettre au point spécifiquement sur PrestaShop : ce que la plateforme génère déjà, là où elle a ses limites, et comment le vérifier au lieu de croire que « ça marche tout seul ».

Cet article est la partie consacrée à hreflang dans un ensemble plus large. Si vous en êtes encore au début, choix des langues, structure des URL, ou décision entre une seule boutique et plusieurs, commencez par la configuration d’une boutique multilingue, puis revenez ici une fois les langues en place.

Ce que hreflang indique réellement à Google (et ce qu’il n’indique pas)

Une annotation hreflang est une simple ligne dans l’en-tête de la page :

<link rel="alternate" hreflang="de" href="https://yourstore.com/de/produkt">

Elle dit une seule chose : « il existe une version équivalente de cette page en allemand, et elle se trouve ici ». Répétez-la pour chaque langue, et vous donnez à Google une carte des URL qui sont des traductions les unes des autres. Google utilise cette carte pour deux tâches. D’abord, la correspondance linguistique : un internaute franco-canadien reçoit votre page fr, pas votre page en, même si la version anglaise est mieux classée en valeur brute. Ensuite, et c’est le point que les marchands sous-estiment, le contrôle de la cannibalisation : hreflang indique à Google que ces pages sont des variantes, pas des concurrentes, afin qu’elles ne diluent pas leurs signaux de classement mutuels. C’est pour cela qu’un problème SEO et un problème de traduction sont en réalité le même problème.

Il faut aussi être clair sur ses limites, car c’est là que naissent les fausses attentes. Hreflang est une indication, pas une directive, Google l’a répété à plusieurs reprises. Il n’impose pas un classement, ne remplace pas de bonnes traductions et ne sauvera pas des pages que Google juge de faible qualité. Il ne change rien non plus directement pour vos clients ; personne ne voit une balise hreflang dans son navigateur. C’est uniquement un signal destiné au robot d’exploration. Alors, concrètement ? Son intérêt est précis mais réel : un hreflang correct vous évite de perdre des positions déjà acquises à cause d’une mauvaise interprétation en contenu dupliqué, et limite les rebonds liés à une mauvaise langue, qui gaspillent aussi bien votre budget publicitaire que vos efforts SEO.

Ce que PrestaShop fait déjà, et où se trouvent les lacunes

Voici ce que les anciens conseils du type « PrestaShop n’a pas de hreflang, installez un module » oublient : les versions modernes de PrestaShop génèrent déjà des balises hreflang. Les thèmes par défaut (le thème classic en 1.7/8 et le thème par défaut basé sur Hummingbird en 9.x) incluent un bloc hreflang dans l’en-tête de la page, qui parcourt vos langues actives et affiche une ligne rel="alternate" pour chacune, construite à partir de Link::getLanguageLink(). Une installation multilingue standard sur une seule boutique dispose donc généralement d’un hreflang fonctionnel dès le départ. Avant d’acheter quoi que ce soit, affichez le code source d’une page produit et cherchez « hreflang » : il est peut-être déjà présent.

Ce que le cœur de PrestaShop ne gère pas toujours correctement, ce sont les cas de bord, et c’est justement là que vivent les boutiques internationales :

• x-default est souvent absent. La boucle native génère une balise par langue, mais omet fréquemment l’entrée hreflang="x-default", qui indique à Google quoi afficher lorsqu’aucune de vos langues ne correspond à l’internaute (par exemple, un acheteur néerlandais sur une boutique EN/DE/FR). Sans elle, Google choisit à votre place.
• Le ciblage de plusieurs marchés dans une même langue n’est pas résolu pour vous. Une langue PrestaShop possède des champs de locale et de code langue, donc une valeur régionale n’est pas impossible, mais le cœur n’assemblera pas automatiquement les grappes complexes au niveau marché dont vous avez besoin si vous vendez en allemand à la fois en Autriche et en Allemagne, ou en anglais au Royaume-Uni et aux États-Unis. Distinguer de-AT de de-DE entre ces variantes est quelque chose que vous devez configurer et vérifier, pas quelque chose que la boucle hreflang standard déduit seule. Contrôlez les valeurs hreflang réellement générées à partir de la locale et du code de chaque langue, au lieu de supposer qu’elles ciblent le marché prévu.
• Le multiboutique fragmente l’ensemble. Si vous gérez des boutiques séparées par pays (voir PrestaShop Multistore), chaque boutique ne connaît que ses propres langues. Faire en sorte que store-de.com et store-fr.com se référencent mutuellement dans une même grappe hreflang est précisément le cas que le cœur ne construit pas pour vous.
• Les thèmes personnalisés et enfants peuvent le supprimer. Les thèmes qui surchargent head.tpl ou retirent le hook peuvent faire disparaître silencieusement le bloc hreflang. Un nombre surprenant de cas de « hreflang manquant » viennent simplement d’un thème qui n’affiche plus ce fragment.

La vraie question sur PrestaShop est donc rarement « ai-je du hreflang ? ». C’est plutôt : « l’ensemble est-il complet, réciproque et orienté vers les URL canoniques ? », et cela relève d’une vérification, pas d’un achat.

Commencer par une structure d’URL propre

Hreflang pointe vers des URL ; il ne peut donc être aussi propre que la structure d’URL multilingue sur laquelle il s’appuie. PrestaShop vous laisse un choix, à configurer dans Paramètres de la boutique → Trafic & SEO → SEO & URL (et, pour l’option de domaine par langue, dans les réglages Définir l’URL de la boutique / URL multiboutique). Voici les trois structures réalistes, et ce qu’elles impliquent pour hreflang :

Un piège propre à PrestaShop se trouve dans la configuration de la langue (International → Localisation → Langues), où deux champs distincts comptent. Le préfixe du chemin d’URL est construit à partir du code ISO à deux lettres ; une langue ajoutée avec un code ISO négligé produira donc un chemin négligé. La valeur hreflang, elle, vient de la locale / du code langue de la langue ; un problème de balise linguistique incorrecte et un problème de préfixe d’URL incorrect se corrigent donc à deux endroits différents. Vérifiez le code ISO si vos chemins semblent incohérents, et la locale/le code langue si les valeurs hreflang générées semblent fausses, puis corrigez la langue, pas la balise à la main. Les devises, la TVA et la configuration plus large de vente dans l’UE qui va avec sont traitées dans vendre en Europe depuis PrestaShop ; cet article reste concentré sur hreflang.

Les quatre erreurs qui invalident silencieusement votre hreflang

Hreflang échoue en silence. Il n’y a pas d’erreur dans votre boutique, pas de page cassée, Google ignore simplement l’annotation et recommence à deviner. Ces quatre causes couvrent presque tous les échecs rencontrés en production :

• Balises de retour manquantes (ensembles non réciproques). Si votre page EN liste la page DE comme sa variante allemande, la page DE doit lister en retour la page EN. Hreflang est une poignée de main ; un signe à sens unique est ignoré. C’est l’échec le plus courant, et celui qui touche le plus les configurations multiboutiques, où chaque boutique ne connaît naturellement que la moitié de l’échange.
• Codes de langue incorrects. La valeur doit être un vrai code de langue ISO 639-1, éventuellement complété par un pays ISO 3166-1. en-GB est valide ; en-UK ne l’est pas (le pays est GB). cs désigne le tchèque, pas cz. PrestaShop vous laissera volontiers saisir un mauvais code ISO dans la configuration de la langue, et celui-ci se retrouvera directement dans la balise.
• Pointage vers des URL non canoniques. Si votre canonique est https://store.com/de/, mais que votre hreflang pointe vers http://store.com/de (pas de SSL, barre oblique finale différente, ou paramètre ?), Google voit une URL différente et écarte l’annotation. Sur PrestaShop, cela vient le plus souvent d’une configuration http/https mixte ou d’une canonique d’URL simplifiée qui ne correspond pas à ce que la boucle hreflang construit.
• Couverture partielle. Hreflang sur les produits, mais pas sur les catégories, les pages CMS ou la page d’accueil, laisse Google dans le flou sur des sections entières du site. Il doit être présent sur chaque type de page, dans chaque langue ; sinon, l’incohérence devient elle-même un signal que quelque chose ne va pas.

Quand le hreflang natif ne suffit pas : passer par un module

Si vous avez vérifié votre configuration et trouvé de vraies lacunes. Pas de x-default, un thème personnalisé qui a supprimé les balises, un ciblage par pays que le cœur ne sait pas exprimer, ou une grappe multiboutique nécessitant une réciprocité entre domaines, c’est là qu’un module SEO mérite sa place. Son rôle est précis : générer un ensemble hreflang complet, réciproque et canonique sur chaque type de page, y compris x-default, sans modification manuelle des templates.

Notre suite SEO Revolution gère hreflang dans sa couche SEO internationale : elle génère l’ensemble des variantes sur les produits, catégories, pages CMS et la page d’accueil à partir de vos langues PrestaShop actives, ajoute l’entrée x-default que le cœur a tendance à oublier, et oriente chaque balise vers l’URL canonique afin que les incohérences http/https et les paramètres évoqués plus haut ne s’invitent pas. Qu’est-ce que cela vous apporte concrètement ? Vous n’avez plus à auditer à la main les balises d’en-tête d’une boutique qui ajoute sans cesse des pages, et une mise à jour de thème ne peut pas supprimer silencieusement votre hreflang, puisque les balises viennent du module plutôt que d’un template que vous pourriez surcharger. La configuration se fait depuis le back-office, pas de chirurgie dans head.tpl, pas de facture développeur pour une balise d’une ligne qui doit être correcte sur des milliers d’URL. La limite honnête est la même : un module qui génère un hreflang parfait ne classe pas votre boutique à lui seul ; il supprime la raison technique qui pousserait Google à mal classer ou mal servir les pages que vous avez déjà traduites.

Vérifiez-le, ne le supposez pas

Hreflang est particulièrement impitoyable, car une implémentation à moitié fausse peut être pire que l’absence totale de balises : un ensemble réciproque cassé peut faire perdre confiance à Google dans toute la grappe. La vérification n’est donc pas une finition facultative, c’est le travail lui-même. Trois contrôles, dans cet ordre :

• Commencez par afficher le code source. Ouvrez une page produit, cherchez « hreflang » dans le HTML, et comptez. Vous devriez voir une ligne rel="alternate" par langue active, plus une ligne x-default. Si vous n’en voyez aucune, votre thème a supprimé le bloc. Si vous voyez les langues mais pas x-default, c’est votre première lacune.
• Vérifiez la réciprocité à la main sur une grappe. Prenez un produit, ouvrez le code source de chaque version linguistique et confirmez que chaque version liste le même ensemble complet, elle-même incluse. Si la page DE ne pointe pas vers EN en retour, vous avez trouvé une erreur de balise de retour avant Google.
• Puis fiez-vous à la vision d’un crawler. Google Search Console ne propose plus l’ancien rapport Ciblage international ; utilisez donc un crawler qui audite hreflang (Screaming Frog, Sitebulb, ou un audit de site Ahrefs/Semrush) pour détecter en une fois les balises de retour manquantes, les codes invalides et les cibles non canoniques sur tout le site. C’est le seul moyen de repérer le problème de couverture partielle, car il est réparti sur des milliers d’URL.

Questions fréquentes

PrestaShop génère-t-il hreflang tout seul, ou ai-je besoin d’un module ?

Les versions modernes de PrestaShop le génèrent déjà. Les thèmes par défaut (classic en 1.7/8, thème par défaut basé sur Hummingbird en 9.x) incluent un bloc hreflang dans l’en-tête de la page, qui parcourt vos langues actives et affiche une ligne rel="alternate" pour chacune, construite à partir de Link::getLanguageLink(). Une installation multilingue standard sur une seule boutique dispose donc généralement d’un hreflang fonctionnel dès le départ, affichez le code source et cherchez « hreflang » avant d’acheter quoi que ce soit. Vous avez besoin d’un module lorsque vous trouvez de vraies lacunes : un x-default manquant, un thème personnalisé qui a supprimé le bloc, un ciblage au niveau pays ou une grappe multiboutique nécessitant une réciprocité entre domaines.

À quoi ressemble concrètement un ensemble hreflang complet ?

Chaque version linguistique d’une page doit lister le même ensemble complet, elle-même incluse, plus un x-default. Pour un produit EN/DE/FR, chacune de ces trois pages doit contenir un bloc identique dans son <head> :

<link rel="alternate" hreflang="en" href="https://store.com/en/product" />
<link rel="alternate" hreflang="de" href="https://store.com/de/produkt" />
<link rel="alternate" hreflang="fr" href="https://store.com/fr/produit" />
<link rel="alternate" hreflang="x-default" href="https://store.com/en/product" />

Le x-default indique à Google quoi servir lorsqu’aucune de vos langues ne correspond à l’internaute (par exemple, un acheteur néerlandais sur une boutique EN/DE/FR). Faites pointer chaque balise vers l’URL canonique, même protocole, même barre oblique finale, aucun paramètre ? parasite, sinon Google écarte l’annotation.

Quelle est la façon la plus courante dont hreflang échoue en silence ?

Les balises de retour manquantes. Hreflang est une poignée de main : si votre page EN liste la page DE comme variante allemande, la page DE doit lister la page EN en retour. Un signal à sens unique est ignoré. C’est l’échec qui touche le plus durement les configurations multiboutiques, car chaque boutique ne connaît naturellement que la moitié de l’échange, faire en sorte que store-de.com et store-fr.com se référencent mutuellement est précisément le cas que le cœur ne construit pas pour vous.

Mes valeurs hreflang sont incorrectes, dois-je les corriger dans la balise ou dans la langue ?

Dans la langue, jamais à la main dans la balise. Le préfixe du chemin d’URL vient du code ISO à deux lettres de la langue, tandis que la valeur hreflang vient de la locale / du code langue (International → Localisation → Langues). Un problème de chemin et un problème de balise se corrigent donc dans des champs différents. Utilisez un vrai code ISO 639-1, éventuellement complété par un pays ISO 3166-1 : en-GB est valide, en-UK ne l’est pas ; cs désigne le tchèque, pas cz.

Comment vérifier hreflang sur des milliers d’URL ?

Affichez d’abord le code source d’une page pour confirmer que les balises existent et incluent x-default, puis vérifiez à la main la réciprocité sur une grappe de produits. Ensuite, fiez-vous à un crawler, Google Search Console ne propose plus l’ancien rapport Ciblage international ; utilisez donc Screaming Frog, Sitebulb, ou un audit de site Ahrefs/Semrush pour détecter à l’échelle du site les balises de retour manquantes, les codes invalides et les cibles non canoniques. C’est la seule façon pratique de repérer une couverture partielle, puisqu’elle est dispersée dans tout le catalogue.

À lire aussi

• Configuration d’une boutique multilingue, mettez au point la boutique traduite et les URL par langue avant de vous préoccuper de hreflang.
• PrestaShop Multistore. Là où la réciprocité hreflang entre domaines devient la partie difficile.
• Sélecteur de devise et drapeaux de langue, le sélecteur visible par l’utilisateur que hreflang complète, mais ne remplace pas.

Le principe sous-jacent est le même que dans le reste de cet ensemble : une boutique qui vend à l’international repose sur une série de petits signaux exacts, la bonne devise, le bon drapeau de langue, la bonne ligne de taxe et le bon hreflang, chacun peu coûteux isolément, chacun capable de faire perdre de la valeur lorsqu’il est légèrement faux. Soignez l’expérience de langue et de devise pour que les visiteurs restent (sélecteur de devise et drapeaux de langue), affichez les prix et facturez correctement selon chaque marché (multidevise et vente internationale), et laissez hreflang s’assurer que le moteur de recherche envoie chaque acheteur vers la version que vous avez préparée pour lui. Sur PrestaShop, cela signifie savoir que le cœur fait déjà l’essentiel, puis concentrer vos efforts sur x-default, la réciprocité et la correspondance canonique qui décident si ce travail compte réellement.