SEO international DNVB : hreflang sans se planter (FR, UK, US)

Un déploiement international se vend comme un chantier de traduction et de logistique. Ce qui décide de la page que Google affiche à Londres, puis à Chicago, tient dans trois pages de documentation officielle et une page d'aide Search Console, publiques et suffisantes pour instruire une proposition commerciale avant de la signer. Ces quatre pages ont été consultées le 8 septembre 2026, et chaque URL est donnée en clair à côté de l'affirmation qu'elle porte.

Les cinq règles qu'une annotation hreflang doit tenir

Google décrit trois méthodes d'implémentation au choix (https://developers.google.com/search/docs/specialty/international/localized-versions) : une balise link rel="alternate" dans le head de la page, un en-tête HTTP Link sur la réponse, ou des éléments xhtml:link dans le sitemap XML. Les règles qui suivent viennent de la même page et valent pour les trois méthodes.

• Chaque version doit se lister elle-même, en plus de lister toutes les autres versions.
• La réciprocité est une condition de validité : si deux pages ne pointent pas l'une vers l'autre, les balises sont ignorées.
• Les URL alternatives doivent être complètes, protocole http ou https compris.
• Le code de langue suit la norme ISO 639-1, le code de région la norme ISO 3166-1 alpha-2, et le code de pays ne peut pas être utilisé seul.
• Les valeurs UK, EU et UN n'ont aucun effet sur la recherche Google. Le Royaume-Uni s'écrit GB.

La dernière règle se vérifie en dix secondes dans le code source d'une fiche produit. Les autres se vérifient à l'échelle du catalogue, ce qui suppose des annotations générées par un gabarit ou par le sitemap, jamais saisies à la main : chaque fiche porte autant d'annotations qu'il existe de versions, elle-même comprise. Une proposition qui promet le hreflang sans dire où il est généré promet un chantier que personne ne maintiendra au dixième ajout de produit.

Ce que change vraiment le passage FR vers UK, puis UK vers US

Les deux étapes ne posent pas le même problème, et les confondre coûte cher.

Google précise que les versions localisées d'une page sont considérées comme des doublons uniquement si le contenu principal reste non traduit. Une page française et une page anglaise sont donc deux pages distinctes, et le hreflang sert à router le bon visiteur vers la bonne.

Une page en-GB et une page en-US qui portent le même texte relèvent d'un autre cas : du contenu similaire ou dupliqué, sur des URL différentes, dans la même langue. La documentation multirégionale demande alors de choisir une version préférée, puis d'utiliser l'élément rel="canonical" et les balises hreflang pour que la bonne URL linguistique ou régionale soit servie aux internautes (https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites).

La question à trancher avant d'ouvrir le marché américain devient donc opérationnelle : qu'est-ce qui diverge réellement entre les deux versions anglaises ? Devise et affichage des taxes, frais et délais de livraison, politique de retour, guide des tailles, mentions légales, disponibilité produit, horaires du service client. Si la réponse tient en une ligne, vous financez un deuxième site pour servir le même texte. Une annotation hreflang oriente l'internaute vers la version qui lui correspond, elle ne fait pas classer une page qui ne se classerait pas seule.

La structure d'URL se décide avant la première balise

La même documentation multirégionale liste quatre structures et leurs contreparties.

• Le domaine national (example.co.uk) : ciblage géographique clair et séparation nette, contre un coût plus élevé, des exigences propres à certains registres et un seul pays visé par domaine.
• Le sous-domaine sur gTLD (uk.example.com) : mise en place simple et serveurs séparables, mais l'utilisateur ne devine pas le ciblage à la lecture de l'URL.
• Le sous-répertoire sur gTLD (example.com/uk/) : mise en place simple et maintenance faible, avec la même ambiguïté, un seul emplacement serveur et une séparation plus difficile.
• Le paramètre d'URL (example.com/?loc=uk) : déconseillé par Google, segmentation difficile et signal de ciblage flou.

Un point de contexte a changé et il pèse sur cet arbitrage : le rapport Ciblage international de la Search Console est obsolète, et la possibilité de cibler des résultats de recherche par pays depuis la Search Console n'est plus prise en charge (https://support.google.com/webmasters/answer/12474899). Google continue en revanche de prendre en charge et d'utiliser les balises hreflang. Sur un domaine générique, il n'existe donc plus de réglage à cocher pour déclarer qu'une section vise le Royaume-Uni : la structure d'URL et les annotations portent seules ce travail.

Ce que Google dit des redirections automatiques par pays

La même documentation multirégionale demande d'éviter de rediriger automatiquement les internautes d'une version linguistique vers une autre, parce que ces redirections peuvent empêcher les utilisateurs et les moteurs de voir toutes les versions du site.

La page consacrée aux contenus adaptés aux paramètres régionaux complète le tableau (https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages) : Googlebot envoie ses requêtes HTTP sans définir l'en-tête Accept-Language, explore depuis des adresses IP situées aux États-Unis comme depuis des adresses hors États-Unis, et Google recommande des URL distinctes par paramètres régionaux, annotées en hreflang, plutôt qu'un contenu qui change sur une même URL.

