Sous-répertoire vs sous-domaine pour le référencement multilingue

Résumez ce post avec : 8 minutes de lecture

Pour un site Web multilingue, les deux sous-répertoires (example.com/fr/) et sous-domaines (fr.example.com) fonctionnent pour le référencement, et Google répertorie les deux comme des options valides. Les sous-répertoires sont la valeur par défaut habituelle car chaque langue partage un domaine et est simple à gérer. Les sous-domaines ont du sens lorsqu'une version linguistique nécessite un hébergement séparé ou une équipe distincte, ou lorsque votre plateforme ne peut pas servir les dossiers traduits en toute sécurité. Ce qui compte plus que le choix, c'est de le faire de manière cohérente : une URL par langue, des balises hreflang et aucune redirection automatique.

Principaux points à retenir

Le guide de Google sur les sites multilingues répertorie les domaines de pays, les sous-domaines et les sous-répertoires comme options et marque les paramètres d'URL (?lang=fr) comme non recommandé.
Sous-répertoires: un domaine, une configuration d'hébergement, une propriété Search Console, des analyses plus simples. Le choix le plus courant pour les sites traduits.
Sous-domaines: chaque langue sur son propre nom d'hôte. Plus facile à héberger ou à transférer séparément ; légèrement plus de configuration dans les analyses et la Search Console.
Google détermine la langue à partir du contenu visible de la page, et non à partir de l'URL, donc la structure de l'URL à elle seule ne crée pas de page “française” pour Google. hreflang connecte les versions.
Choisissez proprement la structure que votre plateforme prend en charge. Une configuration qui peut mettre votre site principal hors ligne est pire qu’une URL légèrement moins ordonnée.

Qu'est-ce qu'un sous-répertoire ?

Un sous-répertoire (également appelé sous-dossier) est un dossier dans le chemin de votre domaine principal :

https://example.com/        (English)
https://example.com/fr/     (French)
https://example.com/de/     (German)

Tout vit sur un seul nom d'hôte. La page de tarification française est example.com/fr/pricing, l'allemand example.com/de/pricing.

Qu'est-ce qu'un sous-domaine ?

Un sous-domaine est un préfixe devant votre nom de domaine, ce qui en fait techniquement un nom d'hôte distinct :

https://example.com/        (English)
https://fr.example.com/     (French)
https://de.example.com/     (German)

La page de tarification française devient fr.example.com/pricing. Chaque sous-domaine est créé avec un enregistrement DNS et peut pointer vers un serveur différent.

Ce que dit Google

Page de Google sur gestion de sites multirégionaux et multilingues compare directement les options :

Structure	Exemple	Les avantages de Google	Les inconvénients de Google
Domaine de code pays	`example.de`	Ciblage géographique clair ; emplacement du serveur non pertinent ; séparation facile	Cher ; plus d'infrastructures ; règles ccTLD strictes ; cible un seul pays
Sous-domaine avec gTLD	`de.example.com`	Facile à configurer ; permet différents emplacements de serveur ; séparation facile	Les utilisateurs peuvent ne pas reconnaître le ciblage géographique à partir de l'URL seule
Sous-répertoire avec gTLD	`example.com/de/`	Facile à installer ; faible entretien (même hôte)	Les utilisateurs peuvent ne pas reconnaître le ciblage géographique à partir de l'URL ; emplacement d'un seul serveur ; il est plus difficile de séparer les sites
Paramètres d'URL	`example.com?loc=de`	Non recommandé	Difficile à segmenter ; peu clair pour les utilisateurs et les moteurs de recherche

Deux autres déclarations dans le même guide justifient cette décision :

Google utilise le contenu visible de la page pour déterminer sa langue, et n'utilise pas d'informations au niveau du code telles que lang attributs ou l'URL.
Google vous conseille de éviter la redirection automatique utilisateurs d'une version linguistique à une autre en fonction des préférences supposées, car cela peut empêcher les utilisateurs et Googlebot d'atteindre chaque version.

