# General Translation Knowledge Base: Sous-répertoire, sous-domaine ou ccTLD pour le SEO multilingue URL: https://generaltranslation.com/fr/kb/multilingual-url-structure.mdx Docs index: https://generaltranslation.com/llms.txt Description: Utilisez des sous-répertoires comme example.com/de/ lorsqu’un même produit partage un site et un processus de livraison. Seul un ccTLD signale un pays, les sous-domaines permettent un hébergement distinct, Google déconseille les paramètres ?lang= et considère les domaines « de complaisance » comme .io et .ai comme génériques. Category: Référencement multilingue Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Chacune de ces structures attribue une URL propre à chaque langue, et le [guide de Google sur les sites multirégionaux et multilingues](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) les compare du point de vue du ciblage et de la maintenance, sans en privilégier aucune. Le choix se résume donc à deux questions : ciblez-vous des langues ou des pays, et combien de sites souhaitez-vous gérer ? ## Comparaison des quatre structures d'URL Les avantages et inconvénients ci-dessous reprennent le tableau de Google. La dernière option, un paramètre d'URL, est celle que Google déconseille. | Structure | Exemple | Avantages selon Google | Inconvénients selon Google | | ------------------------------------------ | --------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Domaine de premier niveau national (ccTLD) | `example.de` | Ciblage géographique clair ; emplacement du serveur sans importance ; sites faciles à séparer | Coûteux et parfois indisponible ; infrastructure plus lourde ; exigences strictes pour les ccTLD dans certains pays ; ne cible qu'un seul pays | | Sous-domaine | `de.example.com` | Facile à configurer ; possibilité d'utiliser des serveurs situés à différents endroits ; sites faciles à séparer | L'URL ne permet pas aux utilisateurs de savoir si `de` désigne une langue ou un pays | | Sous-répertoire | `example.com/de/` | Facile à configurer ; maintenance réduite (même hôte) | Les utilisateurs risquent de ne pas identifier le ciblage à partir de l'URL ; un seul emplacement de serveur ; sites plus difficiles à séparer | | Paramètre d'URL | `example.com?lang=de` | Aucun (déconseillé) | Segmentation par URL difficile ; les utilisateurs risquent de ne pas identifier le ciblage | Deux précisions issues des recommandations de Google relativisent ces différences : * **Parmi les formats d'URL, seul un ccTLD indique un pays.** Les [recommandations de Google sur les versions localisées](https://developers.google.com/search/docs/specialty/international/localized-versions) précisent que les sous-domaines de langue tels que `en` ou `de` ne servent pas à déterminer l'audience d'une page ; vous devez l'indiquer explicitement avec [hreflang](/kb/what-is-hreflang). Google ne mentionne pas spécifiquement les dossiers, mais rien ne laisse penser qu'un chemin `/de/` soit traité différemment : indiquez-les donc eux aussi avec hreflang. * **Certains ccTLD sont considérés comme génériques.** Google traite `.io`, `.ai`, `.co`, `.me`, `.tv` et d'autres ccTLD dits « de complaisance », ainsi que les domaines régionaux comme `.eu`, comme des domaines de premier niveau génériques. Une startup hébergée sur `example.io` ne cible pas pour autant le Territoire britannique de l'océan Indien. Google précise également que l'emplacement du serveur n'est « pas un signal déterminant », puisque les sites utilisent des CDN, ce qui relativise l'inconvénient « un seul emplacement de serveur » des sous-répertoires. Une cinquième option consiste à conserver une seule URL et à changer la langue en fonction d'un cookie ou d'un en-tête du navigateur. Google la déconseille, car son robot d'exploration risque de ne pas trouver toutes les versions ; les compromis sont détaillés dans [comment un site doit choisir la langue qu'il sert](/kb/locale-routing-seo). ## Ce que coûte l'exploitation de chaque structure Le tableau de Google s'en tient à « plus d'infrastructure ». En pratique, les structures se distinguent par le nombre d'éléments distincts à maintenir : * **Domaines nationaux :** un domaine à acheter et à renouveler par pays, avec des règles d'enregistrement locales dans certains pays. Chaque hôte doit être couvert par TLS ; un même certificat peut couvrir plusieurs noms. Prévoyez la propriété, les redirections et la surveillance de l'ensemble de ces domaines. * **Sous-domaines :** un seul domaine, mais un enregistrement DNS et une couverture de certificat par sous-domaine. Les [recommandations de Google sur la canonicalisation](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) précisent que le certificat doit correspondre à l'hôte complet ou être un certificat générique (wildcard), faute de quoi Google risque de privilégier la version HTTP. * **Sous-répertoires :** les langues peuvent partager un même hôte, une même configuration TLS, une même application et un même pipeline de déploiement. Il s'agit de choix d'exploitation courants, pas d'obligations : des proxys inverses peuvent acheminer les chemins vers des applications distinctes, et les outils d'analyse peuvent être organisés indépendamment de la structure des URL. Ne partez pas du principe que les sous-répertoires bénéficient d'un bonus de classement, ni que chaque nouveau sous-domaine démarre sans aucun signal utile. La comparaison de Google n'établit ni l'un ni l'autre. Comparez plutôt le travail d'hébergement, de gestion et de livraison qu'exige concrètement votre déploiement. ## Faut-il cibler des langues ou des pays ? Google distingue un site **multilingue** (la même offre en plusieurs langues, comme une entreprise canadienne présente en anglais et en français) d'un site **multirégional** (des offres différentes selon le pays, comme un fabricant qui livre au Canada et aux États-Unis). La structure de vos URL doit refléter votre situation : * **Ciblez une langue** lorsque le contenu est identique pour tous les locuteurs. Une seule section `/es/` annotée `es` s'adresse aux hispanophones du Mexique, d'Espagne et d'Argentine. * **Ciblez un pays** lorsque certains éléments varient d'un pays à l'autre : prix et devise, livraison, mentions juridiques ou catalogue de produits. Utilisez `/es-mx/` et `/es-es/`, ou `example.mx`, et annotez-les `es-MX` et `es-ES`. Le ciblage par pays a un prix. Selon Google, le ciblage géographique peut améliorer le classement dans le pays cible « au détriment des résultats dans d'autres paramètres régionaux ou langues », et un ccTLD ne peut cibler qu'un seul pays. Si vous optez pour une segmentation par pays, Google [recommande](https://developers.google.com/search/docs/specialty/international/localized-versions) de proposer en plus une page ciblant uniquement la langue (`es`) pour les locuteurs du reste du monde. Pour choisir entre des codes comme `es` et `es-MX`, consultez [quels codes de paramètres régionaux utiliser](/docs/platform/core/guides/locale-codes). ## Slugs localisés Le préfixe du paramètre régional rend la version visible dans l'URL ; le reste du chemin peut lui aussi être traduit, par exemple `/de/ueber-uns` au lieu de `/de/about-us`. Selon Google, les mots localisés dans les URL ne posent aucun problème, pas plus que les noms de domaine internationalisés, à condition que les URL soient encodées en UTF-8 et correctement échappées dans les liens. Un slug non ASCII comme `/de/über-uns` est transmis sous la forme `/de/%C3%BCber-uns` : c'est donc cette forme encodée qui doit figurer dans les balises hreflang et les plans de site. Les slugs traduits sont plus lisibles dans les résultats de recherche, mais ils impliquent de maintenir une table de correspondance des slugs pour chaque paramètre régional, et tout slug dont la traduction change nécessite une redirection depuis l'ancienne URL. Les équipes qui se passent de slugs localisés conservent `/de/about-us` et disposent malgré tout d'une URL distincte et indexable pour chaque langue. ## Quelle structure choisir ? Optez pour des **sous-répertoires** comme point de départ lorsqu'un même produit dessert plusieurs langues à partir d'un site et d'un processus de livraison communs. Ils permettent souvent de réutiliser la configuration de routage et d'hébergement. Rien n'empêche pour autant des déploiements distincts, et un CDN peut servir le même hôte depuis plusieurs emplacements. Optez pour des **domaines nationaux** lorsque chaque pays fonctionne en pratique comme une activité à part entière (entités juridiques, catalogues ou équipes marketing distincts), que vous recherchez le signal géographique le plus fort et que vous pouvez assumer le coût de maintenance. Optez pour des **sous-domaines** lorsqu'un paramètre régional nécessite un hébergement ou une infrastructure spécifique, par exemple lorsqu'un marché doit être servi depuis des serveurs situés dans le pays concerné. Évitez les **paramètres d'URL** comme structure linguistique par défaut, car Google ne les recommande pas. Ils ne sont pas pour autant impossibles à indexer : le comportement des rapports et de la mise en cache dépend de la manière dont vos systèmes traitent ces paramètres. Quelle que soit l'option retenue, utilisez des URL stables et annotez les versions publiées équivalentes avec hreflang. (Voir [Qu'est-ce que hreflang](/kb/what-is-hreflang).) ## Comment General Translation prend en charge chaque structure Le package `gt-next` de General Translation prend en charge les sous-répertoires. Dans l'App Router, [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) place chaque paramètre régional sous un préfixe de chemin, par exemple `/es/about` ; la question de savoir si les paramètres régionaux par défaut en reçoivent également un est traitée dans [routage selon les paramètres régionaux et SEO](/kb/locale-routing-seo). L'option `pathConfig` de ce même middleware associe un chemin commun à un slug localisé pour chaque paramètre régional, par exemple `/de/ueber-uns` pour `/about`, et `customMapping` dans `gt.config.json` permet à une route d'utiliser un alias comme `/cn` tandis que les traductions utilisent le code canonique `zh` (consultez le [guide SEO des alias de paramètres régionaux](/docs/react/nextjs/locale-alias-seo)). La documentation de `gt-next` traite du routage basé sur le chemin, et non du routage par nom d'hôte. Pour les sous-domaines ou les domaines nationaux, associez chaque hôte à un paramètre régional dans votre propre code et transmettez-le à la bibliothèque, par exemple au moyen d'une fonction de paramètre régional personnalisée définie via [`getLocalePath`](/docs/react/nextjs/config#request-function-paths), ou avec [`withGT`](/docs/node/reference/functions/with-gt) dans `gt-node`. Pour les balises canoniques, hreflang et le plan de site, consultez [Comment configurer le SEO d'une application Next.js multilingue ?](/kb/multilingual-nextjs-seo). ## Points clés * Google compare les ccTLD, les sous-domaines et les sous-répertoires du point de vue du ciblage et de la maintenance, et non du classement ; il déconseille par ailleurs les paramètres d'URL de langue. * Un ccTLD transmet un signal de pays ; les sous-domaines et chemins qui ressemblent à des codes de langue ne transmettent pas ce signal à eux seuls. Utilisez hreflang pour cibler explicitement une langue ou une région. Google considère `.io`, `.ai` et `.co` comme des domaines génériques. * Commencez par des sous-répertoires (`example.com/de/`) si vos paramètres régionaux partagent un même site et un même processus de livraison ; la structure d'URL n'impose ni un déploiement unique ni une propriété d'analyse unique. * Ne segmentez par pays (`es-MX`) que si les prix, la livraison, les conditions juridiques ou les catalogues diffèrent ; sinon, ciblez la langue (`es`). * `gt-next` prend en charge le routage par préfixe de chemin, les préfixes facultatifs pour le paramètre régional par défaut et les slugs localisés via `pathConfig`. ## Related questions - [Qu’est-ce que hreflang et comment le configurer ?](https://generaltranslation.com/fr/kb/what-is-hreflang.mdx): Hreflang indique à Google quelles URL correspondent aux versions linguistiques ou régionales d’une même page, afin qu’il affiche la bonne dans les résultats de recherche. Ajoutez-le à l’aide de balises link HTML, d’en-têtes HTTP Link ou d’un plan de site, veillez à ce que chaque lien soit réciproque et utilisez des codes valides comme en-GB, et non en-UK. - [Redirections linguistiques et SEO : URL, cookie ou Accept-Language ?](https://generaltranslation.com/fr/kb/locale-routing-seo.mdx): Laissez l’URL déterminer la langue de chaque page que vous souhaitez faire indexer, car Googlebot n’envoie aucun en-tête Accept-Language et explore principalement depuis des adresses américaines. Ne vous servez du choix enregistré dans un cookie, puis d’Accept-Language, que pour décider vers où redirige une racine neutre comme /, avec une redirection temporaire 302 ou 307. - [Comment configurer le SEO d’une application Next.js multilingue ?](https://generaltranslation.com/fr/kb/multilingual-nextjs-seo.mdx): Attribuez à chaque langue sa propre URL préfixée, comme /en/about et /es/about, puis publiez html lang, une URL canonique autoréférente, des variantes localisées hreflang avec x-default, un titre et une description traduits, ainsi qu’une entrée de plan de site pour chaque langue publiée. Marquez les versions non publiées en noindex. Le package gt-next de General Translation associe chaque langue à sa propre URL et traduit les titres avec getGT. - [Comment rendre un site web multilingue ?](https://generaltranslation.com/fr/kb/make-website-multilingual.mdx): Choisissez où stocker les traductions (dans un proxy, un plugin de CMS, un constructeur de sites ou votre propre code), puis attribuez à chaque langue sa propre URL, comme le recommande Google. Traduisez les pages entières ainsi que les titres et les méta-descriptions, reliez les versions avec hreflang et proposez un sélecteur de langue plutôt que de rediriger automatiquement les visiteurs. ## Previous and next questions - Previous question: [Redirections linguistiques et SEO : URL, cookie ou Accept-Language ?](https://generaltranslation.com/fr/kb/locale-routing-seo.mdx) - Next question: [Comment ajouter l’i18n à une application Next.js App Router ?](https://generaltranslation.com/fr/kb/add-i18n-to-nextjs.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.