ccTLD, sous-domaine ou sous-répertoire pour le SEO international
Comparez les trois structures d’URL destinées à plusieurs pays : ccTLD, sous-domaine et sous-répertoire. Google ne privilégie aucune structure pour le classement, mais seul le ccTLD fournit automatiquement un signal national.
Langues
Trois formes d’URL permettent de servir plusieurs pays : ccTLD tel qu’example.de, sous-domaine tel que de.example.com, ou dossier tel qu’example.com/de/. Google n’accorde aucun avantage de classement à l’une d’elles. Seul le ccTLD fournit automatiquement aux moteurs comme aux visiteurs un signal national clair. Cette précision se paie par une autorité répartie et par davantage d’infrastructure. Les dossiers regroupent les signaux sur le domaine principal et simplifient l’administration, mais ils dépendent de hreflang depuis la suppression du rapport Ciblage international de Search Console en septembre 2022. Les sous-domaines conviennent surtout à une séparation technique. Pour la plupart des sites, le dossier reste donc le choix pratique, sauf exigence juridique, besoin de confiance locale ou ccTLD déjà établi.
TL;DR — Pour proposer des versions nationales d’un site, vous pouvez utiliser un domaine national comme
example.de, un sous-domaine commede.example.comou un sous-répertoire commeexample.com/de/. Google considère les trois structures comme valables. Un ccTLD tel que.de,.frou.co.uksignale automatiquement le pays aux moteurs et aux utilisateurs. Le sous-répertoire reste le choix le plus simple à exploiter et convient par défaut à la plupart des sites.
Les trois possibilités
Imaginons une entreprise américaine qui se développe en Allemagne. Sa version allemande peut utiliser trois structures :
- ccTLD — domaine national de premier niveau :
example.de..decorrespond à l’Allemagne, comme.frà la France et.co.ukau Royaume-Uni. Chaque pays utilise un domaine distinct. - Sous-domaine — préfixe ajouté au domaine principal :
de.example.com. - Sous-répertoire — chemin du domaine principal :
example.com/de/. Toutes les versions restent sur le même domaine et sont organisées en dossiers.
Une structure se classe-t-elle mieux ?
Google ne présente aucune structure comme universellement supérieure. Sa documentation expose des avantages, des coûts et des signaux locaux différents. Le choix doit correspondre au public et au modèle d’exploitation, sans supposer un avantage garanti de classement.
Ces structures ne sont pas pour autant interchangeables. Une différence essentielle mérite d’être comprise :
Un ccTLD annonce automatiquement son pays. example.de indique immédiatement à Google une cible allemande, sans réglage supplémentaire. L’adresse inspire aussi davantage confiance à un acheteur allemand qu’un .com générique.
Un sous-domaine ou un sous-répertoire n’émet pas ce signal automatiquement. Il faut établir le public visé au moyen de hreflang, d’un contenu adapté, d’informations locales et de liens locaux.
Evidence for this claim Google calls ccTLDs a strong country signal and also lists hreflang, server location, local contact details, currency, local links, and Business Profile signals among its locale inputs. Scope: Google Search target-locale signals; no single signal guarantees a chosen result. Confidence: high · Verified: Google: How target locale is determinedQuelle structure choisir ?
Voici une règle simple :
- Choisissez un sous-répertoire (
example.com/de/) en cas de doute. C’est la solution la moins coûteuse et la plus simple : un domaine, un hébergement et une administration, avec toute l’autorité regroupée. - Choisissez un ccTLD (
example.de) si vous possédez déjà les domaines nationaux, si une adresse locale inspire une confiance décisive ou si la loi impose ce domaine. - Choisissez un sous-domaine (
de.example.com) surtout lorsqu’une contrainte technique exige un hébergement séparé sans acheter d’autres domaines.
L’erreur la plus fréquente
N’achetez pas un ccTLD par pays dans l’espoir de mieux vous classer. Chaque domaine divise l’autorité et doit obtenir ses propres liens et sa propre réputation. Ce coût est réel, sans gain automatique. Pour les détails, les déclarations de Google et les conséquences de la suppression du ciblage géographique de Search Console, ouvrez l’onglet Avancé.
Evidence for this claim Google calls ccTLDs a strong country signal and also lists hreflang, server location, local contact details, currency, local links, and Business Profile signals among its locale inputs. Scope: Google Search target-locale signals; no single signal guarantees a chosen result. Confidence: high · Verified: Google: How target locale is determinedTL;DR — Le ciblage international peut utiliser un ccTLD (
example.de), un sous-domaine de gTLD (de.example.com) ou un sous-répertoire (example.com/de/). Google documente ces trois structures sans préférence de classement. La différence centrale est le signal géographique : le ccTLD fournit automatiquement un signal national sans ambiguïté, mais fragmente l’autorité entre plusieurs domaines, multiplie l’infrastructure et complique hreflang. Les sous-répertoires regroupent l’autorité et coûtent moins cher. Depuis la suppression du rapport Ciblage international de Search Console en septembre 2022, aucun réglage ne permet toutefois d’attribuer explicitement un pays à un dossier ; il faut combiner hreflang, contenu local et autres signaux. Les sous-domaines offrent un hébergement distinct mais réclament les mêmes signaux manuels. Propriété, règles d’enregistrement, gouvernance et coût comptent autant que le signal. Toute modification ultérieure constitue une migration d’URL complète. Mon choix par défaut reste le sous-répertoire, sauf domaine national existant, exigence juridique ou séparation technique réelle. Evidence for this claim Google documents ccTLD, gTLD subdomain, and gTLD subdirectory structures as usable locale-specific URL options, with different operational tradeoffs. Scope: Google Search international URL-structure guidance; the documentation does not promise equal ranking outcomes. Confidence: high · Verified: Google: Locale-specific URL structures
Les trois structures, précisément
| Structure | Exemple | Signal national | Autorité | Coût opérationnel |
|---|---|---|---|---|
| ccTLD | example.de | Automatique pour Google et les utilisateurs | Répartie entre des domaines distincts | Le plus élevé : enregistrement, hébergement et hreflang entre propriétés |
| Sous-domaine | de.example.com | Signaux explicites et contextuels | Nom d’hôte distinct, évalué selon le site | Moyen |
| Sous-répertoire | example.com/de/ | Signaux explicites et contextuels | Regroupée sur un domaine | Le plus faible |
Un ccTLD est un domaine national de premier niveau, par exemple .de, .fr, .co.uk ou .jp. Google le considère par défaut comme un fort signal géographique : le domaine est automatiquement associé à un pays. Un gTLD, comme .com, .org ou .net, ne porte aucune signification nationale ; ses sous-domaines et dossiers doivent donc établir leur ciblage autrement.
Ce que dit réellement Google
La documentation de Google sur la gestion des sites multirégionaux et multilingues présente ces structures et leurs compromis :
- Domaine national (ccTLD) — ciblage clair et séparation facile, mais coût élevé, disponibilité parfois limitée et infrastructure supplémentaire.
- Sous-domaine d’un gTLD — configuration simple et possibilité d’hébergements différents, mais ciblage peu lisible dans l’URL pour l’utilisateur.
- Sous-répertoire d’un gTLD — configuration et maintenance simples sur un même hôte, mais ciblage également peu lisible et emplacement serveur unique.
- Paramètres d’URL (
example.com?country=de) — déconseillés pour le ciblage national, car difficiles à segmenter et à reconnaître.
Cette liste ne prétend pas qu’une structure se classe mieux. Les consignes sur la structure des URL répètent que Google n’a aucune préférence d’indexation ou de classement. Choisissez le modèle le plus facile à organiser et à gérer.
Différence essentielle : signal automatique ou manuel
C’est le cœur de la décision internationale, distinct du débat général entre sous-domaines et sous-répertoires.
Un ccTLD fournit gratuitement le signal national. Dès qu’il voit example.de, Google comprend une cible allemande. L’utilisateur perçoit aussi dans .de un indice de confiance qu’un chemin .com/de/ ne peut reproduire.
Un sous-domaine ou un sous-répertoire de gTLD n’obtient aucun signal automatique. .com ne désigne aucun pays. Comment indiquer que example.com/de/ vise les germanophones d’Allemagne ?
Pendant des années, la réponse associait hreflang au rapport Ciblage international de Search Console. Une propriété à préfixe d’URL permettait même d’attribuer un pays à un sous-répertoire comme example.com/de/.
Le changement oublié : Ciblage international a disparu
Google a supprimé le rapport Ciblage international de Search Console en septembre 2022 (avis officiel, également couvert par Search Engine Land). Il réunissait le contrôle des erreurs hreflang et le réglage de pays. Google expliquait que la valeur de ce réglage avait diminué à mesure que hreflang progressait.
Conséquence : aucun moyen ne permet désormais d’attribuer explicitement un pays à un sous-répertoire ou à un sous-domaine dans Google. Pour un gTLD, il reste :
- hreflang — annotations réciproques
language-regionindiquant la version à servir, détaillées dans hreflang et x-default. - Les signaux déduits par Google — emplacement du serveur ou du CDN, langue et devise locales, adresse et téléphone locaux, liens provenant du pays.
Aucun de ces éléments ne constitue une déclaration absolue équivalente à l’ancien réglage. hreflang suggère la version à afficher, sans affecter un dossier à un pays. Dans mon étude de 374 756 domaines utilisant hreflang, plus de 67 % présentaient au moins une erreur. Voilà le vrai coût de l’option la plus simple : tout le signal vous incombe.
Un ccTLD évite ce problème. Il n’a jamais dépendu du rapport Ciblage international ; sa suppression ne l’a donc pas affecté. Cette asymétrie est l’argument le plus fort en faveur d’un ccTLD lorsque le signal national est décisif.
Coût d’un ccTLD : la fragmentation
Pourquoi ne pas utiliser partout le signal le plus clair ? Parce qu’il entraîne des coûts réels :
- Autorité divisée. Chaque ccTLD est un domaine distinct. Les backlinks vers
example.dene renforcent pasexample.com. Chaque pays doit bâtir sa réputation presque à partir de zéro. - Infrastructure multipliée. Davantage de domaines à enregistrer, renouveler, héberger, sécuriser et configurer. Certains ccTLD exigent aussi une présence ou une adresse locale, comme
.com.auet historiquement certains domaines européens. - hreflang plus difficile. Entre une douzaine de propriétés, chacune doit référencer toutes les autres réciproquement. Chaque ccTLD ajoute un nœud aux groupes hreflang et une occasion d’erreur.
Le sous-répertoire inverse ces coûts : domaine, propriété et hébergement uniques, autorité regroupée et hreflang contenu dans un seul site. Sa simplicité opérationnelle explique pourquoi il sert de choix par défaut à la plupart des sites internationaux malgré un signal plus faible.
Sous-domaines : le compromis intermédiaire
Un sous-domaine de gTLD comme de.example.com représente une véritable option intermédiaire :
- Comme un sous-répertoire, il ne reçoit aucun signal national automatique et dépend de hreflang et des signaux déduits.
- Contrairement à un dossier, il constitue un nom d’hôte distinct, facile à placer sur un autre serveur, dans un autre pays ou sous la responsabilité d’une autre équipe. Google précise qu’ils “allow different server locations.” (traduction) « permettent différents emplacements de serveur ».
- Google décide selon l’intégration propre au site s’il appartient au site principal ou doit être traité séparément, comme dans le débat général entre sous-domaine et sous-répertoire.
Le sous-domaine offre donc une souplesse d’hébergement sans domaine supplémentaire, mais exige le même ciblage manuel qu’un dossier. Sans besoin d’hôte distinct, le sous-répertoire accomplit la même tâche avec moins de frais.
Que valent les études de corrélation ?
Certaines études montrent la domination des ccTLD dans les résultats internationaux. L’analyse de SE Ranking portant sur 20 000 mots-clés dans 15 marchés observe beaucoup plus de ccTLD dans les trois premières positions, devant les sous-répertoires puis les sous-domaines.
Ces chiffres sont corrélationnels, pas causaux. Les ccTLD appartiennent souvent à des marques locales établies, entreprises nationales et distributeurs déjà puissants. .de ne crée pas leur classement : leur pertinence, leurs liens et leur réputation le font. Le signal aide à la marge, sans fabriquer l’autorité manquante. Ne concluez pas qu’une migration vers un ccTLD améliorera automatiquement les positions.
Où trouver les compromis non internationaux
Tout ce qui précède concerne le ciblage international. Une autre question porte sur l’équivalence générale d’un sous-domaine et d’un sous-répertoire pour un blog, un centre d’aide ou une documentation, ainsi que sur les migrations dont les résultats sont brouillés par d’autres changements. L’article général sous-domaine ou sous-répertoire traite les cas Pink Cake Box et IWantMyName, les signaux d’intégration et le proxy inverse. Pour un blog, commencez par là ; pour plusieurs pays, vous êtes au bon endroit.
Propriété, gouvernance et coût font partie de la décision
Les compromis dépassent le seul signal géographique :
- Propriété et disponibilité. Il faut pouvoir acheter et conserver le ccTLD. Certains registres imposent une entreprise, un contact ou une adresse locale. Quelques ccTLD, comme
.ioou.co, sont commercialisés comme domaines génériques ; toutes les terminaisonsccne sont donc pas interprétées de la même façon. - Gouvernance et déploiements isolés. Un ccTLD ou sous-domaine peut appartenir à une équipe, une pile et un calendrier distincts. Cette autonomie multiplie aussi les propriétés à sécuriser, surveiller et harmoniser, ainsi que les risques d’erreur locale.
- Coût. Enregistrement, renouvellement, hébergement et certificats augmentent avec chaque propriété. Une stratégie par ccTLD les multiplie ; les dossiers les regroupent.
Adaptez donc la structure aux marchés, aux responsables capables d’entretenir chaque propriété et à l’importance réelle de la confiance locale. La question « laquelle se classe mieux ? » masque les contraintes qui tranchent en pratique.
Risque de migration
Passer d’un ccTLD à un dossier, d’un sous-domaine à un ccTLD ou dans l’autre sens constitue une migration d’URL complète, jamais un simple copier-coller :
- Redirections. Chaque ancienne URL doit rediriger individuellement vers son équivalent, pas vers l’accueil.
- Balises canoniques. Mettez-les à jour ; pour des doublons régionaux de même langue, Google recommande une URL canonique préférée associée à hreflang.
- hreflang. Chaque ensemble réciproque doit référencer les nouvelles URL sur toutes les propriétés.
- Liens internes et sitemaps. Remplacez les URL et actualisez les sitemaps XML.
- Validation des hôtes. Ajoutez le ccTLD ou le sous-domaine à Search Console et Bing Webmaster Tools avant d’avoir besoin des données.
- Suivi. Surveillez indexation, trafic et positions. Une comparaison avant/après reste brouillée par les redirections, contenus et liens modifiés simultanément.
Ne migrez pas uniquement pour chercher un gain de classement : Google ne privilégie aucune structure et la migration présente davantage de risques que le changement ne résout probablement de problèmes.
Ma recommandation
- Par défaut, utilisez des sous-répertoires (
example.com/de/) : coût minimal et autorité regroupée. En contrepartie, appliquez hreflang correctement, seul levier explicite depuis 2022. - Choisissez des ccTLD quand le signal national justifie la fragmentation : domaines déjà possédés, secteur où l’adresse locale inspire fortement confiance ou obligations juridiques. Vérifiez les règles d’enregistrement et acceptez que chaque domaine construise sa propre autorité.
- Choisissez des sous-domaines surtout pour séparer l’infrastructure, sans acheter des domaines différents. Le ciblage manuel reste identique à celui d’un dossier.
- Évitez tout mélange improvisé. Une structure cohérente sur tous les marchés simplifie hreflang et l’exploration.
- Planifiez toute migration. Redirections, URL canoniques, hreflang, liens, sitemaps, validation des hôtes et suivi sont indispensables.
Place dans l’ensemble
Les autres articles de ce groupe couvrent l’audit SEO international, la liste de mise en œuvre, la recherche de mots-clés par marché et la différence entre traduction et localisation. Les mécanismes de balisage se trouvent dans hreflang et x-default. Une fois la structure choisie, la qualité de hreflang est presque toujours plus importante que la forme de l’URL.
Résumé par l’IA
Version condensée de l’onglet Avancé :
- Trois structures : ccTLD (
example.de), sous-domaine de gTLD (de.example.com) ou sous-répertoire (example.com/de/). - Google ne préfère aucune structure pour le classement. Le choix concerne les signaux et l’exploitation.
- Le signal géographique fait la différence. Un ccTLD désigne automatiquement et sans ambiguïté un pays. Les sous-domaines et dossiers d’un gTLD dépendent de hreflang, de l’emplacement, de la langue, de la devise et des liens locaux.
- Ciblage international supprimé en septembre 2022. Aucun réglage Search Console ne permet plus d’attribuer un pays à un sous-répertoire ; hreflang est le seul levier explicite restant.
- Le ccTLD fragmente l’autorité. Chaque domaine obtient ses propres backlinks, multiplie l’infrastructure et complique hreflang entre propriétés.
- Le sous-répertoire coûte le moins cher et regroupe l’autorité, mais dépend entièrement de hreflang pour le ciblage.
- Le sous-domaine est intermédiaire : nom d’hôte distinct et hébergement flexible, mais mêmes signaux manuels qu’un dossier.
- Corrélation ne signifie pas causalité. La présence fréquente de ccTLD en tête des résultats reflète souvent la puissance des marques locales établies.
- Propriété, gouvernance et coût comptent. Certains registres imposent une présence locale ; chaque propriété augmente le travail et les dépenses.
- Changer de structure est une migration complète qui exige redirections, URL canoniques, hreflang, liens, sitemaps, validation et suivi.
- Choix par défaut de Patrick : les sous-répertoires, sauf ccTLD existant, besoin juridique ou de confiance, ou séparation technique réelle. La cohérence entre marchés prime.
Quelle structure utiliser ?
Parcourez ces questions dans l’ordre ; le premier « oui » détermine généralement le choix.
1. Possédez-vous déjà des domaines nationaux, ou votre entreprise y est-elle déjà établie (example.de, example.fr) ?
→ Conservez les ccTLD. L’autorité locale est déjà construite ; ne la sacrifiez pas pour regrouper les domaines. Reliez correctement les propriétés avec hreflang.
2. Le marché impose-t-il juridiquement un domaine local, ou la confiance locale est-elle décisive dans la finance, la santé, le secteur public ou la grande distribution ? → Utilisez un ccTLD pour ce marché. Le signal automatique et la confiance inspirée par l’adresse locale justifient ici le domaine supplémentaire. Vous pouvez combiner ccTLD et dossiers entre marchés, à condition de rester cohérent dans chacun.
3. Chaque pays doit-il disposer d’un serveur, d’une pile ou d’une équipe réellement distincts sans acheter d’autres domaines ?
→ Utilisez un sous-domaine (de.example.com). Vous obtenez la souplesse d’hébergement, mais devez toujours appliquer hreflang : le sous-domaine ne se géocible pas lui-même.
4. Aucun cas précédent : votre site principalement en .com s’étend à de nouvelles langues ou de nouveaux pays et recherche la solution la plus simple ?
→ Utilisez des sous-répertoires (example.com/de/). Autorité, hébergement et propriété Search Console restent regroupés. Appliquez soigneusement hreflang, car aucun réglage manuel de pays n’existe depuis septembre 2022.
Deux règles priment sur l’arbre :
- La cohérence vaut mieux que le choix « parfait ». Une même structure correctement appliquée sur tous les marchés surpasse un assemblage improvisé.
- Ne migrez jamais seulement pour gagner des positions. Google n’a aucune préférence ; le risque de migration dépasse généralement un signal que hreflang peut fournir.
Documentation officielle
Documentation de première main publiée par les moteurs de recherche.
- Gérer les sites multirégionaux et multilingues — les trois structures, leurs avantages et leurs coûts, et la recommandation d’utiliser des URL distinctes plutôt qu’une diffusion fondée sur les cookies ou le navigateur.
- Bonnes pratiques de structure d’URL — ccTLD ou sous-répertoires pour le ciblage, sans préférence de classement déclarée.
- Indiquer les versions localisées avec hreflang — règles réciproques de hreflang, seul signal géographique explicite restant pour les sous-domaines et dossiers de gTLD, avec les signaux déduits.
- Exploration et indexation des sites multilingues — découverte et diffusion de la version locale appropriée.
Bing / Microsoft
- Indiquer à Bing le pays et la langue d’un site — consignes de Bing, qui accorde davantage de poids au signal meta ou d’en-tête
content-languagequ’à hreflang. - Consignes Bing pour les webmasters — aucune préférence imposée entre ccTLD, sous-domaine et sous-répertoire pour un site légitime.
Citations des sources
Déclarations publiques et positions documentées. Les formulations sans sous-chaîne exacte et lien profond vérifiés sont paraphrasées sans guillemets.
Google — aucune préférence de classement entre les structures
- Paraphrase : Google recommande de choisir la structure la plus facile à organiser et à gérer et indique n’avoir aucune préférence d’indexation ou de classement entre elles. Documentation sur les URL
Google — trois structures internationales et leurs compromis
- Paraphrase de la documentation multirégionale : un ccTLD offre un ciblage clair et une séparation facile, mais coûte cher et exige davantage d’infrastructure ; un sous-domaine de gTLD est simple à configurer et accepte différents serveurs, mais son ciblage peut être peu lisible ; un sous-répertoire de gTLD est simple et peu coûteux sur un hôte unique, avec la même limite de lisibilité. Gérer les sites multirégionaux et multilingues
Google — suppression du rapport Ciblage international en septembre 2022
- Paraphrase de l’annonce Search Console : le rapport a été supprimé parce que la valeur du réglage manuel de pays avait diminué à mesure que hreflang progressait ; hreflang reste le mécanisme des versions localisées. Avis de suppression de Google
Erreurs fréquentes et solutions
Mythe 1 : « Un ccTLD se classe mieux ; il en faut un par pays. » C’est faux : Google ne privilégie aucune structure et chaque ccTLD constitue un domaine distinct dont l’autorité, l’infrastructure et hreflang repartent presque de zéro. Les études sont corrélationnelles et reflètent souvent des marques locales établies. À faire : réservez les ccTLD aux cas où le signal national ou la confiance locale justifie réellement la fragmentation ; sinon, regroupez sur des dossiers.
Mythe 2 : « Les sous-répertoires sont équivalents, donc hreflang est inutile. » C’est faux : un dossier de gTLD ne reçoit aucun signal national automatique et aucun réglage manuel n’existe depuis septembre 2022. À faire : appliquez hreflang de façon réciproque et autoréférente à tous les dossiers locaux.
Mythe 3 : « Je peux définir dans Search Console le pays de mon dossier /de/. »
C’est faux : le rapport Ciblage international a été supprimé en septembre 2022.
À faire : utilisez hreflang et les signaux déduits — emplacement, langue, devise, adresse et liens locaux.
Mythe 4 : « Un sous-domaine se géocible automatiquement parce que son nom d’hôte est distinct. »
C’est faux : de.example.com reste sur .com et exige les mêmes signaux qu’un sous-répertoire. Le nom d’hôte distinct apporte une souplesse d’hébergement, pas un signal national automatique.
À faire : traitez son ciblage comme celui d’un dossier et ne le choisissez que pour ses avantages d’infrastructure.
Mythe 5 : « Une migration vers un ccTLD ou un dossier corrigera de mauvaises positions internationales. » C’est faux : la migration ajoute du risque sans gain garanti et les réussites apparentes coïncident souvent avec d’autres changements. À faire : corrigez d’abord hreflang, la qualité du contenu local et les liens provenant du pays.
Mythe 6 : « Je peux mélanger les structures selon ce qui m’arrange dans chaque marché. » C’est faux : l’incohérence complique les groupes hreflang, l’exploration et l’analyse de l’autorité. À faire : appliquez une structure principale et ne dérogez que pour une raison précise, comme un ccTLD existant ou une obligation légale.
Liste de contrôle pour choisir une structure internationale
Avant le choix
- Confirmez qu’un ciblage par pays ou langue est nécessaire, et pas seulement la traduction d’un site mondial.
- Dressez la liste des marchés et de leurs éventuelles obligations d’enregistrement local.
- Vérifiez si vous possédez déjà les ccTLD ou y obtenez des positions.
- Évaluez l’importance de la confiance locale : finance, santé et distribution favorisent souvent les ccTLD ; SaaS et contenu acceptent généralement les dossiers.
Décision
- Présence déjà établie sur des ccTLD, ou impératif juridique/de confiance ? → ccTLD.
- Hébergement séparé par pays sans domaines distincts ? → sous-domaine.
- Sinon, priorité à la simplicité et à l’autorité regroupée ? → sous-répertoire, le choix par défaut.
- Appliquez le modèle choisi de façon cohérente sur tous les marchés.
Après le choix d’une structure de gTLD
- N’oubliez pas l’absence de réglage manuel de pays dans Search Console depuis septembre 2022.
- Implémentez un hreflang réciproque et autoréférent pour toutes les versions.
- Ajoutez un x-default à la page de sélection ou de secours.
- Renforcez les signaux déduits : emplacement, langue, devise, coordonnées locales et liens nationaux.
- Ne migrez pas une structure fonctionnelle uniquement pour chercher de meilleures positions.
Si vous choisissez des ccTLD
- Budgétez séparément l’enregistrement, le renouvellement, l’hébergement et les certificats de chaque domaine.
- Planifiez hreflang entre toutes les propriétés, avec des références réciproques.
- Acceptez que chaque domaine développe sa propre autorité sans mutualiser les backlinks.
En cas de migration
- Redirigez individuellement chaque ancienne URL vers son équivalent, jamais toutes vers l’accueil.
- Actualisez les URL canoniques et conservez URL préférée plus hreflang pour les doublons régionaux de même langue.
- Reconstruisez hreflang réciproquement avec les nouvelles URL sur toutes les propriétés.
- Actualisez les liens internes et les sitemaps XML.
- Validez le nouvel hôte dans Search Console et Bing Webmaster Tools avant d’avoir besoin des données.
- Surveillez indexation, trafic et positions, en tenant compte de la migration comme facteur de confusion.
Modèles mentaux
1. Signal contre autorité : le compromis central. Le ccTLD maximise le signal géographique, automatique et clair, mais fragmente l’autorité entre plusieurs domaines. Le dossier regroupe l’autorité mais dépend de hreflang. Le sous-domaine se place entre les deux. Presque chaque décision se situe sur cet axe.
2. Signal automatique ou manuel. Seul le ccTLD offre gratuitement le signal national. Toute structure de gTLD dépend d’un signal dont vous êtes responsable et, depuis septembre 2022, ce signal explicite est hreflang, pas un réglage Search Console.
3. La structure n’est pas un levier de classement. Google n’a aucune préférence. La pertinence, la confiance et les liens locaux déterminent les positions ; la structure change seulement la clarté du signal national.
4. La cohérence prime sur l’optimisation. Une structure correctement appliquée dans tous les marchés vaut mieux qu’un mélange fondé sur des intuitions. Elle seule garde hreflang et l’exploration gérables à grande échelle.
5. Distinguez la question internationale de la question générale. « Où placer mon blog ? » et « Comment servir plusieurs pays ? » sont deux décisions différentes. La première dépend de l’intégration et du risque de migration ; la seconde du signal géographique. Ne transposez pas automatiquement la réponse de l’une à l’autre.
Testez vos connaissances : ccTLD, sous-domaine ou sous-répertoire
Cinq questions rapides sur le choix d’une structure d’URL internationale.
Ressources à consulter
Mes articles connexes
- Hreflang : guide facile pour débutants — mécanisme indispensable aux sous-domaines et dossiers de gTLD, avec mon étude de 374 756 domaines dont plus de 67 % présentaient un problème.
- Guide du débutant sur le SEO technique — place du choix d’URL internationale dans l’ensemble.
- Sous-domaine ou sous-répertoire : les dossiers ne sont pas meilleurs pour le SEO — analyse générale, non internationale, de leur équivalence et des migrations brouillées par d’autres changements.
Mes conférences
- Fonctionnement de la recherche (SlideShare) — présentation de l’exploration, du rendu, de l’indexation et du classement. Avertissement permanent : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Voici ma compréhension des systèmes ; elle ne sera ni complète ni exacte à 100 %. »
Dans le secteur
- Gérer les sites multirégionaux et multilingues (Google Search Central) — liste officielle des trois structures et de leurs compromis.
- Suppression du rapport Ciblage international (Aide Search Console) — changement de septembre 2022 et conséquences pour les dossiers.
- Bonnes pratiques de structure d’URL (Google Search Central) — ciblage géographique et absence de préférence.
- Étude sous-domaines/sous-répertoires sur 20 000 mots-clés (SE Ranking) — étude corrélationnelle transparente dans 15 marchés.
- Bonnes pratiques SEO avec Cloudflare Workers, partie 1 (Cloudflare) — solution de proxy inverse pour afficher un contenu de sous-domaine sous une URL de dossier.
Journal des modifications
Mis à jour le 11 août 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.
Mis à jour le 11 août 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.
Mis à jour le 18 juil. 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.