Hreflang e-commerce multilingue : le guide anti-erreurs

Vous avez une boutique FR et vous ouvrez une version EN pour les US. Tout semble fonctionner — jusqu'à ce que vous réalisiez qu'en tapant votre marque depuis la France, Google affiche la page US. Vos clients français atterrissent sur une page anglaise, votre conversion chute.

Le coupable : un hreflang mal configuré. Cette balise dit à Google quelle version linguistique ou régionale servir à qui. Bien faite, elle débloque le SEO international. Mal faite, elle génère un chaos de redirections croisées.

Ce que hreflang résout (et ne résout pas)

Hreflang résout :

Servir la page FR aux utilisateurs francophones, EN aux anglophones
Différencier fr-FR (France) et fr-CA (Canada) avec des prix ou livraisons distincts
Éviter le contenu dupliqué entre 5 versions linguistiques quasi-identiques

Hreflang ne résout pas :

Le ranking en lui-même (hreflang n'est pas un signal de ranking direct)
La performance par marché (les backlinks locaux restent essentiels pour chaque marché)
Les problèmes de traduction de qualité

Si votre site n'a qu'une langue, vous n'avez pas besoin de hreflang. Si vous avez 2+ langues ou 2+ régions, c'est obligatoire pour un SEO international propre.

Les 3 méthodes d'implémentation

Méthode 1 — Balises `<link>` dans le HTML

La plus commune. Chaque page liste ses alternatives dans le <head> :

<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/products/leather-derby-shoes" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/leather-derby-shoes" />

Bien adapté aux petits catalogues (<1000 pages). Difficile à maintenir sur gros volumes — chaque page doit connaître ses alternatives.

Méthode 2 — Sitemap XML

Chaque URL dans le sitemap liste ses variantes :

<url>
  <loc>https://example.com/fr/products/chaussure-derby</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
  <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/products/leather-derby-shoes" />
</url>

Mieux pour les gros catalogues : centralise les relations dans un seul fichier. Plus facile à générer par script. C'est la méthode recommandée par Ecomptimize pour des catalogues de 5 000+ fiches.

Méthode 3 — En-tête HTTP `Link`

Pour les fichiers non-HTML (PDF, images localisées) :

Link: <https://example.com/fr/catalog.pdf>; rel="alternate"; hreflang="fr-FR",
      <https://example.com/en/catalog.pdf>; rel="alternate"; hreflang="en-US"

Rare pour l'e-commerce, utile pour les catalogues PDF téléchargeables.

Recommandation : méthode sitemap pour les catalogues >1000 URLs, balises HTML pour le reste.

Hreflang vs canonical : ne pas confondre

C'est le malentendu le plus fréquent.

Canonical dit : "voici l'URL de référence de ce contenu parmi plusieurs URLs identiques ou similaires". Sert à dédupliquer.

Hreflang dit : "voici les versions linguistiques de ce contenu, chacune est unique pour son public". Sert à localiser.

Règle critique : hreflang points à une URL différente (la version dans une autre langue). canonical points à une URL potentiellement identique (la même page ou une variation avec paramètres).

Une page doit avoir à la fois un hreflang ET un canonical :

<!-- Canonical de cette page -->
<link rel="canonical" href="https://example.com/fr/products/chaussure-derby" />

<!-- Versions linguistiques de cette page -->
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />

Erreur fatale : faire pointer le canonical de la version EN vers la version FR ("canonicaliser les traductions"). Google interprète ça comme "la version EN est un duplicate de FR à ignorer" et n'indexe pas du tout la page EN. Catastrophe SEO.

La matrice bidirectionnelle

Hreflang doit être bidirectionnel : si A dit "ma version EN est B", alors B doit dire "ma version FR est A". Sinon, Google ignore la relation.

Exemple d'implémentation correcte :

Page FR :

<link rel="alternate" hreflang="fr-FR" href=".../fr/..." />
<link rel="alternate" hreflang="en-US" href=".../en-us/..." />
<link rel="alternate" hreflang="x-default" href=".../en/..." />

Page EN US :

<link rel="alternate" hreflang="fr-FR" href=".../fr/..." />
<link rel="alternate" hreflang="en-US" href=".../en-us/..." />
<link rel="alternate" hreflang="x-default" href=".../en/..." />

Exactement les mêmes 3 lignes sur chaque version. Pas de relations manquantes, pas de relations asymétriques.

Variantes régionales : fr-FR vs fr-CA vs fr-BE

Quand faut-il distinguer les régions ?

Prix différents (TVA, livraison, devise) → oui, distinguer
Contenu légèrement différent (tailles US vs EU, vocabulaire local) → oui, distinguer
Contenu identique, juste la devise → non, distinguer ; gérez la devise côté checkout

La distinction régionale exige des URLs distinctes :

/fr/products/chaussure-derby     (hreflang="fr")
/fr-ca/products/chaussure-derby  (hreflang="fr-CA")
/fr-be/products/chaussure-derby  (hreflang="fr-BE")

Si vous ne pouvez pas maintenir 3 versions distinctes, mieux vaut garder une seule version fr et gérer les différences (devise, livraison) en runtime.

x-default : pourquoi il est indispensable

hreflang="x-default" indique la version à servir quand aucune correspondance n'est trouvée. Par exemple, un utilisateur en Roumanie qui n'a ni FR ni EN-US ni EN-GB dans ses préférences — quelle version lui servir ?

Sans x-default, Google choisit aléatoirement. Avec x-default, vous contrôlez (typiquement, la version EN la plus générique).

Recommandation : toujours déclarer un x-default, idéalement la version anglaise générique.

Implémentation par plateforme

Shopify

Shopify Markets (depuis 2022) gère nativement hreflang si vous configurez plusieurs markets avec des domaines ou sous-domaines distincts. Pas besoin de customisation dans la plupart des cas.

Limites : Shopify Markets ne supporte pas toutes les combinaisons de langue/pays avec une granularité fine. Pour des cas complexes (10+ marchés), passez par un app comme Langify + son module hreflang manuel.

WooCommerce

WooCommerce n'a pas de support natif. Trois options :

WPML (paid) : plugin multilingue leader, gère hreflang automatiquement
Polylang (free/paid) : alternative avec bon support hreflang
TranslatePress (paid) : plus simple pour de petits catalogues

Attention : ne combinez pas deux plugins (WPML + Polylang), ça crée des hreflang dupliqués et cassés.

Headless ou custom

Si vous êtes sur un frontend custom (Next.js, Nuxt), vous générez hreflang côté serveur. Sur Next.js avec next-intl, la génération est automatique si vous utilisez les routes /[locale]/....

Audit hreflang en 15 min

Sur votre site actuel, vérifiez :

Bidirectionnalité : pour 10 pages test, vérifier que chaque version mutuellement réfère aux autres (via Screaming Frog ou hreflang.org)
x-default présent : sur toutes les pages localisées
Pas de canonical cross-langue : la version EN ne doit pas canonicaliser vers FR
Codes ISO valides : "fr", "en" (langue) ou "fr-FR", "en-US" (langue-pays). Pas "french" ni "uk".
Même URL sur hreflang et canonical de la même page : évite les divergences

Outils gratuits :

hreflang.org — audit par URL
Screaming Frog (SEO Spider) — audit en masse
Google Search Console — rapports d'erreurs hreflang dans Settings → International Targeting

Hreflang e-commerce multilingue : le guide anti-erreurs