Sous-domaine ou sous-répertoire : quel choix pour le SEO ?

Sous-domaine ou sous-répertoire : la question ressurgit régulièrement dès qu'un site veut ajouter un blog, une boutique en ligne ou un centre d'aide à un domaine existant. Elle est souvent confondue avec un autre débat, celui des versions linguistiques d'un site : faut-il un ccTLD par pays, un sous-domaine par langue ou des sous-dossiers pour chaque traduction. Ici, il s'agit d'un cas différent : un seul marché, une seule langue, mais un contenu qui pourrait vivre sous la forme d'un hôte séparé, comme blog.exemple.com, ou d'un dossier du domaine principal, comme exemple.com/blog.

Le choix a des conséquences concrètes sur la façon dont Google répartit l'autorité, sur le nombre de propriétés à surveiller dans Search Console, sur le comportement de Googlebot au moment de l'exploration, et sur le coût d'un changement d'avis deux ans plus tard. Ce n'est pas une question de préférence esthétique dans l'URL : c'est une décision d'architecture qui se paie, dans un sens ou dans l'autre. Le sujet revient aussi souvent parce que la décision est prise tôt, avant que le contenu existe, et qu'elle est ensuite très difficile à revoir sans y consacrer un projet à part entière.

Ce que change un sous-domaine techniquement

D'un point de vue purement technique, un sous-domaine comme blog.exemple.com est un hôte distinct de exemple.com, même s'il partage le même nom de domaine racine et, souvent, le même hébergement. Un sous-répertoire comme exemple.com/blog fait au contraire partie du même hôte que la page d'accueil, exactement comme n'importe quelle autre page du site.

Cette distinction a longtemps fait l'objet d'un débat sur l'équivalence des deux traitements par Google. En pratique, un sous-domaine correctement configuré peut être exploré, indexé et positionné sans difficulté de principe, tout comme un sous-dossier. La différence ne se situe donc pas dans la capacité à se positionner, mais dans la façon dont les signaux se répartissent entre les deux hôtes et dans la charge opérationnelle que chaque structure impose à l'équipe qui la gère. Un outil de scan technique verra d'ailleurs souvent le sous-domaine comme un site entièrement séparé, avec son propre score et ses propres alertes, ce qui peut donner une fausse impression de deux sites indépendants alors qu'ils appartiennent à la même marque.

Comment l'autorité se répartit entre les deux structures

Un sous-dossier hérite directement du profil de liens et de l'ancienneté du domaine racine. Un lien externe qui pointe vers exemple.com/produit renforce le même hôte que celui qui pointe vers exemple.com/blog/article : tout le maillage interne et tous les liens externes alimentent une seule et même entité aux yeux du moteur de recherche.

Un sous-domaine, parce qu'il est traité comme un hôte séparé, ne bénéficie pas automatiquement du même niveau de confiance que le domaine principal. Il part avec son propre historique d'exploration et doit, dans une certaine mesure, faire ses preuves indépendamment. Le maillage interne entre le domaine principal et le sous-domaine reste utile et transmet bien de la valeur de liaison, mais il transite par un lien qui traverse deux hôtes plutôt que par la continuité implicite d'un même hôte. Pour un site qui dispose de peu de liens entrants à distribuer, cette différence peut ralentir la montée en visibilité du nouveau contenu. Dans un secteur concurrentiel, où chaque page compte pour appuyer les pages commerciales, cette dilution peut se traduire par plusieurs mois d'écart avant que le nouveau contenu atteigne son plein potentiel de classement.

• Sous-dossier : hérite immédiatement de l'autorité et de l'ancienneté du domaine principal.
• Sous-domaine : part avec un profil distinct, même si le maillage interne l'aide.
• Dans les deux cas, la qualité du contenu et la densité du maillage comptent davantage que la structure d'URL seule.

Search Console : une propriété ou deux