En d’autres termes, Google ne préfère pas officiellement une structure unique pour le classement. Les différences pratiques résident dans la maintenance, la mesure et le risque.

Sous-répertoires vs sous-domaines : côte à côte

Facteur	Sous-répertoires (`/fr/`)	Sous-domaines (`fr.`)
Configuration	A besoin de votre plateforme ou d'un proxy pour servir `/fr/` chemins	Un enregistrement DNS (CNAME) par langue
Hébergement	Toutes les langues sur le même hôte	Chaque langue peut être hébergée séparément
Console de recherche	Couvert par une propriété de domaine ; vous pouvez ajouter chaque dossier comme sa propre propriété pour voir les données par langue	Chaque sous-domaine peut être sa propre propriété ; une propriété de domaine les couvre tous
Analyses	Un seul site, pas de configuration inter-domaines	Fonctionne généralement dans une propriété GA4, mais vérifiez les paramètres des cookies et des références
Lien interne	Toutes les pages clairement sur un seul site	Toujours une marque, mais des noms d'hôtes distincts
Séparation	Plus difficile à séparer plus tard	Il est facile de transmettre une langue à une équipe ou à un partenaire local
Risque en cas de mauvaise configuration	Sur certaines plateformes, un mauvais changement DNS peut affecter l'ensemble du site	Un mauvais enregistrement n’affecte que cette langue

C'est l'argument le plus répété en faveur des sous-répertoires : les liens vers votre domaine principal aident le /fr/ dossier car c'est “le même site”. Cela a du sens. Tout ce qui se trouve sous un même nom d'hôte est clairement un seul site, lié en interne et géré ensemble, et de nombreux praticiens du référencement voient les nouveaux dossiers linguistiques gagner en visibilité plus rapidement que les nouveaux sous-domaines.

Mais soyez prudent avec les affirmations fortes. Google n'a pas publié de règle selon laquelle les sous-domaines sont moins bien classés et “l'autorité du domaine” est une mesure tierce et non un signal Google. Un sous-domaine bien lié avec un bon contenu et un hreflang correct se classe bien. Si un sous-répertoire est facile pour vous, c'est un bon choix par défaut ; s'il est risqué ou impossible sur votre plateforme, un sous-domaine est un choix parfaitement judicieux.

Quand choisir des sous-répertoires

Votre CMS prend en charge les dossiers linguistiques de manière native ou votre plugin de traduction les sert (WordPress est le cas typique).
Vous souhaitez des analyses et une configuration de Search Console les plus simples.
Vous avez une équipe qui gère chaque langue.
Vous voulez que chaque langue ressemble à une partie du même site pour les visiteurs.

Quand choisir des sous-domaines

Votre plateforme ne peut pas servir de dossiers traduits, sinon cela nécessiterait de pointer l'ensemble de votre domaine vers un proxy tiers.
Différentes langues nécessitent un hébergement différent, par exemple un serveur plus proche du marché ou une pile distincte.
Une équipe locale, une agence ou un partenaire exécutera une version linguistique.
Vous souhaitez qu'un problème dans une langue (une erreur DNS, une panne) y reste contenu.

Quand utiliser les domaines de pays à la place

Un domaine de code pays (example.de, example.fr) est un signal local plus fort et peut renforcer la confiance, en particulier sur les marchés où les clients attendent un domaine local. C'est aussi le plus cher et le plus laborieux : domaines séparés, création de liens séparée, configuration juridique et d'hébergement séparée. Il associe les entreprises établies à de véritables opérations locales. Rien que pour la traduction, c'est généralement excessif.

Des erreurs qui comptent plus que la structure

Quelle que soit la structure que vous choisissez, ces erreurs causent plus de dégâts que le choix lui-même :

