SEO multilingue : hreflang, structure et localisation

Un site multilingue ne se résume pas à un ensemble de pages traduites. Du point de vue SEO, c’est un défi d’architecture à part entière : Google doit comprendre quelle version s’adresse à quelle audience, où se trouve la page canonical et comment la popularité transmise se répartit entre les versions linguistiques. Une structure mal choisie devient une dette technique pendant des années.

Trois stratégies de structure d’URL

Google prend officiellement en charge trois approches de structure d’URL pour les sites multilingues et multirégionaux. Chacune a ses atouts, ses limites et ses exigences d’infrastructure.

zoom_in

Sur les paramètres clés : les sous-répertoires l’emportent sur la concentration de la popularité transmise et la simplicité de maintenance. Les ccTLD l’emportent sur la force du signal géographique. Les sous-domaines ne gagnent dans aucune de ces catégories et sont peu à peu abandonnés.

Géociblage : villes, régions et pays

Le SEO régional est une discipline à part entière au sein de l’architecture multilingue. Quand un internaute cherche « rénovation d’appartement à Munich », Google veut afficher un site qui signale sa pertinence pour cette ville précisément. Plusieurs mécanismes fonctionnent ensemble.

Géociblage par l’URL

Sous-répertoires avec le code d’une région ou d’une ville dans l’URL : /london/, /berlin/, /warsaw/. Ou domaines ccTLD pour les pays : .de pour l’Allemagne, .fr pour la France, .pl pour la Pologne. Le robot lit le signal de l’URL avant d’analyser le contenu de la page.

Géociblage via la Search Console

Pour les sous-domaines et les TLD génériques (.com, .org), vous pouvez indiquer un pays cible dans les paramètres de la propriété Google Search Console. C’est un signal complémentaire, plus faible qu’un ccTLD. Il ne s’applique pas aux sous-répertoires, seulement au domaine ou au sous-domaine dans son ensemble.

Géociblage via le contenu et le NAP

Mentions de la ville, de la région, de l’adresse et des numéros de téléphone locaux dans le contenu (NAP : Name, Address, Phone). Important pour le SEO local. Google croise les signaux du contenu avec les données de Google Maps et de Google Business Profile.

Pour les entreprises implantées dans plusieurs villes, la structure optimale est un domaine principal avec des sous-répertoires : site.com/london/, site.com/berlin/. Des pages distinctes pour chaque ville, avec un contenu unique, et pas seulement un nom de ville remplacé. Le contenu dupliqué avec des noms de villes interchangés fait partie des filtres les plus fréquents en SEO local.

Choix de la plateforme : WordPress, MODX, Next.js et CMS headless

Le choix du CMS influence fortement les capacités multilingues et multirégionales. Chaque plateforme répond au problème à sa façon, avec des compromis différents en matière de flexibilité, de coût de développement et d’évolutivité.

Pour un site d’entreprise bilingue simple, WordPress + WPML est un choix raisonnable. Pour un réseau régional complexe comptant des dizaines de domaines, seul Next.js convient. MODX se justifie lorsque l’équipe travaille déjà avec cette plateforme et possède l’expertise nécessaire.

Next.js et multidomaine : un monorepo, plusieurs ccTLD

C’est l’architecture la plus puissante, et la plus complexe à mettre en œuvre. Le principe : une seule base de code, un seul dépôt, un seul pipeline de déploiement, mais plusieurs domaines ccTLD indépendants pour différents pays. Elle n’est accessible qu’avec Next.js (et Nuxt 3, dans un paradigme proche) : WordPress et MODX ne peuvent pas la reproduire sans une refonte profonde de l’infrastructure.

Fonctionnement concret : dans next.config.ts, vous décrivez les domaines et les locales qui leur correspondent. Le middleware intercepte la requête, vérifie le nom d’hôte (seohead.ru → ru, seohead.com → en, seohead.de → de) et définit la locale appropriée sur la requête. Tous les composants, traductions et métadonnées SEO reçoivent la bonne locale, sans duplication de code.