C'est le point le plus souvent sous-estimé au moment du choix. Un sous-domaine constitue une propriété distincte dans Search Console, sauf à utiliser une propriété de type domaine, qui regroupe alors tous les sous-domaines et tous les protocoles sous une racine commune. Un sous-répertoire, lui, reste dans la même propriété que le reste du site, qu'elle soit de type domaine ou de type préfixe d'URL.

Concrètement, avec un sous-répertoire, les rapports de performance, de couverture d'indexation et Core Web Vitals du blog ou de la boutique s'ajoutent naturellement aux rapports déjà en place : une seule vue à surveiller au quotidien. Avec un sous-domaine suivi comme propriété de type préfixe d'URL, il faut ajouter et vérifier une propriété séparée, suivre ses propres rapports de couverture, et se rappeler qu'un problème d'indexation sur ce sous-domaine n'apparaîtra jamais dans les alertes de la propriété principale. Une propriété de type domaine règle ce problème de suivi fragmenté, mais elle demande un accès au DNS pour la vérification, ce qu'une équipe ne peut pas toujours obtenir rapidement. Ce détail est facile à oublier au moment du lancement, quand l'attention est tournée vers la mise en ligne plutôt que vers le suivi à long terme, et il ressurgit en général plusieurs mois plus tard sous la forme d'une baisse de trafic inexpliquée.

Exploration et budget de crawl : ce qui bouge réellement

Googlebot explore un site en fonction de sa capacité de réponse, de la fraîcheur perçue du contenu et du nombre de chemins qu'il découvre. Un sous-répertoire profite du même plan de site, du même maillage de navigation et souvent du même fichier robots.txt que le reste du domaine, ce qui facilite la découverte rapide des nouvelles pages.

Un sous-domaine se comporte comme un site à part pour l'exploration : il peut avoir son propre robots.txt, son propre plan de site, et sa propre fréquence de passage de Googlebot, surtout s'il tourne sur une infrastructure ou un système de gestion de contenu différent de celui du domaine principal, un cas fréquent quand un centre d'aide utilise un logiciel de support dédié. Cette séparation n'est pas un problème en soi, mais elle signifie qu'il faut soumettre et surveiller le plan de site du sous-domaine séparément : personne ne le fera à la place de l'équipe simplement parce qu'il partage le nom de domaine.

• Sous-dossier : découverte facilitée par le maillage et le plan de site déjà en place.
• Sous-domaine : plan de site et robots.txt à gérer et à surveiller séparément.
• Un sous-domaine hébergé sur une plateforme tierce, support ou commerce en ligne, peut avoir des contraintes d'exploration propres au fournisseur.

Trois cas concrets : blog, boutique et centre d'aide

Un blog éditorial dont l'objectif est d'attirer du trafic informationnel et de renforcer les pages commerciales du site a presque toujours intérêt à vivre en sous-dossier. Le maillage interne entre un article et une page produit devient alors un simple lien du même hôte vers lui-même, ce qui est la configuration la plus directe pour faire remonter l'autorité acquise par le contenu vers les pages qui convertissent.

Une boutique ajoutée à un site vitrine pose une question différente, celle de la plateforme technique. Si la boutique tourne sur un moteur de commerce en ligne distinct qui ne peut techniquement s'installer que sur son propre sous-domaine, le choix n'est plus vraiment un choix de référencement mais une contrainte d'infrastructure. Dans ce cas, il vaut mieux investir dans un maillage interne soigné entre le site principal et la boutique plutôt que de forcer une intégration en sous-dossier fragile et coûteuse à maintenir.

Un centre d'aide est le cas le plus souvent mal tranché. Beaucoup d'équipes le placent sur un sous-domaine par défaut, simplement parce que le logiciel de support le propose ainsi, sans se demander si son contenu, des réponses à des questions transactionnelles et de réassurance, pourrait aussi renforcer les pages produit si les articles vivaient en sous-dossier. Quand la plateforme de support le permet techniquement, un sous-dossier est en général préférable pour un centre d'aide dont les articles peuvent se positionner sur des requêtes informationnelles proches des produits vendus.

