Sous-domaine ou sous-répertoire : quelle structure URL privilégier pour un site multilingue ?

Pourquoi Google autorise-t-il toutes les structures URL pour le multilingue ?

La position de Google est claire : la structure URL n'est pas un critère de classement en soi. Que vous optiez pour example.com/fr/, fr.example.com ou example.com?lang=fr, le moteur indexera et classera vos contenus de manière équivalente, tant que chaque URL ne sert qu'une seule langue.

Cette neutralité technique s'explique par l'évolution de la capacité de Googlebot à interpréter les signaux contextuels : balises hreflang, langue déclarée dans le HTML, contenu lui-même. Le choix de la structure relève donc davantage de contraintes techniques internes — architecture serveur, CMS, capacité de déploiement — que d'un impératif SEO strict.

Quelle différence entre site multilingue et site multi-pays ?

Mueller établit une distinction fondamentale que beaucoup confondent encore. Un site multilingue propose plusieurs langues sans ciblage géographique spécifique — exemple : un SaaS B2B en anglais, français, allemand sans préférence territoriale.

Un site multi-pays, en revanche, cible des marchés nationaux distincts avec des contenus, offres ou stratégies commerciales différenciés. Dans ce cas, Google exige une structure permettant le geo-targeting via Search Console : sous-domaines (fr.example.com), sous-répertoires (example.com/fr/) ou domaines séparés (example.fr). Les paramètres d'URL sont exclus pour le multi-pays — ils ne permettent pas de configurer le ciblage géographique.

Que signifie concrètement « une langue par URL » ?

Google refuse les URLs mixtes où plusieurs langues cohabitent sur la même page — pensez à ces sites avec sélecteur de langue en JavaScript qui modifie le DOM sans changer l'URL. Chaque version linguistique doit avoir sa propre URL canonique, stable et accessible indépendamment.

Cette règle impacte directement l'implémentation des hreflang : impossible de déclarer des alternatives linguistiques si l'URL reste identique. La segmentation par URL garantit que Googlebot peut crawler, indexer et servir la bonne version selon la langue de requête de l'utilisateur.

• Structures acceptées pour multilingue pur : sous-domaines, sous-répertoires, paramètres, domaines séparés
• Structures acceptées pour multi-pays : sous-domaines, sous-répertoires, domaines séparés uniquement (pas de paramètres)
• Obligation absolue : une langue unique par URL, pas de contenu mixte
• Configuration obligatoire pour multi-pays : geo-targeting dans Search Console par propriété ou sous-section
• Signal complémentaire requis : balises hreflang correctement implémentées pour toutes les structures

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, mais avec une nuance de taille : toutes les structures ne se valent pas en termes d'efficacité SEO opérationnelle. Google dit vrai quand il affirme qu'aucune structure n'est favorisée algorithmiquement — mais il omet les conséquences pratiques de chaque choix.

Les sous-domaines fragmentent l'autorité de domaine et multiplient les propriétés Search Console, complexifiant le pilotage. Les paramètres d'URL posent des problèmes de crawl budget et de duplication si mal configurés. Les sous-répertoires concentrent l'autorité sur un domaine unique mais compliquent la gestion technique quand plusieurs équipes gèrent des pays différents. La neutralité de Google ne signifie pas que votre choix est sans conséquence.

Quelles sont les zones d'ombre de cette déclaration ?

Mueller ne précise pas le comportement de Google face aux incohérences entre structure URL, hreflang et geo-targeting. Que se passe-t-il si un sous-répertoire /fr/ cible la Belgique via Search Console mais utilise des hreflang vers fr-FR ? [À vérifier] — les retours terrain montrent des incohérences d'indexation dans ces configurations hybrides.

Autre point : Google n'aborde pas les sites avec variantes régionales d'une même langue (français France vs français Canada, anglais US vs UK). La recommandation d'une langue par URL reste valide, mais comment Google arbitre-t-il entre /fr-fr/ et /fr-ca/ sans geo-targeting explicite ? Les observations montrent que le contenu et les signaux de localisation (serveur, backlinks locaux) prennent le relais — mais aucune confirmation officielle.

