SEO international : sous-répertoire, sous-domaine ou ccTLD ?

Pour la plupart des entreprises, le sous-répertoire (example.com/fr/, example.com/de/) est le meilleur point de départ : un seul domaine, une seule autorité à construire, une maintenance centralisée. Le ccTLD (example.fr, example.de) se justifie lorsque chaque pays doit être une entité séparée (juridiquement, commercialement ou par la marque) et que les moyens existent pour faire vivre plusieurs sites. Le sous-domaine (fr.example.com) répond surtout à des contraintes d’infrastructure ou d’organisation. Une architecture hybride reste exceptionnelle.

Cet article intervient avant la mise en œuvre. Pour corriger des annotations existantes, voir notre guide des erreurs hreflang.

Cibler des pays ou des langues : la première distinction

Un site « multilingue » propose plusieurs langues ; un site « multirégional » cible plusieurs pays. Les deux se combinent souvent, mais n’appellent pas la même structure.

La règle : ne créez une version par pays que si le contenu change réellement (prix, devise, disponibilité, mentions légales, interlocuteurs). Dupliquer une page à l’identique pour chaque pays crée du contenu dupliqué à gérer par canonical et hreflang, sans bénéfice pour l’utilisateur.

Sous-répertoire, sous-domaine ou ccTLD : le comparatif détaillé

Google Search Central décrit chaque option avec ses avantages et inconvénients. Le tableau ci-dessous les reprend et les complète avec les critères opérationnels que nous rencontrons en projet.

Autorité et liens

Avec des sous-répertoires, chaque lien obtenu par une version profite au même hôte et au maillage commun. Avec des ccTLD, chaque site doit gagner sa propre notoriété locale ; c’est un coût, mais aussi une force lorsque la marque est forte localement et que les liens viennent naturellement de sites du pays. Google ne documente pas de règle de transmission d’autorité entre sous-domaines : considérez-les comme des sections à faire vivre chacune.

Administration, coûts et maintenance

• Sous-répertoire : un CMS, un certificat, une configuration serveur, un sitemap par langue ou un index commun. Les évolutions techniques profitent à toutes les versions en même temps.
• Sous-domaine : configuration DNS et certificat par sous-domaine (ou certificat générique), déploiements éventuellement séparés.
• ccTLD : achat et renouvellement des domaines, conditions d’éligibilité de certains registres (présence locale exigée pour certains ccTLD), certificats, et souvent plusieurs instances de CMS à maintenir au même niveau de sécurité.

Marque et confiance

Un ccTLD peut rassurer un acheteur local, en particulier lorsque la marque opère avec une entité, un service client et des conditions propres au pays. Ce bénéfice ne vaut que si l’expérience suit : un example.de qui affiche des prix en euros mais des délais français et un service client injoignable en allemand dégrade la confiance au lieu de la renforcer.

Attention aux extensions trompeuses : Google traite certains ccTLD comme des domaines génériques (par exemple .io ou .co), et des domaines régionaux comme .eu ne ciblent pas un pays précis.

Comment Google comprend le pays et la langue ciblés

Selon la documentation Google, les signaux utilisés pour déterminer le public ciblé sont :

• le ccTLD du domaine ;
• les annotations hreflang (balises, en-têtes HTTP ou sitemap) ;
• l’emplacement du serveur, signal affaibli lorsque le site passe par un CDN ;
• d’autres indices : adresses et numéros de téléphone locaux, langue et devise, liens provenant de sites locaux, fiche d’établissement.

Google ignore les balises meta de géolocalisation (geo.position, distribution) et détermine la langue à partir du contenu visible, pas de l’attribut lang ni de l’URL. L’ancien rapport de ciblage international de Search Console a été retiré : on ne peut plus déclarer un pays cible pour un sous-répertoire.

Quelle architecture pour mon SEO international ?

Renseignez vos marchés, vos domaines, votre organisation et vos contraintes. L’outil recommande sous-répertoire, sous-domaine, ccTLD ou, exceptionnellement, une architecture hybride, et affiche les avantages, les contraintes et les prochaines étapes. Le raisonnement est visible : vous pouvez le présenter tel quel à une direction ou à une équipe technique.

Analytics, Search Console et maillage : piloter chaque marché

Search Console

