Pour un site international, la structure d'URL se résume à trois options. Un domaine national par pays (exemple.de, exemple.it), des sous-domaines (de.exemple.com) ou des sous-dossiers (exemple.com/de/). Les trois peuvent bien se positionner. Le bon choix dépend de vos moyens, de vos équipes locales et du nombre de marchés visés. Il doit ensuite être complété par des balises hreflang correctes, des canonical cohérentes, des URL lisibles et une migration propre si vous changez d'organisation.
Google traite chaque URL comme l'identifiant unique d'une page. Une version allemande et une version espagnole doivent donc avoir chacune leur propre adresse, sinon le moteur ne peut en indexer qu'une seule. C'est le défaut des widgets de traduction qui réécrivent le texte à la volée en JavaScript sur une URL unique. Le visiteur lit sa langue, Googlebot voit toujours la page d'origine, et la version traduite n'existe pas dans l'index.
La structure d'URL sert aussi de signal géographique. Une extension .de dit clairement que le site vise l'Allemagne. Un dossier /de/ sur un .com peut dire la même chose, à condition que les balises hreflang et le contenu le confirment. Changer de structure après coup reste possible, mais toujours au prix d'une migration. Mieux vaut donc trancher avant la mise en ligne de la première version étrangère, comme nous le rappelons dans les erreurs les plus fréquentes d'une stratégie SEO internationale.
Une URL comporte un protocole (https), un nom d'hôte (www.exemple.com, qui inclut l'extension et un éventuel sous-domaine), puis un chemin (/de/produkte/pumpen/). En SEO international, chacune de ces parties peut porter l'information de pays ou de langue. Le protocole, lui, doit être https partout, sans exception pour les versions étrangères.
Pour le chemin, les bonnes pratiques sont stables depuis longtemps. Google recommande de séparer les mots par des traits d'union plutôt que par des tirets bas, car le trait d'union est lu comme un séparateur de mots. Écrivez tout en minuscules, puisque le chemin d'une URL est sensible à la casse et que /Produits/ et /produits/ peuvent devenir deux pages distinctes. Gardez des adresses courtes, avec un ou deux mots qui décrivent la page, sans empiler les mots-clés. Retirez les mots vides quand ils n'apportent rien, ainsi que les virgules, espaces et autres signes qui seront encodés.
Le poids d'un mot-clé dans l'URL reste modeste. Son intérêt est surtout lisible. Une adresse claire rassure l'internaute qui la voit dans un résultat de recherche, dans un e-mail ou dans un message LinkedIn. Choisissez aussi une convention pour la barre oblique finale et tenez-la partout, car exemple.com/de/pumpen et exemple.com/de/pumpen/ sont techniquement deux URL.
Google décrit quatre façons d'organiser un site multirégional. La première est le domaine national, ou ccTLD, comme exemple.de ou exemple.es. La deuxième est le sous-domaine sur un domaine générique, comme de.exemple.com. La troisième est le sous-dossier, comme exemple.com/de/. La quatrième consiste à passer la langue en paramètre, comme exemple.com/?lang=de, et Google la déconseille explicitement, car le paramètre est fragile et mal compris des utilisateurs comme des outils.
Il existe aussi des formules hybrides. Une entreprise peut garder son .fr historique pour la France, ouvrir un .de parce qu'elle a une filiale à Munich, et regrouper les autres langues en sous-dossiers sur un .com. Ce qui pose problème, c'est l'incohérence non assumée, par exemple des sous-dossiers de langue sur le .fr, un sous-domaine pour l'anglais et un ccTLD pour l'Italie, sans logique de gestion derrière.
Pour choisir, posez trois questions concrètes. Combien de marchés visez-vous dans les trois prochaines années ? Avez-vous, dans chaque pays, quelqu'un capable de produire des contenus et d'obtenir des liens ? Votre outil de gestion de contenu sait-il gérer plusieurs domaines ou seulement plusieurs langues ? Les réponses tranchent généralement le débat plus vite que n'importe quel tableau comparatif.
Le ccTLD est le signal géographique le plus net. Un exemple.de est compris comme un site destiné à l'Allemagne, par Google comme par l'acheteur allemand, qui fait souvent davantage confiance à une extension de son pays. C'est aussi une façon claire de séparer les marchés, avec des hébergements, des équipes et des calendriers distincts.
Les limites sont réelles. Chaque domaine démarre avec sa propre autorité et doit gagner ses propres liens. Le coût de gestion se multiplie, puisqu'il faut suivre plusieurs propriétés, plusieurs certificats, plusieurs sitemaps. Certaines extensions imposent des règles d'enregistrement. Le .fr, par exemple, est réservé aux personnes et entreprises établies dans l'Union européenne ou dans quelques pays européens voisins. Et le domaine voulu est parfois déjà pris. Attention également aux extensions détournées de leur pays. Google traite des ccTLD comme .io, .co ou .tv comme des domaines génériques, qui ne ciblent aucun pays.
Mintense fonctionne elle-même avec des domaines nationaux, comme mintense.fr, mintense.it ou mintense.co.uk, chacun rédigé par des équipes de langue maternelle. Ce modèle tient parce que chaque site vit séparément, avec ses propres textes et ses propres priorités. Si vous n'avez pas les moyens d'alimenter chaque domaine, un ccTLD vide fera moins bien qu'un sous-dossier bien tenu.
Le sous-domaine (de.exemple.com) permet d'héberger chaque version sur une infrastructure différente, avec une installation séparée du CMS. C'est utile quand une filiale gère son propre site avec un prestataire local, ou quand une plateforme e-commerce impose une instance par pays. Le sous-domaine reste aussi plus simple à déployer qu'un nouveau domaine, puisqu'il suffit d'une entrée DNS.
Google affirme gérer correctement les sous-domaines comme les sous-dossiers et ne pas les pénaliser par principe. Sur le terrain, la difficulté est ailleurs. Un sous-domaine se comporte souvent comme un site à part dans les outils, dans les rapports et dans la tête des équipes. Le maillage interne entre les versions est moins naturel, les liens obtenus par la version allemande profitent moins visiblement aux autres, et le signal géographique est moins lisible pour l'internaute qu'un .de ou un /de/.
Avec des sous-dossiers (exemple.com/de/, exemple.com/es/), toutes les versions partagent un seul domaine, un seul hébergement et une seule autorité. Un lien obtenu par la version espagnole renforce le domaine entier. C'est l'option la plus économique à maintenir, et celle que la plupart des CMS gèrent nativement, qu'il s'agisse de WordPress avec WPML ou Polylang, de Shopify Markets ou de Drupal.
Le revers tient au signal géographique, moins fort qu'un ccTLD. Un dossier /de/ ne dit rien tout seul. Ce sont les balises hreflang, la langue du contenu, les prix, les adresses et les liens locaux qui font comprendre à Google que la page vise l'Allemagne. Autre limite, une panne ou une pénalité touche toutes les versions à la fois.
Un point mérite d'être tranché dès le départ. Si vous partez d'un domaine national comme exemple.fr, y ajouter /de/ ou /es/ fonctionne techniquement, mais le message reste ambigu, car le .fr est compris comme un site visant la France. Pour un projet de plusieurs pays, un domaine générique en .com, ou un ccTLD par marché, est plus cohérent. C'est une des premières décisions que nous prenons avec nos clients à l'agence SEO international.
Avant de dessiner les URL, décidez si vous ciblez une langue ou un pays. Un dossier /es/ vise tous les hispanophones. Un dossier /es-es/ vise l'Espagne et laisse la porte ouverte à /es-mx/ pour le Mexique. La différence compte dès que les prix, la TVA, les délais de livraison ou le vocabulaire changent. Un Espagnol parle d'ordenador, un Mexicain de computadora. Un Belge francophone écrit GSM là où un Français écrit portable.
Pour une PME qui démarre, cibler une langue est souvent suffisant. Une seule version allemande peut servir l'Allemagne, l'Autriche et la Suisse alémanique, quitte à créer plus tard des pages dédiées si un marché décolle. Ce qu'il faut éviter, c'est de créer dix versions régionales quasi identiques sans rien changer d'autre que le code pays. Google les verra comme des doublons et en choisira une, ce qui annule l'intérêt du découpage. Le sujet est développé dans notre article sur la duplication de contenu en SEO.
Les balises hreflang indiquent à Google quelle version afficher selon la langue et le pays de l'internaute. Elles se déclarent de trois façons, au choix, dans l'en-tête HTML de chaque page, dans l'en-tête HTTP pour les fichiers PDF, ou dans le sitemap XML. Pour un gros site, le sitemap évite d'alourdir le code de chaque page.
Les erreurs les plus courantes sont toujours les mêmes. Les codes doivent suivre la norme ISO 639-1 pour la langue et ISO 3166-1 alpha-2 pour le pays. On écrit donc en-gb pour le Royaume-Uni, jamais en-uk, et de-at pour l'Autriche. Un code pays seul, sans langue, est invalide. Chaque page doit se citer elle-même et citer toutes ses équivalentes, et ces équivalentes doivent la citer en retour. Sans cette réciprocité, Google ignore l'annotation. Les URL déclarées doivent être absolues, en https, et répondre en 200, sans redirection.
Ajoutez une valeur x-default pour la page à afficher quand aucune version ne correspond, souvent la version anglaise ou une page de choix de pays. Le rapport de ciblage international ayant été retiré de la Search Console, le contrôle passe désormais par un crawler comme Screaming Frog, qui liste les retours manquants et les codes invalides.
La balise canonical et les balises hreflang ne font pas le même travail, et les mélanger produit des pages invisibles. La canonical désigne la version de référence parmi des doublons d'une même page. Les hreflang relient des versions différentes destinées à des publics différents. Une page allemande doit donc avoir une canonical qui pointe vers elle-même, jamais vers la version française.
L'erreur classique se produit quand un CMS ou un module de traduction place automatiquement la canonical de toutes les langues sur la version d'origine. Google comprend alors que les pages traduites sont des copies et n'indexe que l'originale. Le symptôme se voit dans la Search Console, avec des pages étrangères classées « Autre page avec balise canonique correcte » ou signalées comme des doublons pour lesquels Google a retenu une autre canonique que la vôtre.
Deuxième règle, les URL citées dans les hreflang doivent être les URL canoniques. Si /de/produkte/?sort=price porte une canonical vers /de/produkte/, c'est cette dernière qui doit figurer dans le jeu hreflang.
Oui, dans la grande majorité des cas. Une page allemande sur les pompes industrielles sera plus lisible à l'adresse exemple.com/de/industriepumpen/ qu'à exemple.com/de/pompes-industrielles/. L'internaute allemand comprend l'URL dans le résultat de recherche, la partage plus volontiers, et le mot-clé local apparaît en clair. Garder le slug français sur une page allemande n'est pas pénalisant en soi, mais c'est un indice de traduction faite à moitié, que l'acheteur repère.
Traduire les URL suppose une discipline. Il faut une correspondance tenue à jour entre les versions, sinon les hreflang cassent à chaque modification. La plupart des modules multilingues gèrent cette correspondance, à condition de ne pas renommer les pages à la main dans une seule langue.
Le choix du mot qui va dans le slug relève de la recherche de mots-clés locale, pas du dictionnaire. En Allemagne, la requête la plus cherchée n'est pas toujours la traduction littérale du terme français. Notre article sur le SEO en Allemagne en donne plusieurs exemples.
Techniquement, Google accepte les caractères non ASCII dans les URL, encodés en UTF-8. En pratique, nous les déconseillons pour les langues à alphabet latin. Une URL comme /fr/référencement/ est transmise sous la forme /fr/r%C3%A9f%C3%A9rencement/ dès qu'elle est copiée dans un e-mail, un tableur ou certains outils d'analyse. Elle devient illisible, et les erreurs de double encodage produisent des 404 difficiles à repérer.
Un autre piège tient à la façon dont un même caractère accentué peut être codé de deux manières différentes en Unicode. Deux URL visuellement identiques peuvent alors être différentes pour le serveur. Le plus simple est de translittérer, en écrivant e pour é, a pour à, c pour ç. En allemand, l'usage courant transforme ü en ue, ö en oe, ä en ae et ß en ss, ce qui donne /de/fuehrung/ plutôt que /de/führung/.
La règle change pour les alphabets non latins. Pour un site en grec, en arabe ou en japonais, les URL natives sont parfois préférables, car une translittération serait incompréhensible pour l'internaute local. La décision se prend langue par langue, avec un locuteur natif, ce que permettent des équipes de langue maternelle.
Rediriger automatiquement un visiteur vers sa version locale selon son adresse IP ou la langue de son navigateur semble pratique. Google le déconseille pourtant. Googlebot explore principalement depuis des adresses IP situées aux États-Unis. Si chaque visiteur américain est renvoyé vers la version anglaise, le robot risque de ne jamais voir les versions française, allemande ou italienne.
La redirection automatique pose aussi des problèmes humains. Un acheteur allemand en déplacement en France se retrouve sur le site français. Un commercial suisse qui veut consulter la version italienne ne peut plus y accéder.
La bonne pratique consiste à laisser chaque URL accessible à tous, et à proposer la version locale par une bannière discrète, du type « Ce site existe en allemand, souhaitez-vous y accéder ? », que l'utilisateur peut refuser. Ajoutez un sélecteur de langue visible sur toutes les pages, avec des liens HTML classiques que le robot peut suivre, et des intitulés écrits dans la langue cible, Deutsch plutôt qu'allemand. Les drapeaux seuls sont à éviter, car une langue n'est pas un pays.
Passer de sous-domaines à des sous-dossiers, ou regrouper plusieurs ccTLD sur un .com, est une migration au sens plein. La première étape est un inventaire complet des URL existantes, issu d'un crawl, des sitemaps et des pages qui reçoivent du trafic ou des liens. Chaque ancienne URL reçoit ensuite une destination précise, la plus proche possible en contenu. Rediriger tout vers la page d'accueil fait perdre la plus grande partie de la valeur.
Les redirections doivent être permanentes, en 301 ou 308, directes, sans chaînes. Google recommande de les conserver au moins un an. Mettez à jour dans la foulée les hreflang, les canonical, le maillage interne et les sitemaps, pour qu'aucun lien interne ne passe par une redirection. Pour un changement de domaine ou de sous-domaine, l'outil Changement d'adresse de la Search Console accompagne la transition. Il ne couvre pas en revanche les réorganisations de chemins à l'intérieur d'un même domaine.
Prévoyez une baisse temporaire, le temps que Google réexplore les URL, et évitez de cumuler la migration avec une refonte graphique et une réécriture des contenus. Les liens externes les plus forts méritent enfin un contact avec les sites qui les publient pour faire corriger l'adresse, un sujet traité dans notre article sur les backlinks internationaux.
La structure d'URL détermine la finesse du suivi. Avec des ccTLD, chaque domaine est une propriété distincte. Avec des sous-dossiers, créez une propriété de domaine pour la vue d'ensemble, vérifiée par un enregistrement DNS, puis une propriété « préfixe d'URL » par dossier, comme https://www.exemple.com/de/. Chaque version linguistique dispose alors de ses propres rapports de performances, d'indexation et d'expérience sur la page.
Dans le rapport Performances, le filtre Pays montre d'où viennent les impressions, ce qui permet de vérifier que la version allemande est bien vue en Allemagne et pas seulement en France. Le croisement du filtre Page et du filtre Pays révèle les cas où la mauvaise version s'affiche, par exemple une page française qui reçoit des impressions en Belgique néerlandophone alors qu'une version néerlandaise existe. C'est souvent le premier signe d'un problème de hreflang.
Pensez aussi aux autres moteurs. Bing Webmaster Tools importe les propriétés de la Search Console en quelques clics, et Bing est le moteur par défaut du navigateur Edge, installé sur les postes Windows de nombreuses entreprises. Pour une méthode complète d'analyse par marché, voyez notre plan d'action pour améliorer un site à l'étranger.
Les principes de base n'ont pas changé, mais les moteurs génératifs ajoutent une contrainte. Les réponses de Google, de ChatGPT ou de Perplexity citent des sources par leur URL. Une adresse stable, lisible et cohérente avec le sujet de la page facilite la citation et inspire confiance quand elle s'affiche dans une réponse. Une page qui change d'adresse tous les ans perd ces références à chaque fois. Nous détaillons ces évolutions dans notre article sur Google et ChatGPT.
Pour un site lancé ou refondu cette année, voici les règles à poser dès le cahier des charges.
Le dernier point concerne l'ordre des chantiers. La structure d'URL se décide avant les traductions et avant la stratégie de liens, pas après. Pour situer ce choix dans un projet plus large, consultez notre guide de la stratégie SEO multilingue et notre article sur la visibilité dans les pays européens. Si vous préférez être accompagné sur l'audit de vos URL ou sur une migration, nos équipes SEO international interviennent dans 16 langues.
Un .com est un domaine générique, qui ne cible aucun pays par défaut. Il peut parfaitement se positionner en Allemagne, en Espagne ou en Italie, à condition que chaque version linguistique ait sa propre URL, des balises hreflang correctes et un contenu rédigé pour le marché visé. Ce qui fait la différence, ce sont les signaux locaux, comme les prix en euros, les coordonnées, les mentions légales et les liens venus du pays. L'extension seule ne garantit rien, ni dans un sens ni dans l'autre.
Oui, et c'est fréquent. Une entreprise peut garder un ccTLD sur ses deux ou trois marchés principaux, où elle a des équipes et des liens, et regrouper les autres langues en sous-dossiers sur un .com. Les balises hreflang fonctionnent entre domaines différents, à condition d'être réciproques. La condition est de documenter la règle, pour savoir où créer une nouvelle version, et de suivre chaque ensemble dans des propriétés Search Console distinctes.
Non. La plupart des widgets traduisent le texte dans le navigateur, sans créer de nouvelle URL. Google n'indexe alors que la version d'origine, et le site reste absent des résultats dans les autres langues. Certains services créent en revanche des URL traduites côté serveur, qui peuvent être indexées. Même dans ce cas, une traduction automatique non relue produit des textes que l'acheteur repère vite et des mots-clés qui ne correspondent pas aux recherches locales.
Google les déconseille pour séparer les langues. Un paramètre est facilement perdu lors d'un partage, d'une redirection ou d'un passage par un outil de suivi, et il rend l'URL moins lisible pour l'internaute. Les rapports d'analyse deviennent aussi plus difficiles à filtrer. Si votre site utilise aujourd'hui ce format, la migration vers des sous-dossiers est en général la plus simple, avec une redirection 301 de chaque URL paramétrée vers son équivalent.
Très peu. Google indique que l'emplacement du serveur n'est pas un signal déterminant, d'autant que les réseaux de diffusion de contenu servent les pages depuis des points proches du visiteur. L'hébergement joue surtout sur la vitesse. Un site hébergé en France et consulté depuis l'Asie sans CDN peut être lent, ce qui dégrade l'expérience. Pour l'Europe, un hébergement français ou européen bien configuré ne pose pas de difficulté particulière.
Normalement non, si la structure a été bien pensée au départ. Ajouter un pays revient alors à créer un nouveau dossier ou un nouveau domaine selon la règle choisie, puis à l'intégrer dans les hreflang de toutes les pages concernées. C'est ce dernier point qu'on oublie le plus souvent. La question de la structure se repose surtout quand un marché prend une importance telle qu'il justifie un ccTLD et une équipe dédiée.