Pour une marque qui vend depuis une seule boutique avec détection du pays, la conséquence est directe : un visiteur détecté hors zone doit pouvoir atteindre la version qu'il demande. Le sélecteur de pays et le bandeau de suggestion tiennent ce rôle, la redirection forcée non.

x-default, la valeur qui manque le plus souvent

La valeur réservée x-default désigne la version servie aux utilisateurs dont les paramètres linguistiques ne correspondent à aucune version localisée du site. Sur un parcours FR vers UK vers US, elle répond à une question que le reste des annotations laisse ouverte : que voit un visiteur allemand ou japonais. Une page de sélection de pays, ou la version considérée comme la plus universelle, remplit ce rôle.

Ce que ce domaine déclare lui-même

Cet article est publié par une agence qui vend du SEO e-commerce : notre offre SEO e-commerce couvre ces chantiers, et la grille ci-dessus s'applique d'abord à nous.

make-sense.fr porte ses pages anglaises en sous-répertoire /en. La page d'accueil déclare fr, fr-FR, en, en-US et x-default. Sur le cluster Google Ads, la page française déclare en-GB vers notre page londonienne et en, en-US vers notre page anglaise, et la page londonienne renvoie les mêmes paires en retour. Sur les pages nationales des clusters Google Ads et Meta Ads, les paires fr-CA et en-CA partent vers les pages montréalaises de make-sense.ca, et elles ne sont ajoutées côté français que lorsque le dépôt canadien porte déjà l'annotation de retour, sans quoi elles seraient ignorées.

Le lecteur qui ouvrira le code de nos propres pages montréalaises du .fr trouvera autre chose, et c'est un défaut : make-sense.fr/agence-google-ads-montreal et make-sense.fr/agence-meta-ads-montreal déclarent fr-CA vers elles-mêmes et en-CA vers leur version /en du même domaine, sans aucune annotation vers leurs jumelles canadiennes. Le .fr revendique donc Montréal en fr-CA et en-CA à deux endroits concurrents, et ces pages tombent exactement dans le cas « contenu similaire, même langue, URL différentes » que cet article demande de trancher par version préférée, canonical et hreflang. Le chantier est identifié, il n'est pas fait.

Le point discutable est visible : héberger des pages anglaises sur un .fr revient à poser du contenu anglophone sur un domaine national associé à la France, dont la documentation Google dit qu'il porte un ciblage géographique clair. Ce compromis tient tant que le volume anglophone reste limité, et se réexamine dès qu'un marché justifie son propre domaine.

Notre comparatif SEO Shopify vs Shopify Plus détaille ce que la configuration Markets génère automatiquement en hreflang, canonical et sitemaps annotés. Sur la validité des annotations elles-mêmes, c'est le présent article qui fait foi.

Ce que nous demandons avant de chiffrer un déploiement

Les questions ci-dessous se posent dans cet ordre : les balises passent après la logistique et le catalogue, parce qu'une version qui ne diverge sur rien n'a pas de raison d'exister.

• La liste des paires prévues, version par version, et l'endroit exact où elles seront générées : gabarit du thème, sitemap ou en-têtes HTTP.
• La preuve de réciprocité quand une paire pointe vers un domaine que vous ne contrôlez pas seul, filiale ou distributeur compris.
• Ce qui diverge réellement entre deux versions de même langue, et qui l'alimente en interne.
• Le comportement prévu pour un visiteur hors zone, et le sort réservé au sélecteur de pays.
• Les codes utilisés, GB plutôt que UK, et la présence d'un x-default.

Ces cinq points se répondent avant toute discussion de volume de traduction. Ils rejoignent la lecture de notre grille de priorisation d'audit SEO e-commerce, qui classe les chantiers par impact rapporté à l'effort plutôt que par ordre imposé.

Make Sense 4 Digital accompagne des marques e-commerce depuis ses bureaux de Lille et de Montréal, sur le SEO, Google Ads, Meta Ads et le CRM Klaviyo.

Trois vérifications avant d'ouvrir un budget international

1. Ouvrez le code source d'une fiche produit de votre version UK, relevez ses annotations, ouvrez la version US citée et vérifiez que le retour existe. Une paire non réciproque est ignorée, et l'anomalie se répète sur tout le catalogue.

2. Cherchez UK, EU ou un code de région employé seul dans vos annotations. Ces valeurs sont sans effet, et leur présence signale une intégration écrite à la main.

3. Appelez votre URL britannique depuis la France en navigation privée. Si vous êtes redirigé de force vers une autre version, vous reproduisez le comportement que la documentation demande d'éviter.

Ces trois lectures se mènent en interne, sans budget et sans outil payant. Si elles remontent des annotations ignorées ou une redirection qui masque une version entière, demandez un diagnostic SEO, regardez notre offre SEO e-commerce avec cette grille en main, ou écrivez-nous.