Quand une boutique prépare une ouverture à l'étranger, la première question est presque toujours la mauvaise : « comment poser les balises hreflang ? ». Ces balises ne font qu'exécuter des décisions prises en amont, et mal prises, elles codent en dur une erreur de stratégie. Voici les six décisions que je tranche avec mes clients avant toute ligne de code, dans l'ordre où elles se posent — une fois qu'elles sont posées, le hreflang devient presque mécanique.
Ce que le hreflang ne fait pas
Le hreflang est une instruction d'affichage : « montre cette version à qui lit depuis ce pays ou cette langue ». Il ne traduit pas un mot, ne positionne pas une page, ne fait pas remonter un produit dans un marché. Il ne crée pas de valeur locale non plus : si la page canadienne est la page française avec un symbole de devise changé, l'instruction changera qui la voit, pas ce qu'elle mérite.
La conséquence est simple à formuler : le hreflang ne peut améliorer que ce que les cinq décisions précédentes ont bien défini. C'est la dernière brique technique, pas la première. Google décrit lui-même ces signaux dans sa documentation sur les sites internationaux — langue, structure, signaux de localisation — et le hreflang y arrive à la fin.
Décision 1 — Un catalogue ou des catalogues
La question fondamentale : vos pays partageront-ils le même contenu ou auront-ils chacun le leur ? Tout découle de la réponse. Si une phrase s'adresse aussi bien à un Parisien qu'à un Bruxellois — mêmes produits, mêmes conditions, mêmes photos — vous n'avez pas deux pages à créer, vous avez une page à ne pas dupliquer. Deux URL strictement identiques, reliées par hreflang, restent deux URL identiques : Google les traite comme des doublons affichés selon le public, sans valeur ajoutée pour aucun marché.
En revanche, si la page doit changer — délais de livraison, tailles disponibles, garantie locale, avis de clients du pays, modèle de catalogue différent — alors chaque URL mérite son existence. Le test que j'applique : si la même phrase de description convient aux deux pays sans modification, la deuxième URL est du bruit ; si elle doit être écrite différemment, elle est légitime. Ce choix détermine le budget de traduction, la complexité du maillage et la durée du projet bien plus que n'importe quel réglage technique.
Décision 2 — La structure des URLs
Trois familles de structures existent, et le débat « domaine national ou sous-dossier ? » se gagne rarement à force d'arguments abstraits : il se tranche sur ce que vous pouvez réellement exploiter.
| Structure | Autorité SEO | Mise en place | Quand je la choisis |
|---|---|---|---|
| Domaine par pays (.be, .de, .co.uk) | Isolée : chaque domaine repart de zéro | La plus lourde : hébergement, certificats, DNS et suivi par domaine | Grand marché, notoriété locale déjà présente, budget conséquent |
| Sous-domaine (be.votresite.fr) | Partagée en théorie, souvent traitée comme un site séparé | Simple à créer | Équipes ou projets réellement autonomes par pays |
| Sous-dossier (votresite.fr/be/) | Partagée : chaque marché profite de l'autorité du domaine | La plus rapide à mettre en place | Défaut dans la grande majorité des projets que je vois réussis |
À cette structure s'ajoute le piège le plus coûteux de tous : la redirection automatique par adresse IP. Un visiteur canadien arrivant sur la page française est redirigé vers la version canadienne — l'utilisateur est bien traité, le robot de Google qui crawl depuis les États-Unis aussi, mais le robot de Bing, Ahrefs ou votre Search Console en France ? Ils se retrouvent tous servis en anglais ou en américain. Jamais de redirection géo-automatique : proposez un choix de pays visible, laissez chaque URL accessible depuis partout.
Décision 3 — Traduire ou localiser
Traduire, c'est transposer les mots. Localiser, c'est transposer ce qu'ils décrivent : des tailles de vêtements qui ne suivent pas les mêmes échelles, des photos de scène qui ne parlent pas à la cible, un vocabulaire technique qui existe dans un pays mais pas dans l'autre, des moyens de paiement locaux qui rassurent plus que n'importe quel argument. Un catalogue traduit automatiquement puis relu à la volée se positionne parfois, mais convertit rarement — et un taux de rebond élevé finit par peser.
Dans la pratique, je segmente : les pages qui portent de la vente (catégories, pages de marque, fiches best-sellers) sont travaillées par un traducteur qui connaît le secteur ; les pages longues traîne (guides, FAQ, notices) peuvent être traduites puis relues ; les pages techniques pures (CGV, tableau de tailles) supportent une relecture légère. Le budget se concentre là où se joue le chiffre d'affaires, pas sur la longueur totale du site.
Décision 4 — Prix, devise et taxes
Le prix n'est pas une donnée à traduire, c'est une décision commerciale. Afficher la même valeur en euros sur une boutique canadienne, c'est perdre les conversions avant même de parler de référencement ; convertir la devise sans ajuster le prix de vente, c'est arrondir au hasard. Le SEO n'a aucun levier là-dessus — c'est le premier point où je dis à un client que son consultant doit s'arrêter et que son responsable commercial doit commencer.
Attention en revanche au basculement de devise par adresse IP : si la même URL sert en euros à Googlebot et en dollars aux visiteurs locaux, le contenu que le robot mesure n'est pas celui que vous publiez. Basculez par marché, sur des URL distinctes ou un paramètre proprement géré, et gardez la devise cohérente pour chaque version signalée par hreflang. Le volet fiscal — TVA, enregistrement, seuils de vente par pays — sort explicitement de mon périmètre : un expert-comptable doit valider chaque marché avant l'ouverture, pas après la première vente.
Décision 5 — Relier les versions entre elles
Venons-en enfin au hreflang lui-même, puisque tout le reste est tranché. Les règles à respecter tiennent en peu de points, mais chacune casse tout le dispositif si elle est oubliée : chaque déclaration doit être réciproque (si A pointe vers B, B doit pointer vers A), les codes de langue suivent le format ISO 639-1 avec région en majuscules (fr-BE, en-GB), la version par défaut pour tout le reste se déclare en x-default, et les déclarations peuvent vivre dans les balises HTML ou dans le sitemap.
Le détail des trois méthodes d'implémentation, des erreurs qui neutralisent l'ensemble et de la procédure de vérification est dans mon guide dédié aux balises hreflang pour l'e-commerce — je n'ai pas à le répéter ici : cet article traite des décisions qui viennent avant. Côté pilotage, je vérifie ensuite que Search Console reçoit bien chaque marché (sitemap ou propriété par structure) et que les signaux racontent la même histoire que le code.
Décision 6 — Les contraintes de plateforme
Chaque plateforme impose sa grammaire, et l'ignorer coûte des mois. Shopify gère les marchés via ses fonctionnalités natives — domaines, langues, déclinaisons de prix — mais garde les mêmes limites structurelles que la version standard, notamment sur la maîtrise du fichier robots.txt : utile à connaître avant de promettre une architecture sur mesure. WooCommerce permet des URL par répertoire ou sous-domaine avec les extensions multilingues, à condition de les configurer avant la mise en ligne, pas après. PrestaShop gère pays et langues via sa fonction multiboutique — sa configuration définit comment les versions cohabitent, avec les pièges de duplication que j'ai décortiqués dans le guide de référencement PrestaShop.
En architecture headless, tout est à la main : les balises hreflang, les slugs par langue, la redirection géo. C'est le terrain le plus libre et le plus risqué — chaque oubli est invisible tant que personne ne vérifie. Quelle que soit la plateforme, la question à poser au prestataire n'est pas « gère-t-il l'international ? » mais « montrez-moi où vivront les URL de chaque marché dans six mois ».
Mon diagnostic d'expansion en vingt minutes
Avant d'ouvrir un marché, je fais passer cinq contrôles au projet. Un : les versions existent-elles déjà en ligne, ou seulement en recette ? Deux : une redirection géo coupe-t-elle l'accès des robots aux versions étrangères ? Trois : chaque URL a-t-elle son prix et sa devise stables ? Quatre : les pages du pays visé sont-elles une copie de la page française ou une vraie page locale ? Cinq : le site relie-t-il ses versions dans les deux sens ? En général, les trois dernières questions ne sont pas encore tranchées à ce stade — c'est exactement le signal que la structure n'a pas été décidée avant le calendrier commercial.
Plan 90 jours pour ouvrir un marché
L'ordre compte plus que la vitesse. Semaines 1 et 2 : structure des URLs et hébergement en place, aucune redirection géo, choix du périmètre de pages par pays. Semaines 3 à 6 : contenu localisé pour les catégories et les meilleures ventes ; prix et devise validés par la direction commerciale. Semaine 7 : versions en ligne, maillage entre marchés cohérent, choix pays visible. Semaine 8 : balises hreflang déployées sur le périmètre, vérification de réciprocité, sitemap par marché soumis. Semaines 9 à 12 : suivi dans Search Console par structure, correction des doublons signalés, puis uniquement après ces étapes, le travail d'autorité locale — liens régionaux, annuaires réellement fréquentés, presse du pays.
Ce que je ne fais pas
Trois limites à poser franchement. Je ne donne pas d'avis juridique ou fiscal : seuils de TVA et contrats locaux relèvent d'un professionnel du droit. Je ne promets pas de positionnement dans un marché où les acteurs locaux établis servent déjà la demande : l'ouverture d'un pays ne crée pas la demande, elle y amène votre catalogue. Et je ne fabrique pas des liens régionaux à la chaîne : une autorité locale se construit avec une présence locale réelle — j'ai écrit comment procéder côté netlinking pour l'e-commerce, la logique s'applique pays par pays.
FAQ : référencement e-commerce international
Faut-il un domaine national pour viser un pays ?
Presque jamais en premier. Le sous-dossier partage l'autorité du domaine existant et se met en place vite ; le domaine national se choisit quand le marché est assez grand pour justifier une notoriété autonome et un budget de développement distinct. La majorité des projets que j'accompagne démarrent en sous-dossier.
Le hreflang suffit-il à éviter les problèmes de contenu dupliqué ?
Non. Le hreflang indique quelle version montrer ; il ne dissimule pas deux pages identiques. Si deux URL ne diffèrent que par la devise ou rien du tout, elles doivent être fusionnées ou réellement différenciées — prix locaux, disponibilités, avis, conditions. La technique ne remplace pas l'adaptation.
Shopify gère-t-il l'international tout seul ?
Il gère les marchés — langues, domaines, tarification — et cela suffit à beaucoup de projets. En revanche, la maîtrise fine de l'exploration et de l'architecture reste limitée par rapport à une boutique auto-hébergée : à peser avant d'annoncer une stratégie internationale sur mesure.
Faut-il une propriété Search Console par pays ?
Une propriété par structure réelle (domaine, sous-domaine ou préfixe) donne la lecture la plus propre, et Google a retiré le réglage de ciblage pays : il déduit maintenant le marché cible des signaux — langue, structure, hreflang. C'est une raison supplémentaire de les rendre cohérents.
Combien de temps avant les premiers résultats sur un marché neuf ?
Le crawl et l'indexation des nouvelles URL prennent quelques semaines ; les positions, plusieurs mois selon la concurrence locale. Un site qui ouvre un pays avec du contenu adapté et des liens locaux gagne bien plus vite qu'un site qui publie la même page sous cinq drapeaux.
Pour préparer une expansion internationale sans se tromper de structure : je propose un accompagnement en référencement international e-commerce, de l'audit du dispositif existant au plan de déploiement. Parlons de votre marché cible via la page contact.
Et pour l'audit de ce qui existe déjà : mon audit SEO e-commerce vérifie les versions, les hreflang et les doublons d'un site déjà multilingue.
Consultant SEO e-commerce et expert Adobe Analytics, dans le web depuis 2007. J'aide les boutiques en ligne à gagner des clients grâce au référencement naturel.
