Site multilingue : sous-dossier, sous-domaine ou domaine par pays ?
Quelle structure choisir pour un site en plusieurs langues, ce que chaque option coûte par an et les erreurs hreflang à vérifier avant la mise en ligne.
En bref. Pour un site français qui ajoute une ou deux langues, le sous-dossier (votresite.fr/en/) est le bon choix dans la grande majorité des cas : il conserve l’autorité déjà acquise par le domaine, se gère avec un seul hébergement et coûte le moins cher à maintenir. Le domaine par pays (votresite.de) ne devient pertinent qu’avec une équipe et un budget dédiés à ce marché — comptez 3 000 à 8 000 € la première année, par pays.
Les trois structures possibles, et ce qu’elles impliquent
Il n’existe que trois façons d’organiser un site en plusieurs langues. Le choix se fait une fois, et le changer plus tard coûte cher : une migration mal faite fait perdre 20 à 40 % du trafic pendant plusieurs mois.
| Structure | Exemple | Coût annuel supplémentaire | Autorité |
|---|---|---|---|
| Sous-dossier | votresite.fr/en/ | 0 à 200 € | Partagée avec le domaine principal |
| Sous-domaine | en.votresite.fr | 0 à 300 € | Partiellement séparée |
| Domaine par pays | votresite.de | 3 000 à 8 000 € | Entièrement à reconstruire |
Le tableau se lit surtout dans la dernière colonne. Un domaine que vous travaillez depuis trois ans a accumulé des liens, un historique et une forme de crédit auprès des moteurs. Un sous-dossier en hérite immédiatement. Un domaine neuf repart de zéro : les premiers mois, il se positionnera moins bien que votre page française sur les mêmes requêtes traduites.
Pourquoi le sous-dossier gagne presque toujours
Trois raisons concrètes, dans l’ordre d’importance.
L’autorité ne se duplique pas. Si votre site français reçoit 400 liens entrants, un sous-dossier anglais démarre avec ce capital derrière lui. Un domaine séparé démarre à zéro et vous devrez refaire le travail de netlinking sur le nouveau marché — c’est le poste qui explique l’essentiel des 3 000 à 8 000 € annoncés plus haut.
La maintenance est mutualisée. Un seul hébergement, un seul certificat, une seule sauvegarde, une seule mise à jour de CMS. Avec trois domaines séparés, chaque intervention technique est multipliée par trois, et chaque oubli devient une faille. Pour une structure sans équipe technique dédiée, c’est le facteur décisif.
Le suivi est unifié. Une seule propriété Google Search Console, un seul flux analytique, un seul plan de taggage. Les comparaisons entre versions linguistiques deviennent lisibles au lieu d’exiger un assemblage manuel.
Le seul vrai inconvénient du sous-dossier est la contrainte technique : votre CMS doit savoir servir des URL par langue proprement. Sur WordPress, Webflow, Shopify ou un site sur mesure, c’est le cas. Si votre outil impose un sous-domaine, ce n’est pas dramatique — voir plus bas.
Les deux cas où le domaine par pays reste justifié
Le premier cas est réglementaire ou commercial : vous vendez avec des conditions différentes par pays, une entité juridique locale, une TVA et un service client sur place. Un .de avec une adresse allemande et un numéro allemand rassure un acheteur allemand d’une manière qu’un sous-dossier ne reproduit pas. Sur des paniers élevés ou en B2B, cet effet de confiance pèse davantage que le SEO.
Le second cas est organisationnel : une équipe locale dispose de son propre budget, publie son propre contenu et travaille ses propres partenariats. Un domaine séparé lui donne l’autonomie technique sans risquer de casser le site du siège.
En dehors de ces deux situations, ouvrir un domaine par pays revient à s’imposer un travail de référencement supplémentaire sans contrepartie. La question à se poser est simple : disposez-vous d’un budget de contenu et de liens dédié à ce marché, chaque mois, sur au moins douze mois ? Si la réponse est non, restez en sous-dossier.
Le sous-domaine : un compromis rarement nécessaire
Le sous-domaine occupe une position intermédiaire inconfortable. Il ne donne pas la crédibilité locale d’un .de et ne transmet pas aussi franchement l’autorité qu’un sous-dossier. Il se défend dans deux situations précises : quand la version étrangère tourne sur une infrastructure différente du site principal, et quand vous utilisez une plateforme qui ne gère les langues que de cette façon.
Si vous êtes déjà en sous-domaine et que tout fonctionne, ne migrez pas pour le principe. Le gain théorique d’un passage en sous-dossier est réel mais modeste, et il ne compense pas le risque d’une migration mal exécutée. La règle vaut pour toute refonte de structure : on ne déplace des URL que si le problème actuel est mesuré, pas supposé. C’est aussi ce qui distingue un chantier de refonte de site bien cadré d’une réorganisation faite à l’intuition.
Hreflang : quatre erreurs qui annulent tout le travail
La balise hreflang indique aux moteurs quelle version servir à quel visiteur. Mal posée, elle produit l’inverse de l’effet recherché : la version anglaise s’affiche pour des internautes français, ou aucune version ne se positionne correctement.
Une déclaration hreflang doit être réciproque. Si la page française pointe vers la page anglaise, la page anglaise doit pointer vers la page française. Un lien à sens unique est ignoré, et c’est de loin l’erreur la plus fréquente sur les sites multilingues.
Les quatre erreurs à vérifier avant tout le reste :
- Les codes de langue inventés. Le code du Royaume-Uni est en-GB, pas en-UK. Celui du Japon est ja, pas jp. Un code invalide fait ignorer la déclaration entière.
- L’absence d’autoréférence. Chaque page doit se déclarer elle-même dans sa propre liste hreflang. Sans cela, la grappe est considérée comme incomplète.
- Le pointage vers des URL redirigées. Une balise qui vise une adresse renvoyant un code 301 ou 404 casse la relation. À vérifier après chaque changement d’arborescence.
- L’oubli de la balise x-default. Elle indique la page à servir quand aucune version ne correspond à la langue du visiteur. Sans elle, le comportement devient imprévisible sur les marchés que vous ne couvrez pas.
Sur un site de moins de cent pages, un contrôle complet prend une heure avec un outil de crawl. Faites-le à la mise en ligne, puis une fois par trimestre.
Traduire ou réécrire : ce que ça change côté budget
Une traduction littérale de votre site français ne se positionnera pas, pour une raison mécanique : les gens ne cherchent pas la même chose dans les deux langues. « Devis travaux » et sa traduction anglaise correspondent à des volumes, des intentions et des concurrents différents. Traduire les mots sans revoir les requêtes ciblées produit des pages correctes en langue et invisibles en recherche.
| Approche | Coût indicatif | Résultat SEO attendu |
|---|---|---|
| Traduction automatique brute | Quasi nul | Très faible, risque de contenu de mauvaise qualité |
| Traduction IA + relecture humaine | 0,03 à 0,06 € / mot | Correct sur les pages de service, insuffisant sur le blog |
| Traduction professionnelle | 0,10 à 0,18 € / mot | Bon, mais sans recherche de mots-clés locale |
| Adaptation avec recherche de requêtes | 150 à 400 € / page | Le seul qui vise réellement des positions |
La stratégie la plus économe consiste à mélanger : traduction relue pour les pages obligatoires (mentions légales, conditions, à propos), et adaptation complète pour les cinq à dix pages qui doivent générer du trafic. Traduire l’intégralité d’un blog de deux cents articles est presque toujours un mauvais investissement au démarrage.
La liste de contrôle avant mise en ligne
Une version linguistique se lance mal quand on traite le référencement après coup. Les sept points ci-dessous se règlent avant la publication, en une demi-journée pour un site de taille moyenne :
- Chaque page traduite possède une URL propre et lisible, avec les segments traduits eux aussi (/en/services/ plutôt que /en/services-fr/).
- Les balises title et les méta-descriptions sont rédigées dans la langue cible, pas traduites mot à mot depuis le français.
- La balise lang de la page correspond à la langue réellement servie.
- Le plan de site XML liste les URL de toutes les langues, avec les correspondances hreflang.
- Le sélecteur de langue est un lien HTML classique, explorable, et non un menu géré uniquement en JavaScript.
- Les formulaires, messages d’erreur et pages 404 sont traduits — c’est le premier oubli en volume.
- Les coordonnées, devises et mentions de délai sont adaptées au marché visé, pas recopiées.
Le point 5 mérite une vérification manuelle : de nombreux thèmes gèrent le changement de langue par script, ce qui rend les autres versions invisibles pour les robots. Le test est simple : désactivez JavaScript dans le navigateur et regardez si les liens vers les autres langues sont toujours présents et cliquables.
Le point 7 fait souvent la différence sur la conversion plutôt que sur les positions. Un visiteur allemand qui voit un délai de livraison exprimé « sous 48 h en France métropolitaine » comprend immédiatement que la page ne lui est pas destinée, même si le texte est parfaitement traduit.
Combien de temps avant les premiers résultats
En sous-dossier, sur un domaine déjà établi, les premières pages traduites commencent à apparaître dans les résultats au bout de trois à six semaines, avec des positions instables pendant deux mois. Un trafic significatif arrive généralement entre le quatrième et le sixième mois.
Sur un domaine neuf, ajoutez six à douze mois. C’est l’écart le plus concret entre les deux structures, et celui qu’on sous-estime le plus au moment de la décision.
Questions fréquentes
Faut-il rediriger automatiquement les visiteurs selon leur pays ?
Non. Une redirection automatique fondée sur l’adresse IP empêche les robots d’explorer les autres versions et frustre les visiteurs qui veulent lire dans une autre langue que celle de leur localisation. La bonne pratique consiste à afficher une bannière discrète proposant la version adaptée, tout en laissant la page demandée accessible.
Peut-on utiliser un paramètre d’URL comme votresite.fr/?lang=en ?
C’est techniquement possible mais déconseillé. Ces URL sont moins bien explorées, se partagent mal et compliquent le suivi analytique. Si votre CMS ne propose que cette option, cherchez d’abord une réécriture d’URL avant d’envisager autre chose.
Le contenu dupliqué entre versions linguistiques est-il pénalisé ?
Non, deux versions d’une même page dans deux langues différentes ne constituent pas du contenu dupliqué. Le problème apparaît entre variantes d’une même langue — une version française pour la France et une pour la Belgique, quasi identiques. Dans ce cas, hreflang correctement posé règle la situation, mais il vaut mieux différencier réellement les contenus, ne serait-ce que sur les prix, les délais et les coordonnées.
Combien de langues ajouter au départ ?
Une seule. Chaque langue supplémentaire multiplie la maintenance, la production de contenu et les points de défaillance technique. Lancez une version, mesurez son trafic et ses conversions pendant six mois, et n’ajoutez la deuxième que si la première a atteint son objectif. La plupart des sites multilingues abandonnés le sont pour cette raison : trois langues lancées en même temps, aucune correctement entretenue au bout d’un an.