Une propriété de domaine couvre automatiquement le domaine et ses sous-domaines. Pour isoler un marché, ajoutez une propriété préfixe d’URL par sous-répertoire (https://www.example.com/fr/) ou par sous-domaine : chaque version dispose alors de ses rapports et de ses utilisateurs. Avec des ccTLD, chaque domaine est une propriété distincte. Pour consolider ces sources, notre guide de l’API Search Console montre comment automatiser un reporting multi-propriétés.

Analytics

Sous-répertoires et sous-domaines d’un même domaine se mesurent dans une seule propriété GA4, avec une dimension de langue ou de répertoire pour segmenter. Avec des ccTLD, le parcours d’un visiteur qui passe d’example.fr à example.be traverse deux domaines : la mesure inter-domaines de GA4 doit être configurée pour ne pas couper les sessions.

Maillage entre versions

• Un sélecteur présent sur chaque page, qui pointe vers la page équivalente dans l’autre version, pas vers l’accueil.
• Un maillage interne propre à chaque version, dans sa langue, pour que chaque marché ait ses pages piliers.
• Des sitemaps par version, qui facilitent le suivi de l’indexation par marché.

Le hreflang : indispensable, mais après le choix d’architecture

Quelle que soit la structure, les versions d’une même page doivent être reliées par des annotations hreflang réciproques, avec une auto-référence et, si besoin, une version x-default. Pour deux versions dans la même langue (example.de et example.com/de/, par exemple), Google recommande de choisir une version préférée et d’utiliser canonical et hreflang pour que la bonne URL soit proposée.

<link rel="alternate" hreflang="fr-fr" href="https://www.example.com/fr-fr/tarifs/">
<link rel="alternate" hreflang="fr-be" href="https://www.example.com/fr-be/tarifs/">
<link rel="alternate" hreflang="de-de" href="https://www.example.com/de-de/preise/">
<link rel="alternate" hreflang="x-default" href="https://www.example.com/">

Les erreurs de mise en œuvre (codes invalides, liens non réciproques, canonicals contradictoires) sont détaillées dans notre guide des erreurs hreflang, qui intègre un validateur. Évitez aussi de confier la langue à un paramètre : notre article sur les URL avec paramètres explique pourquoi ces variantes compliquent l’indexation.

Organisation des équipes, contenu et migration

Organisation des équipes

Une équipe centrale qui produit et traduit tout s’accommode parfaitement de sous-répertoires. Des filiales autonomes, avec leurs propres agences, catalogues et calendriers, vivent mieux avec des sous-domaines ou des ccTLD, à condition d’imposer un socle technique commun (gabarits, hreflang, suivi). Le pire scénario combine des sites séparés et l’absence de gouvernance : chaque version diverge, les liens entre versions cassent, les hreflang deviennent faux.

Contenu

Une version locale n’est pas une traduction automatique. Prix, devises, unités, mentions légales, exemples, preuves et coordonnées doivent être adaptés. L’IA peut accélérer la production multilingue, comme nous le décrivons dans notre article sur la création de contenu multilingue avec l’IA, mais une relecture native reste nécessaire pour la terminologie et le ton.

Migration d’une architecture à une autre

Passer de ccTLD à des sous-répertoires (ou l’inverse) est un déplacement de site avec changement d’URL : table de correspondance exhaustive, redirections 301 page à page, mise à jour des hreflang et des canonicals, suivi par propriété. Une baisse temporaire est possible pendant le retraitement. Les risques sont ceux décrits dans nos guides sur la baisse de trafic après un changement de domaine, les redirections 301 oubliées et les erreurs de canonical après migration. D’où l’intérêt de choisir la bonne architecture dès le départ, idéalement au moment d’une refonte.

Les erreurs fréquentes des sites internationaux

• Acheter des ccTLD par réflexe puis les rediriger tous vers le .com, ou y publier des sites vides.
• Mélanger les logiques : /fr/ pour une langue et /be/ pour un pays sur le même site, sans règle documentée.
• Rediriger automatiquement selon l’adresse IP ou la langue du navigateur.
• Mélanger deux langues sur une page (menus en anglais, contenu en français) : Google se fonde sur le contenu visible.
• Traduire les URL d’une version mais pas ses liens internes, qui continuent de pointer vers la version d’origine.
• Canonicaliser toutes les versions vers la version principale, ce qui retire les autres de l’index au lieu de les relier.
• Oublier la mesure par marché, ce qui interdit de savoir quelle version progresse.

Conclusion : la structure la plus simple qui respecte vos contraintes

Le sous-répertoire couvre la majorité des besoins avec le moins de coûts et de dispersion. Le ccTLD s’impose lorsque chaque pays doit exister comme une entité distincte et que l’organisation peut faire vivre plusieurs sites. Le sous-domaine répond à une contrainte d’infrastructure ou d’équipe. Dans tous les cas, le hreflang, la qualité des versions locales et la mesure par marché décideront du résultat.

Nous accompagnons ces choix lors d’une refonte de site, d’un audit SEO technique ou d’un projet multilingue comme ceux que nous menons pour des entreprises en Suisse, pays où plusieurs langues cohabitent. Pour une stratégie de visibilité par marché, voir notre accompagnement en référencement naturel ; et si une migration est déjà en cours, notre guide pour réussir une migration SEO sans perte de trafic complète celui-ci.