Sous-domaines ou sous-répertoires pour l'international : quelle architecture hreflang Google privilégie-t-il vraiment ?

Pourquoi Google penche-t-il pour les sous-répertoires plutôt que les sous-domaines ?

La déclaration de John Mueller tranche un débat vieux de quinze ans. Historiquement, Google a toujours affirmé traiter sous-domaines et sous-répertoires de manière équivalente côté indexation. Cette neutralité technique n'a jamais changé.

Ce qui change, c'est la consolidation des signaux. Avec des sous-répertoires, tous les backlinks, l'ancienneté du domaine, le trust accumulé profitent à l'ensemble du site. Avec des sous-domaines, chaque instance est traitée comme une entité semi-autonome — un peu comme si vous gériez plusieurs sites distincts sous la même ombrelle.

En quoi cela impacte-t-il concrètement l'attribution des signaux de ranking ?

Les sous-domaines fragmentent l'autorité. Un lien entrant vers fr.example.com ne remonte pas directement vers en.example.com ou vers le domaine racine. Google peut transférer une partie de ce trust, mais c'est moins direct, moins automatique.

Avec des sous-répertoires, chaque backlink vers /fr/ renforce le domaine principal, et donc tous les autres répertoires linguistiques par ricochet. C'est particulièrement critique pour des sites de 3-5 langues qui n'ont pas les moyens de bâtir un profil de liens indépendant pour chaque version.

Qu'en est-il de l'analytics et de la maintenance technique ?

Un point souvent sous-estimé : la gestion opérationnelle. Avec des sous-domaines, vous multipliez les propriétés Search Console, les profils Google Analytics, les configurations GTM. Chaque version linguistique devient un silo.

Les sous-répertoires simplifient radicalement l'infra : une seule propriété GSC, un seul GA4, un seul suivi de performances. Vous comparez les versions en deux clics, pas en jonglant entre dix onglets. Pour une équipe SEO qui gère déjà trois métiers différents, ce gain de temps n'est pas anecdotique.

• Consolidation des signaux : backlinks et trust profitent à l'ensemble du domaine avec des sous-répertoires
• Fragmentation évitée : les sous-domaines créent des entités semi-autonomes qui diluent l'autorité globale
• Simplicité opérationnelle : une seule propriété Search Console et Analytics pour tous les marchés
• Hreflang simplifié : moins de risques d'erreurs de configuration inter-domaines
• Budget crawl optimisé : Google explore plus efficacement une structure unifiée qu'un archipel de sous-domaines

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même un des rares cas où le discours officiel colle parfaitement aux observations empiriques. Les sites internationaux qui migrent de sous-domaines vers sous-répertoires constatent régulièrement une amélioration du trafic organique dans les 3-6 mois post-migration — à condition que la migration soit propre.

Par contre, ce n'est pas un levier miraculeux. Si vos contenus sont faibles, si vous avez zéro backlinks par marché, passer aux sous-répertoires ne va pas créer du trafic ex nihilo. Ça optimise la distribution de ce que vous avez déjà, point.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Mueller parle explicitement de sites à 3-5 langues. Dès que vous dépassez 10-15 marchés avec des équipes locales autonomes, des marques distinctes par pays, ou des contraintes légales de séparation géographique, les sous-domaines reprennent du sens.

Exemple : un groupe média qui opère des marques différentes par pays (LeParisien.fr, DerSpiegel.de) ne va évidemment pas tout fusionner sous un domaine global. De même, certains secteurs (finance, santé) imposent des hébergements régionalisés qui rendent les sous-domaines incontournables. [À vérifier] : Google affirme que les sous-domaines restent « possibles », mais ne précise jamais à partir de quel seuil de complexité ils redeviennent préférables. Cette zone grise laisse de la place à l'interprétation.

Faut-il migrer un site existant en sous-domaines vers des sous-répertoires ?

Ça dépend de ton coût d'opportunité. Si tu as déjà un site mature en sous-domaines, avec des profils de liens bien établis par version linguistique, migrer va mobiliser 3-6 mois de dev, QA, redirections 301 massives, surveillance post-migration.

Si ton site stagne ou régresse, que tes sous-domaines ont du mal à décoller, alors oui, envisage la migration. Mais si tes performances sont correctes, que tu n'as pas de ressources dev disponibles à court terme, ne casse pas quelque chose qui fonctionne juste pour cocher une case. Priorise d'abord le contenu et les liens — ces leviers restent 10x plus impactants qu'une optimisation d'architecture.

Que faut-il faire concrètement pour un nouveau site multilingue ?

Si tu lances un site international de zéro, privilégie les sous-répertoires par défaut. Configure example.com/fr/, example.com/en/, example.com/de/ dès le départ. Implémente hreflang en annotations HTML (balises dans le ) ou via le sitemap XML.

Assure-toi que chaque page ait ses balises hreflang vers toutes les versions linguistiques équivalentes, y compris une référence à elle-même. Erreur classique : oublier la déclaration x-default pour désigner la version par défaut quand l'utilisateur ne matche aucune langue cible.

Comment migrer un site en sous-domaines vers des sous-répertoires sans tout casser ?

Première étape : cartographie complète de l'existant. Liste toutes les URLs par sous-domaine, leur trafic organique, leurs positions, leurs backlinks. Construis une matrice de redirections 301 exacte, page à page, pas de wildcard approximatif.

Configure le nouveau setup en staging. Teste les redirections, le hreflang, les sitemaps. Une fois validé, migre par étapes : un marché à la fois si tu veux limiter les risques, ou big bang si tu as confiance dans ton infra. Surveille Search Console comme un radar pendant au minimum 8 semaines post-migration — les fluctuations sont normales, mais une chute prolongée signale un problème de redirections ou de canonicalisation.

Quelles erreurs éviter absolument dans cette architecture ?

Erreur n°1 : mélanger sous-domaines et sous-répertoires pour différentes langues. Choisis un camp et tiens-le. Google gère, mais tu compliques inutilement ton hreflang et tu fragmentes tes signaux.

Erreur n°2 : laisser des contenus dupliqués sans hreflang correct. Si /fr/ et /en/ affichent le même texte traduit à la va-vite par DeepL, Google va cannibaliser tes rankings. Hreflang ne compense pas un contenu pauvre, il signale juste une relation entre versions de qualité équivalente. Erreur n°3 : sous-estimer la complexité opérationnelle d'une migration. Ces chantiers demandent coordination dev, SEO, produit, support client — et souvent un accompagnement spécialisé pour éviter les pièges techniques critiques.

• Privilégier sous-répertoires (example.com/fr/) pour tout site de 3-10 langues sans contrainte légale spécifique
• Implémenter hreflang en annotations HTML ou sitemap XML, avec x-default pour la version par défaut
• Créer une matrice de redirections 301 exacte avant toute migration, testée en staging
• Surveiller Search Console pendant 8 semaines post-migration pour détecter anomalies de crawl ou d'indexation
• Ne jamais mélanger sous-domaines et sous-répertoires pour différentes versions linguistiques
• Vérifier que chaque page référence toutes ses alternatives linguistiques, y compris elle-même