Dans quels cas cette règle ne suffit-elle pas ?

Les marchés complexes avec multi-langues par pays exposent les limites de la doctrine Google. Prenez la Suisse : français, allemand, italien, romanche. Faut-il créer example.com/ch-fr/, example.com/ch-de/, etc. ou example.com/fr/ avec geo-targeting Suisse ? Les deux approches sont valides techniquement, mais les implications sur le crawl budget, la duplication de contenu et la cohérence hreflang divergent radicalement.

Google conseille également de configurer le geo-targeting « par propriété ou sous-section » dans Search Console — mais la granularité réelle de ce paramètre reste floue. Un sous-répertoire peut-il cibler plusieurs pays simultanément ? Non selon l'interface, un seul pays par sous-section. Ce qui force à dupliquer /fr/ en /fr-fr/, /fr-be/, /fr-ch/ pour un ciblage fin — avec les risques de cannibalisation que cela implique.

Comment choisir la structure URL adaptée à votre contexte ?

Pour un site multilingue sans ciblage géographique strict, privilégiez les sous-répertoires (example.com/fr/, /de/, /es/). Ils concentrent l'autorité de domaine, simplifient la gestion Search Console et facilitent le déploiement technique sur un seul serveur ou CDN. Le seul cas où les sous-domaines se justifient : infrastructures techniques cloisonnées par marché, équipes autonomes par langue, ou contraintes CMS imposant cette segmentation.

Pour un site multi-pays avec stratégies commerciales distinctes, trois options viables : domaines séparés (example.fr, example.de) si vous avez les ressources pour gérer plusieurs propriétés et si l'identité locale est critique ; sous-domaines (fr.example.com) si vous voulez une gestion décentralisée mais un back-office unifié ; sous-répertoires (example.com/fr/, /de/) si vous recherchez la concentration maximale d'autorité et acceptez une complexité technique centralisée.

Quelles erreurs critiques éviter lors de l'implémentation ?

Ne jamais utiliser de paramètres d'URL pour le multi-pays — Google ne permet pas de configurer le geo-targeting sur example.com?country=fr. Cette structure reste acceptable pour du multilingue pur, mais elle pose des problèmes de crawl budget, de duplication et de partage sur les réseaux sociaux. À éviter sauf contrainte technique majeure.

Autre erreur fréquente : oublier de configurer le geo-targeting dans Search Console après avoir choisi sous-domaines ou sous-répertoires. Sans cette étape, Google tente de deviner le ciblage via IP serveur, ccTLD, contenu — avec des résultats souvent incohérents. Validez également que vos hreflang sont bidirectionnels et incluent toutes les variantes, y compris x-default pour les utilisateurs hors cible.

Comment auditer la conformité de votre structure actuelle ?

Vérifiez d'abord que chaque URL ne sert qu'une seule langue — inspectez le HTML source, pas seulement le rendu visuel. Les sélecteurs de langue en JavaScript qui modifient le DOM sans changer l'URL violent cette règle. Crawlez votre site avec Screaming Frog ou Oncrawl en analysant les attributs lang et hreflang pour détecter les incohérences.

Contrôlez ensuite la configuration Search Console : pour un site multi-pays, chaque sous-domaine ou sous-répertoire doit avoir son ciblage géographique explicite. Comparez cette configuration avec vos déclarations hreflang — toute divergence génère des signaux contradictoires pour Google. Enfin, testez l'affichage dans les SERP depuis différents pays via VPN ou outils comme Valentin.app pour valider que Google sert bien la bonne version selon la géolocalisation.

• Auditer la structure actuelle : une langue unique par URL, pas de contenu mixte
• Valider les balises hreflang : bidirectionnelles, complètes, incluant x-default
• Configurer le geo-targeting dans Search Console pour chaque propriété/sous-section multi-pays
• Éviter les paramètres d'URL pour le ciblage géographique
• Documenter la logique de choix (sous-domaine vs sous-répertoire vs domaine) selon les contraintes métier
• Tester l'affichage dans les SERP internationales pour confirmer le bon ciblage