Architecture SEO multilingue : sous-répertoires, sous-domaines ou sites indépendants, et le choix du hreflang
1. Les différences de transmission d’autorité entre les trois architectures
L’architecture multilingue se résume à une seule question : quelle part de l’autorité patiemment accumulée sur votre domaine principal se transmet à la nouvelle version linguistique. Google ne traite pas de la même façon un domaine principal, un sous-répertoire, un sous-domaine et un domaine indépendant.
| Architecture | Exemple | Transmission d’autorité | Coût de maintenance | Phase adaptée |
|---|---|---|---|---|
| Sous-répertoire | example.com/de/ | Héritage à 100 % du domaine principal | Minimal, un seul template | La grande majorité des sites B2B |
| Sous-domaine | de.example.com | Transmission partielle, autorité à reconstruire | Moyen, reconfiguration des cookies et du CDN | Isolation technique requise |
| Site indépendant en ccTLD | example.fr | Départ de zéro | Maximal, backlinks et contenu en double | Marque locale forte |
| Multi-sites en gTLD | example-es.com | Départ de zéro, aucun signal local | Maximal | Déconseillé |
Si le sous-répertoire s’impose comme la réponse par défaut, c’est qu’il rattache toutes les versions linguistiques au même domaine : backlinks, profondeur de contenu et budget de crawl du domaine principal sont entièrement partagés. Ajouter une version allemande ne demande ni nouvelle propriété Search Console ni nouvelle campagne de backlinks : il suffit de produire du contenu sous le chemin /de/. Voir le processus de lancement multilingue Processus de mise en ligne des contenus multilingues.
2. Cadre de décision : choisir selon le stade du marché et les contraintes
Ne choisissez pas une architecture au feeling : répondez à trois questions. L’ordre de décision est le suivant : le domaine principal est-il mature, avez-vous un besoin d’isolation technique, votre marque locale est-elle assez forte.
| Question à trancher | Oui | Non |
|---|---|---|
| Le domaine principal est-il exploité depuis 2 ans avec du trafic organique ? | Choisir le sous-répertoire | Développez d’abord le domaine principal, ne vous précipitez pas sur le multilingue |
| Un marché exige un paiement, une conformité ou une stack technique distincts ? | Utiliser un sous-domaine pour ce marché | Rester sur le sous-répertoire |
| Notoriété de marque locale forte et budget annuel ≥ 200 000 ? | Un site indépendant en ccTLD est envisageable | Continuer avec le sous-répertoire |
| Même langue dans plusieurs pays (anglais US/UK/AU) ? | Un simple balisage hreflang suffit | Pas besoin de site indépendant |
Un cas concret : vous êtes une entreprise d’équipement industriel qui exporte, votre site principal en anglais tourne depuis 3 ans avec 8 000 visites organiques par mois, et vous voulez ajouter des versions allemande et espagnole. La bonne approche : example.com/de/ et example.com/es/. En 6 mois, vous voyez vos mots-clés allemands entrer dans le top 50. Si vous achetez d’emblée example.de et example.es, il vous faudra 12 à 18 mois rien que pour construire l’autorité.
Autre cas : un marché du Moyen-Orient a besoin d’un canal de paiement indépendant et d’un déploiement conforme aux règles locales, et le template du domaine principal ne peut pas être modifié. Là, un sous-domaine me.example.com est un compromis raisonnable. Mais acceptez que la transmission d’autorité, comme dans la zone germanophone, perde 30 % sur un sous-domaine.
Le comparatif des coûts mérite aussi un calcul. En sous-répertoire, le surcoût annuel est quasi nul : seuls la traduction et la production de contenu coûtent. En sous-domaine, il faut ajouter un certificat SSL, des règles de cache CDN et une propriété Search Console supplémentaires, soit environ 3 à 5 jours-homme en une fois. En ccTLD, outre les frais d’enregistrement du domaine, il faut créer des backlinks et une équipe de contenu locale : la première année coûte généralement 2 à 3 fois plus qu’en sous-répertoire. Si votre budget est serré en B2B, faites ce calcul avant de trancher.
III. Les différences d’écriture Hreflang selon les trois architectures
Quelle que soit l’architecture choisie, le Hreflang est obligatoire, sinon Google ne sait pas quelle version correspond à quel pays et à quelle langue. Les règles d’écriture sont identiques pour les trois architectures, seul le format d’URL change.
| Architecture | exemple hreflang | Emplacement | Point de vigilance |
|---|---|---|---|
| Sous-répertoire | href=”https://example.com/de/” | balise link dans le head ou sitemap | le moins sujet aux erreurs |
| Sous-domaine | href=”https://de.example.com/” | URL complète entre sous-domaines | le certificat SSL doit couvrir le sous-domaine |
| Site autonome | href=”https://example.de/” | URL complète entre domaines | les deux sites doivent se référencer mutuellement |
| x-default | href=”https://example.com/” | obligatoire dans chaque groupe | pointe vers la page anglaise par défaut |
Une règle stricte s’impose : chaque groupe hreflang doit être référencé dans les deux sens. La page anglaise référence la page allemande, et la page allemande doit aussi référencer la page anglaise ; si un côté manque, tout le groupe est invalidé. Le code de langue suit l’ISO 639-1 (de, fr), le code de pays l’ISO 3166-1 (de-DE, de-AT) : l’allemand d’Allemagne et celui d’Autriche diffèrent, il faut les baliser séparément. Pour l’écriture complète et les erreurs courantes, voir Hreflang et versions multilingues.
Sur un site WordPress avec WPML ou Polylang, le plugin génère automatiquement les hreflang, mais les balises générées oublient souvent le x-default ou la référence bidirectionnelle. Après la mise en ligne, vérifiez par échantillonnage avec le rapport de ciblage international de Search Console. Pour le choix de la stack technique, voir Stack technique crater.
Un dilemme fréquent : l’anglais a déjà une version américaine, faut-il créer un /en-gb/ pour le Royaume-Uni ? Si la page britannique se contente de remplacer les dollars par des livres et l’orthographe américaine par l’orthographe britannique, avec un contenu identique pour le reste, ne créez pas de page séparée : gardez /en/ et balisez avec hreflang en-GB. Une page différenciée ne se justifie que si le Royaume-Uni a sa propre tarification, sa conformité ou ses études de cas.
IV. Migration et erreurs courantes
Choisir la mauvaise architecture coûte cher à migrer. Voici les erreurs les plus fréquentes, réunies en une seule liste.
| Erreur | Conséquence | Bonne pratique |
|---|---|---|
| Acheter directement un ccTLD pour un nouveau marché | Être moins bien classé qu’un sous-répertoire pendant les 12 premiers mois | Valider d’abord le marché avec un sous-répertoire, puis décider |
| hreflang renseigné d’un seul côté | Tout le groupe de balises devient inopérant | Référencement croisé dans chaque groupe, plus x-default |
| Sous-domaine sans SSL | Échec de l’exploration hreflang | Certificat couvrant tous les sous-domaines |
| Créer des pages doorway par pays | Déclencher une action manuelle | Chaque page a un contenu local réel, voir Créer des pages d’atterrissage par pays |
| Partager une même page entre pays de même langue sans la baliser | Google choisit la mauvaise version à afficher | Distinguer avec en-GB/en-AU |
Migrer d’un sous-répertoire vers un site indépendant est l’opération qui fait perdre le plus de poids. Elle exige une carte de redirections 301 et une reconstruction des liens externes. Après la migration, des fluctuations de classement pendant 4 à 8 semaines sont normales. Voir la méthodologie de migration Refonte du site et changement de domaine. La qualité de la traduction elle-même influence le classement : après une traduction automatique, il faut impérativement passer par contrôle de révision après traduction, sinon le taux de rebond des utilisateurs locaux explose et Google juge aussi la qualité du contenu faible.
Pour finir, un moyen mnémotechnique pour choisir : si l’équipe ne compte qu’une ou deux personnes, choisissez le sous-répertoire les yeux fermés ; si l’équipe technique demande explicitement un déploiement indépendant pour un marché, passez au sous-domaine ; ne envisagez le site indépendant que si des distributeurs ou clients locaux vous cherchent déjà via un ccTLD et que vous êtes prêt à entretenir une équipe de contenu dédiée à ce marché. Une fois l’architecture fixée, ne touchez plus aux URL pendant trois ans : changer souvent fait plus de mal que de se tromper.
Ce raisonnement ne dépend pas de la taille de l’entreprise. Les petites équipes ont encore plus intérêt à concentrer le poids sur un domaine principal plutôt qu’à le disperser sur plusieurs nouveaux domaines.
FAQ — Questions fréquentes
Sous-répertoire, sous-domaine ou site indépendant : lequel choisir ?
Un domaine .de bénéficie-t-il naturellement d’un bonus de classement dans la zone germanophone ?
Une même langue dans plusieurs pays, par exemple l’anglais aux États-Unis, au Royaume-Uni et en Australie : faut-il ouvrir des sites indépendants ?
Pourquoi une architecture en sous-domaines fait-elle perdre de l’autorité ?
WPML sur WordPress écrit automatiquement les balises hreflang : faut-il quand même vérifier manuellement ?
J’ai déjà fait du multilingue avec des sous-répertoires : puis-je passer plus tard à des sites indépendants ?
Pour conclure
Le choix d’une architecture multilingue est avant tout un arbitrage entre efficacité d’autorité et besoins de localisation. Pour chaque option autre que les sous-répertoires, vous devez pouvoir avancer une raison impérieuse de l’utiliser, sinon vous ne faites qu’alourdir vos coûts de maintenance. Pour la grande majorité des sites B2B à l’international, des sous-répertoires avec des hreflang corrects suffisent.
Trois étapes pour passer à l’action : cette semaine, vérifiez dans Search Console si votre domaine principal est assez mature pour se développer en multilingue ; la semaine prochaine, choisissez une architecture pour chaque nouveau marché selon l’arbre de décision, en privilégiant les sous-répertoires ; dans les deux semaines suivant la mise en ligne, vérifiez la réciprocité des hreflang dans le rapport de ciblage international. Pour la localisation des graphiques et des chiffres dans les versions allemande et espagnole, voir le traitement des graphiques sur un site multilingue.
Une phrase à retenir : en matière d’architecture multilingue, commencez par bien utiliser les sous-répertoires. Le ccTLD est fait pour ceux qui ont déjà gagné leur marché local, pas pour faire gagner du temps à ceux qui se lancent à l’international.