Cette solution convient aux entreprises présentes dans 3 pays ou plus, avec des ccTLD spécifiques, disposant d’une équipe de développement (et non d’un seul freelance) et d’une stack Next.js existante ou prévue. Pour une petite entreprise avec une ou deux langues, c’est excessif.

Localisation et traduction : bien faire les choses

La localisation n’est pas la traduction. Traduire, c’est restituer le sens dans une autre langue. Localiser, c’est adapter le contenu au contexte culturel, aux attentes de l’audience et aux usages locaux. L’enjeu SEO est majeur : une traduction automatique produit du contenu dupliqué de faible qualité, que Google sait de mieux en mieux détecter.

Traduction automatique (DeepL, Google Translate)

Rapide et peu coûteuse, mais elle exige une relecture obligatoire par un locuteur natif. Une traduction automatique brute, sans post-édition, n’est pas une localisation : c’est un facteur de risque pour une pénalité liée au contenu pauvre. Utilisez-la comme premier jet, pas comme résultat final.

Traduction professionnelle avec localisation

Un traducteur natif adapte non seulement le texte, mais aussi les exemples, les études de cas, les unités de mesure, les formats de date et de monnaie, ainsi que les références culturelles. C’est coûteux, mais c’est la bonne approche pour les pages clés : accueil, services, à propos.

Outils TAO et mémoire de traduction (TM)

Pour de gros volumes de contenu : Phrase (anciennement Memsource), Lokalise, Crowdin. Ils conservent les traductions de termes validées et font gagner jusqu’à 40 % de temps lors des mises à jour. Ils s’intègrent à la base de code via les pipelines CI/CD.

Les mots-clés SEO dans les langues cibles doivent être recherchés indépendamment : la traduction directe d’une expression clé ne correspond souvent pas à ce que les natifs recherchent réellement. Utilisez Ahrefs ou Semrush en ciblant le pays visé, et non un outil de traduction.

Configuration SEO : hreflang, sitemap, canonical

La configuration SEO technique d’un site multilingue repose sur plusieurs éléments obligatoires. En négliger un seul provoque une confusion d’indexation et une perte de trafic.

Que choisir : sous-répertoires ou multidomaines

Conseil général : commencez par analyser les concurrents dans chaque région visée. Si les cinq premiers de votre niche en Allemagne sont des ccTLD allemands (.de), le sous-répertoire example.com/de/ fonctionnera, mais avec un désavantage structurel. Si vos concurrents utilisent des sous-répertoires, inutile d’investir dans des ccTLD.

Choisissez les sous-répertoires lorsque

L’entreprise est petite ou moyenne, sans équipes dédiées par pays. Le budget est limité. La rapidité de lancement compte. Les concurrents des régions visées utilisent aussi des sous-répertoires. La solution passe bien à l’échelle : ajouter une langue revient à ajouter un dossier et des traductions.

Choisissez les ccTLD lorsque

Vous êtes présent sérieusement dans des pays précis, sur un marché très concurrentiel. Vos concurrents utilisent des ccTLD. Vous disposez d’équipes ou d’un budget pour entretenir chaque domaine de façon indépendante. La confiance locale maximale est essentielle (finance, e-commerce, services juridiques).

Évitez les sous-domaines

Les sous-domaines cumulent les inconvénients des deux autres options : la popularité transmise circule moins bien qu’avec les sous-répertoires, le signal géographique est plus faible qu’avec les ccTLD, et la maintenance est plus complexe que pour des sous-répertoires. Ne les utilisez que si l’architecture technique l’exige (par exemple, un SaaS avec des domaines personnalisés pour ses clients).

En pratique, la plupart des entreprises commencent par des sous-répertoires et migrent vers des ccTLD en grandissant. Des redirections 301 bien configurées et des hreflang garantissent une migration sûre, sans perte de positions. Aucune approche n’est définitive : l’architecture peut évoluer, à condition de disposer d’un plan de migration technique adapté.

FAQ