Une URL pour toutes les langues. Si la langue change avec un cookie ou un script mais que l'URL reste la même, Google ne peut indexer qu'une seule version.
Redirections automatiques par langue de navigateur ou IP. Google le déconseille. Proposez plutôt un sélecteur de langue ou une bannière de suggestions.
Hreflang manquant ou cassé. Chaque version doit se répertorier elle-même et toutes les versions alternatives, avec des URL entièrement qualifiées. Voir notre guide complet de hreflang et le liste des codes hreflang valides.
Balises canoniques pointant vers la langue originale. Chaque version linguistique doit être canonique pour elle-même.
Titres non traduits et méta descriptions. Une page française avec un titre anglais ressemble à un doublon.
Nidification profonde ou incohérente. Gardez la langue au plus haut niveau (/fr/pricing, non /pricing/fr/ sur certaines pages et /fr/pricing sur les autres).
Modification de la structure après le lancement sans redirections. Si vous passez ultérieurement de sous-domaines à sous-dossiers, mappez chaque ancienne URL à sa nouvelle avec des redirections 301.

Comment ConveyThis gère la structure de l'URL

ConveyThis prend en charge les deux structures, ainsi qu'un mode par défaut et un mode paramètre URL pour les plates-formes où rien d'autre n'est possible. Avec des sous-domaines ou des sous-répertoires, chaque langue obtient sa propre URL indexable et ConveyThis ajoute des balises hreflang et traduit des titres, des méta descriptions et des données structurées. Des sous-domaines et des sous-répertoires sont disponibles dans le plan d'affaires (voir prix).

Notre propre recommandation est pratique plutôt que dogmatique, et elle dépend de la plateforme :

WordPress: le plugin ConveyThis utilise des sous-répertoires par défaut et ne nécessite aucune modification DNS, donc /fr/ est le chemin facile.
Sites sur mesure : les sous-domaines sont généralement plus sûrs. Vous ajoutez un enregistrement CNAME par langue et votre site principal reste sur votre propre hébergeur. Une configuration de sous-répertoire sur ces sites signifie acheminer l'ensemble de votre domaine via ConveyThis, et une erreur DNS affecte alors le site d'origine, pas seulement les traductions.
Shopify: les sous-répertoires jusqu'à ConveyThis ne sont pas disponibles ; utilisez des sous-domaines.
Wix, Bubble, Framer et adorable : aucune des deux structures n'est actuellement proposée pour ces plateformes, c'est pourquoi le mode par défaut ou paramètre est utilisé.

Le article d'aide sur les sous-domaines et les sous-répertoires parcourt chaque plateforme et les étapes DNS, et le page SEO multilingue couvre le reste de la configuration SEO.

Questions fréquemment posées

Les sous-répertoires sont-ils meilleurs que les sous-domaines pour le référencement ? En aucun cas, Google n'a publié. Google répertorie les deux comme valides. Les sous-répertoires sont plus simples à exécuter et constituent une bonne valeur par défaut ; les sous-domaines conviennent lorsque votre configuration les appelle.

Puis-je utiliser ?lang=fr des paramètres à la place ? Vous pouvez, mais Google indique que les paramètres d'URL ne sont pas recommandés pour les sites multilingues. Utilisez-les uniquement si votre plateforme ne prend en charge rien d’autre.

Chaque langue doit-elle avoir sa propre propriété Search Console ? Ça aide. Avec les sous-répertoires, vous pouvez ajouter chaque dossier en tant que propriété de préfixe d'URL ; avec les sous-domaines, chaque sous-domaine peut être sa propre propriété. Les deux vous permettent de voir les performances par langue.

Puis-je passer des sous-domaines aux sous-répertoires plus tard ? Oui, mais considérez-le comme une migration de site : redirigez 301 chaque ancienne URL vers la nouvelle, mettez à jour hreflang et les plans de site et attendez-vous à un certain mouvement de classement pendant que Google retraite le changement.

Prêt à donner à chaque langue sa propre URL optimisée pour le référencement ? Créer un compte ConveyThis et choisissez la structure qui correspond à votre plateforme.