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

Pourquoi Google exclut-il d'autres méthodes de séparation linguistique ?

La position de Google est claire : paramètres d'URL et cookies de détection ne sont pas recommandés pour gérer le multilinguisme. Les paramètres (exemple.com?lang=fr) posent des problèmes de canonicalisation et compliquent le crawl. Google doit indexer des variantes multiples d'une même URL, ce qui dilue les signaux de ranking.

Les cookies, quant à eux, sont invisibles pour Googlebot lors du premier passage. Le robot ne peut déterminer la langue d'une page si celle-ci s'affiche via détection navigateur. Résultat : indexation aléatoire, souvent dans la mauvaise version linguistique, et expérience utilisateur incohérente dans les SERPs.

Sous-domaines vs sous-répertoires : quelle différence technique pour Google ?

Un sous-domaine (fr.exemple.com) est techniquement traité comme une entité semi-autonome. Google lui attribue un budget crawl distinct, ce qui peut être un avantage si vos versions linguistiques sont volumineuses et nécessitent un crawl intensif indépendant. Mais cela signifie aussi que l'autorité de domaine ne se transfère pas automatiquement : chaque sous-domaine doit construire sa propre crédibilité.

Un sous-répertoire (exemple.com/fr/) bénéficie directement de l'autorité du domaine principal. Tous les backlinks pointant vers exemple.com renforcent également /fr/, /en/, /de/. Le crawl reste unifié, ce qui simplifie la gestion technique mais peut créer des embouteillages si le site est massif.

Le tag hreflang est-il vraiment obligatoire avec ces structures ?

Google ne dit pas « obligatoire », mais en pratique, hreflang est indispensable. Sans lui, même avec une structure sous-répertoire propre, Google ne peut garantir qu'il affichera la bonne version linguistique à l'utilisateur français, espagnol ou allemand.

Hreflang indique explicitement : « Cette page en /fr/ est la version française de /en/ et /de/ ». Sans ce signal, Google se base sur des indices contextuels (langue détectée dans le contenu, géolocalisation du serveur, liens entrants) qui sont souvent insuffisants ou contradictoires. Résultat : cannibalisation entre versions linguistiques dans les SERPs.

• Sous-domaines et sous-répertoires sont les deux structures validées par Google pour le multilinguisme
• Paramètres d'URL et cookies créent des problèmes d'indexation et de canonicalisation
• Hreflang reste essentiel quelle que soit la structure choisie pour éviter la cannibalisation entre versions
• Sous-domaines = budget crawl distinct, autorité à reconstruire ; sous-répertoires = autorité partagée, crawl unifié
• Le choix dépend du volume de contenu et de votre stratégie de netlinking internationale

Cette recommandation est-elle cohérente avec les observations terrain ?

Oui, largement. Les sites multilingues qui utilisent des paramètres d'URL rencontrent systématiquement des problèmes d'indexation : pages en double, mauvaise langue servie dans les SERPs, nécessité de canonical tags complexes qui finissent par créer plus de problèmes qu'ils n'en résolvent.

Cependant, Google reste volontairement flou sur un point : quel impact réel a le choix sous-domaine vs sous-répertoire sur le ranking ? Officiellement, aucun. En pratique, les sous-répertoires tendent à performer plus rapidement pour les nouveaux marchés linguistiques, simplement parce qu'ils héritent de l'autorité existante. [A verifier] : Google affirme traiter les sous-domaines « presque » comme des répertoires, mais les data montrent un delta de performance initial.

Quelles nuances faut-il apporter sur hreflang ?

Google dit « utilisez hreflang », mais ne précise pas que 90% des implémentations hreflang contiennent des erreurs. Les plus fréquentes : absence de balise de retour (si /fr/ pointe vers /en/, /en/ doit pointer vers /fr/), codes de langue incorrects (fr-FR au lieu de fr), URLs non-canoniques dans les balises.

Autre point que Google omet : hreflang ne garantit pas l'indexation de toutes vos versions. Si votre contenu en /de/ est une traduction mot-à-mot de /en/ sans valeur ajoutée locale, Google peut choisir de ne pas l'indexer, hreflang ou pas. Le signal linguistique ne compense pas un contenu dupliqué inter-langues.

Dans quels cas cette recommandation devient-elle insuffisante ?

Pour les sites gérant à la fois langue ET pays (exemple : français France vs français Belgique), Google recommande une structure combinée : fr-fr.exemple.com ou exemple.com/fr-fr/. Mais cela crée une complexité exponentielle. Un site avec 5 langues et 10 pays = 50 versions potentielles.

Dans ces cas, la stratégie hreflang doit être scriptée, automatisée et auditée en continu. Une erreur sur une seule balise peut casser toute la chaîne. Google ne fournit aucun outil natif pour valider massivement les implémentations hreflang complexes, ce qui est un vrai problème pour les sites enterprise.

Quelle structure choisir entre sous-domaine et sous-répertoire ?

Si vous lancez un nouveau marché linguistique et que votre domaine principal a déjà de l'autorité, privilégiez les sous-répertoires. Vous bénéficierez immédiatement du trust et des backlinks existants. C'est la solution la plus efficace pour accélérer le positionnement initial.

Si vous gérez des volumes de contenu massifs par langue (plusieurs centaines de milliers de pages), les sous-domaines offrent plus de souplesse technique : serveurs géolocalisés distincts, équipes de contenu indépendantes, budgets crawl séparés. Mais vous devrez investir dans le netlinking spécifique pour chaque sous-domaine.

Comment implémenter hreflang sans erreur critique ?

Utilisez les trois méthodes simultanément si possible : balises HTML dans le head, HTTP headers pour les PDFs et fichiers non-HTML, et sitemap XML comme filet de sécurité. Google crawle les trois sources et peut corriger des incohérences mineures.

Testez systématiquement avec la Search Console : section « Ciblage international » (anciennement « Balises hreflang »). Google signale les erreurs de retour, les URLs canoniques manquantes, les codes de langue invalides. Mais attention, la validation Search Console est asynchrone : une erreur corrigée peut mettre 2-3 semaines à disparaître du rapport.

Quelles erreurs éviter absolument lors de la migration ?

Ne changez jamais de structure (sous-domaine vers sous-répertoire ou inverse) sans plan de redirection exhaustif. Google doit comprendre que fr.exemple.com/page-A est devenu exemple.com/fr/page-A. Les redirections 301 doivent pointer exactement vers l'équivalent linguistique, pas vers la homepage du nouveau sous-répertoire.

Évitez de mélanger les approches : si vous utilisez des sous-répertoires pour le français et l'anglais, ne passez pas soudainement à un sous-domaine pour l'allemand « parce que l'équipe locale le demande ». Google peut interpréter cela comme un signal de faible cohérence éditoriale, ce qui impacte le trust global.

• Auditer la structure actuelle : identifier tous les paramètres d'URL ou cookies de langue encore présents
• Choisir sous-domaine OU sous-répertoire en fonction de l'autorité du domaine et du volume de contenu par langue
• Implémenter hreflang en triple : HTML head, HTTP headers, sitemap XML
• Valider chaque langue via Search Console section ciblage international avant de pousser en production
• Configurer des alertes monitoring pour détecter les erreurs hreflang post-déploiement (outils type OnCrawl, Botify, Screaming Frog)
• Documenter la logique de redirection 301 si migration depuis paramètres d'URL ou autre structure