Le coût d'une migration une fois le choix fait

Changer de structure après coup n'est pas neutre. Migrer un sous-domaine vers un sous-répertoire, ou l'inverse, implique de rediriger chaque URL individuellement avec des redirections permanentes, de mettre à jour tout le maillage interne qui pointait vers l'ancienne structure, de resoumettre un nouveau plan de site, et d'accepter une période où le suivi dans Search Console se chevauche entre l'ancienne et la nouvelle propriété.

Le trafic ne bascule pas instantanément : Google doit réexplorer les nouvelles URL, recalculer leur position dans l'index, et abandonner progressivement les anciennes. Selon le volume de pages concernées et la vitesse de réexploration habituelle du site, cette phase de transition peut s'étaler sur plusieurs semaines, pendant lesquelles une partie du trafic organique du contenu migré peut fluctuer. Ce n'est pas une raison pour ne jamais migrer si la structure initiale est réellement mauvaise, mais c'est une raison de trancher correctement dès le départ plutôt que de traiter le choix comme réversible sans coût.

• Des redirections permanentes une à une, jamais une redirection générique du domaine entier.
• Une mise à jour du maillage interne dans tout le contenu déjà publié.
• Un nouveau plan de site, et une nouvelle vérification dans Search Console si la propriété change de type.
• Une période de transition pendant laquelle le trafic du contenu migré peut varier sensiblement.

Comment trancher pour un site à marché unique

Le sous-dossier doit rester le choix par défaut chaque fois que le contenu ajouté vise à renforcer les pages existantes du domaine : blog éditorial, guides, centre d'aide, pages de comparaison. Il concentre l'autorité au même endroit, simplifie le suivi dans les outils, et rend le maillage interne plus direct entre le contenu et les pages qui doivent en profiter.

Le sous-domaine se justifie quand une contrainte technique réelle l'impose : une plateforme qui ne s'installe que sur son propre hôte, un besoin d'isoler un environnement, comme une application ou un espace client, qui n'a pas vocation à se positionner sur des requêtes de recherche, ou une équipe et une infrastructure totalement séparées qui ne pourraient de toute façon pas maintenir un sous-dossier intégré au même système que le site principal.

Dans les deux cas, la question à se poser n'est pas seulement de savoir où il est techniquement possible d'installer le contenu, mais si ce contenu a vocation à faire remonter de l'autorité vers le reste du site, ou s'il vit sa vie indépendamment de lui. La réponse à cette question détermine presque toujours la bonne structure à retenir.

• Contenu qui doit renforcer le reste du site : sous-dossier par défaut.
• Contrainte de plateforme ou d'infrastructure réellement bloquante : sous-domaine, avec un maillage interne soigné en compensation.
• Dans le doute, mieux vaut commencer en sous-dossier : la migration inverse est tout aussi coûteuse mais bien moins souvent nécessaire par la suite.

Erreurs qui compliquent la suite

La première erreur consiste à choisir la structure en fonction de la facilité d'installation immédiate du logiciel plutôt qu'en fonction du rôle réel du contenu dans la stratégie de recherche. Un centre d'aide installé en quelques minutes sur un sous-domaine peut sembler un gain de temps, alors qu'un sous-dossier aurait mieux servi l'ensemble du site sur la durée.

La deuxième erreur est de laisser un sous-domaine sans surveillance dans Search Console parce qu'il n'apparaît pas dans les rapports habituels de la propriété principale : des erreurs d'indexation ou une chute de couverture peuvent y passer inaperçues pendant des mois si personne ne consulte cette propriété séparément et régulièrement.

La troisième erreur est de traiter le choix comme définitif et de ne jamais documenter les raisons qui l'ont motivé. Quand la personne qui a pris la décision quitte l'équipe, plus personne ne sait pourquoi la boutique vit sur un sous-domaine ou pourquoi le blog est resté en sous-dossier, et chaque nouvelle décision d'architecture repart alors de zéro, sans mémoire des arbitrages précédents.