Une question reçue d'une agence partenaire résume bien le sujet. Camille m'écrivait : « Nous avons un prospect qui veut un site marchand multilingue (FR, EN, DE, ES, PT) sous PrestaShop, couplé à l'ERP Dolibarr. Quelle structure privilégier pour un bon référencement international : monsite.fr et monsite.de, fr.monsite.com et de.monsite.com, ou monsite.com/fr et monsite.com/de ? » J'avais répondu à l'époque en recommandant les domaines nationaux sans trop de nuance. Avec le recul et quelques projets de plus, ma réponse est plus prudente : la structure d'URL compte, mais moins que la cohérence entre cible, balisage hreflang et contenu réellement localisé.
Cet article détaille la méthode que j'applique aujourd'hui pour un site qui vise plusieurs pays ou plusieurs langues : choisir entre ciblage par langue et ciblage par pays, comparer les trois structures d'URL, poser un hreflang correct, localiser le contenu au-delà de la traduction, puis déployer par étapes. Il s'adresse au dirigeant ou au responsable marketing qui doit arbitrer avant de lancer le chantier.
Pourquoi le référencement international se prépare
L'achat transfrontalier est réel mais minoritaire. D'après les données Eurostat 2024 reprises dans le European E-commerce Report 2025 (Ecommerce Europe et EuroCommerce), 83 % des Européens de l'UE-27 ayant acheté en ligne au cours des trois derniers mois l'ont fait auprès de vendeurs nationaux, 33 % auprès de vendeurs d'un autre pays de l'UE et 20 % auprès de vendeurs hors UE. Les écarts par pays sont importants : en Allemagne, seuls 20 % des acheteurs en ligne ont commandé chez un vendeur d'un autre pays de l'UE, contre 45 % au Portugal et 39 % en France.
La langue pèse sur la décision d'achat. L'étude « Can't Read, Won't Buy » de CSA Research (2020, 8 709 consommateurs interrogés dans 29 pays) indique que 76 % des acheteurs en ligne déclarent préférer un produit présenté dans leur langue, et que 40 % déclarent ne jamais acheter sur un site dans une autre langue. Ce sont des réponses déclaratives, mais elles confirment qu'une version anglaise unique ne couvre pas un marché allemand ou portugais.
Première décision : cibler une langue ou un pays
La question de Camille mélange deux notions. FR, EN, DE, ES, PT sont des langues. L'espagnol se lit en Espagne et au Mexique, le portugais au Portugal et au Brésil, l'anglais partout. Avant de parler d'URL, il faut savoir si le site vend dans un pays donné (prix, TVA, livraison, droit de la consommation) ou s'il s'adresse à une communauté linguistique sans distinction de pays.
- Ciblage par langue : une version par langue, sans pays. Adapté aux services, aux logiciels, au B2B qui livre partout. Le hreflang porte un code langue seul (
de,es). - Ciblage par pays : une version par couple langue-pays (
fr-FR,fr-BE,de-DE,de-AT). Nécessaire quand les prix, la logistique ou les mentions légales changent d'un pays à l'autre. - Mixte : le cas le plus fréquent en e-commerce. Par exemple
fr-FR,de-DE,es-ES,pt-PTet une versionengénérique.
Ce choix détermine le nombre de versions à maintenir, donc le budget de traduction et de suivi. Mieux vaut le fixer avant de signer le devis.
Les trois structures d'URL comparées
Google documente quatre organisations possibles dans son guide Gérer les sites multirégionaux et multilingues : domaine national (ccTLD), sous-domaine, sous-répertoire, et paramètres d'URL, cette dernière option étant déconseillée. Le tableau résume les trois premières avec les critères qui comptent pour une PME.
| Critère | ccTLD (monsite.de) | Sous-domaine (de.monsite.com) | Sous-répertoire (monsite.com/de/) |
|---|---|---|---|
| Signal géographique | Fort et automatique, un seul pays par domaine | Faible sans hreflang | Faible sans hreflang |
| Autorité et liens | À construire pour chaque domaine | Partiellement partagée, traitée souvent comme un site distinct | Concentrée sur un seul domaine |
| Coût et maintenance | Plusieurs domaines, plusieurs propriétés Search Console, parfois plusieurs installations | Un domaine, configuration serveur séparée possible | Un domaine, une installation, un certificat |
| Perception utilisateur | Extension locale rassurante | Neutre | Neutre |
| Ciblage par langue sans pays | Inadapté (un ccTLD vise un pays) | Possible | Possible |
Ma réponse à Camille aujourd'hui : pour une PME qui lance cinq langues en même temps sur une seule boutique PrestaShop reliée à un ERP, le sous-répertoire est le choix le plus raisonnable. Une seule installation, un seul catalogue synchronisé avec Dolibarr, une autorité de domaine qui profite à toutes les versions. Le ccTLD reste pertinent quand l'entreprise a une présence réelle dans le pays (filiale, stock, service client local) et les moyens d'animer un site par marché. Le sous-domaine est un compromis que je réserve aux cas où l'hébergement ou la technologie doit différer par pays.
Point important : depuis 2022, Google a retiré le rapport Ciblage international de la Search Console. On ne peut plus déclarer manuellement le pays visé par un sous-domaine ou un sous-répertoire. Le ciblage repose donc sur le ccTLD, le hreflang, et les signaux de contenu (adresse, devise, langue). L'argument « il faudra configurer le ciblage dans la Search Console » est périmé.
hreflang : les règles qui font échouer la plupart des sites
Le balisage hreflang indique à Google quelle version servir pour quelle langue ou quel pays. Google accepte trois supports, équivalents de son point de vue : des balises link dans le head, un en-tête HTTP Link, ou un sitemap XML avec des éléments xhtml:link. Pour une boutique de plusieurs milliers d'URL, le sitemap est souvent le plus simple à générer et à vérifier.
<link rel="alternate" hreflang="fr-FR" href="https://monsite.com/fr/produit/" />
<link rel="alternate" hreflang="de-DE" href="https://monsite.com/de/produkt/" />
<link rel="alternate" hreflang="es-ES" href="https://monsite.com/es/producto/" />
<link rel="alternate" hreflang="pt-PT" href="https://monsite.com/pt/produto/" />
<link rel="alternate" hreflang="en" href="https://monsite.com/en/product/" />
<link rel="alternate" hreflang="x-default" href="https://monsite.com/" />Les règles que Google énonce et que je vérifie systématiquement en audit :
- Réciprocité : chaque page doit lister toutes ses variantes, y compris elle-même. Si la page allemande ne renvoie pas vers la page française, les annotations sont ignorées.
- URL absolues, avec le protocole, et pointant vers la version canonique (pas vers une redirection ni une URL bloquée).
- Codes valides : langue en ISO 639-1, pays en ISO 3166-1 alpha-2. Un code pays seul (
hreflang="FR") est invalide ;UKetEUne sont pas acceptés (le Royaume-Uni s'écritGB). - x-default : à réserver à une page de choix de langue ou à la version par défaut, pour les visiteurs qui ne correspondent à aucune variante.
- Cohérence avec la canonique : une page dont la balise canonical pointe vers une autre langue annule l'effet du hreflang.
Le rapport d'erreurs hreflang de la Search Console a disparu avec le rapport Ciblage international. Il faut donc contrôler le balisage avec un crawler (Screaming Frog, Sitebulb ou équivalent) après chaque mise en production, et surveiller l'indexation de chaque version. Le service de contrôle de l'indexation couvre précisément ce suivi.
Localiser le contenu, pas seulement le traduire
Un site traduit mot à mot reste un site français en costume étranger. Google déconseille par ailleurs d'adapter le contenu selon l'adresse IP, jugée peu fiable ; Googlebot explore surtout depuis des adresses américaines. Il faut donc des URL distinctes par version, chacune avec son contenu complet, et un sélecteur de langue visible plutôt qu'une redirection forcée.
Ce qui doit changer d'une version à l'autre :
- les prix en devise locale, la TVA applicable et les frais de port réels ;
- les moyens de paiement attendus dans le pays et les transporteurs connus localement ;
- les mentions légales, CGV et conditions de retour conformes au droit du pays ;
- les titres, méta-descriptions, slugs d'URL et données structurées dans la langue de la page ;
- le vocabulaire et les unités (le portugais du Brésil n'est pas celui du Portugal ; le français du Québec a ses propres termes commerciaux).
La traduction automatique a sa place pour un premier jet sur un catalogue volumineux, mais une relecture humaine par un locuteur natif reste nécessaire sur les pages qui vendent et sur tout ce qui engage juridiquement. Les erreurs de traduction célèbres en marketing montrent ce que coûte une formule mal adaptée. Rappel aussi que la politique anti-spam de Google cite les contenus produits en masse par transformation automatique, traduction comprise, sans valeur ajoutée, et les pages ou domaines ciblant des régions qui renvoient tous vers une même page (« doorway abuse »). Cinq domaines avec le même texte anglais et un drapeau différent relèvent de ce cas.
Pour situer l'enjeu de la langue : d'après W3Techs (relevé du 10 septembre 2026), 49,5 % des sites web dont la langue est identifiée sont en anglais, contre 6,0 % en espagnol, 5,9 % en allemand, 4,5 % en français et 4,1 % en portugais. Une version locale soignée affronte donc une offre bien moins dense qu'une version anglaise.
Déployer par étapes
Ouvrir cinq langues le même jour multiplie les risques : catalogue partiellement traduit, hreflang incomplet, service client débordé. Ma recommandation reste de commencer par le marché principal plus un marché test, puis d'étendre quand les indicateurs le justifient.
- Phase 1 : version française complète et une seconde langue-pays choisie sur des critères concrets (demande déjà observée dans les commandes, logistique maîtrisée, capacité à répondre aux clients). Balisage hreflang et sitemaps par langue en place dès le départ.
- Phase 2 : mesure pendant trois à six mois. Pages indexées par version, impressions et clics par pays dans la Search Console (filtre Pays), taux de conversion par langue dans l'outil d'analyse d'audience.
- Phase 3 : extension aux langues suivantes, une par une, en reprenant la même liste de contrôle. C'est aussi le moment de décider si un marché mérite un ccTLD dédié et une présence locale.
Côté WordPress, le choix de l'extension multilingue conditionne beaucoup de ces points (URL par langue, hreflang généré, sitemaps séparés). J'en parle dans l'article sur la traduction d'un site WordPress en plusieurs langues. Sur PrestaShop, même logique : URL propres, métadonnées traduites et hreflang réciproque à vérifier avant de traduire le premier produit.
Questions fréquentes
Faut-il un nom de domaine par pays pour se référencer à l'international ?
Non. Un domaine national (.de, .es) donne un signal géographique fort, mais des sous-répertoires ou des sous-domaines fonctionnent aussi, à condition de poser un balisage hreflang correct et un contenu propre à chaque version. Le domaine par pays se justifie surtout quand l'entreprise a une présence réelle dans le pays et les moyens d'animer un site distinct.
Le hreflang améliore-t-il le classement d'une page ?
Non, il ne fait pas monter une page. Il indique à Google quelle version linguistique ou nationale afficher à quel utilisateur, ce qui évite qu'une page française apparaisse à un internaute allemand. Pour être pris en compte, chaque page doit lister toutes ses variantes, y compris elle-même, avec des URL absolues.
Peut-on encore déclarer un pays cible dans la Search Console ?
Non. Google a retiré le rapport Ciblage international de la Search Console en 2022, avec la possibilité de choisir un pays pour un sous-domaine ou un sous-répertoire. Le ciblage repose désormais sur l'extension du domaine, le hreflang et les signaux présents dans le contenu (langue, devise, adresse).
La traduction automatique suffit-elle pour un site multilingue ?
Elle peut servir de premier jet sur un gros catalogue, mais une relecture par un locuteur natif reste nécessaire sur les pages commerciales et juridiques. Google classe parmi les abus les contenus produits en masse par transformation automatique sans valeur ajoutée, et les pages ciblant des régions qui se contentent de renvoyer vers une page unique.
Faut-il rediriger automatiquement le visiteur vers sa langue selon son adresse IP ?
Google déconseille d'adapter le contenu selon l'adresse IP, jugée peu fiable, et son robot explore surtout depuis des adresses américaines. La bonne pratique consiste à proposer des URL distinctes par langue, à afficher un sélecteur de langue visible et, au plus, à suggérer une version sans forcer la redirection.
Combien de temps faut-il pour voir des résultats sur un nouveau marché ?
Il n'existe pas de délai garanti. Une nouvelle version doit d'abord être explorée et indexée, puis obtenir des liens et des signaux d'usage dans le pays visé, ce qui prend généralement plusieurs mois. Le suivi se fait par version : pages indexées, impressions et clics par pays, conversions par langue.