Sous-domaine ou sous-répertoire

En bref — Un sous-domaine est une adresse comme blog.example.com : un préfixe placé avant le domaine. Un sous-répertoire (ou sous-dossier) est un chemin comme example.com/blog/. On entend souvent que les sous-répertoires seraient « meilleurs pour le SEO ». Ce n’est pas intrinsèquement vrai : Google indique que les deux solutions peuvent fonctionner. Les sous-répertoires sont souvent plus simples à exploiter dans une même application et un même périmètre analytique. À défaut d’une vraie raison de séparer les éléments, les garder ensemble reste donc le choix le plus simple.

Quelle est la différence ?

Tout dépend de l’endroit où se place le mot supplémentaire par rapport au domaine :

• Sous-domaine — le mot précède le domaine et en est séparé par un point : blog.example.com, shop.example.com, support.example.com. Il s’agit techniquement d’une adresse distincte ; elle peut donc être hébergée sur un autre serveur ou exploiter un autre système de gestion de contenu (CMS).
• Sous-répertoire (aussi appelé sous-dossier) — le mot suit le domaine et en est séparé par une barre oblique : example.com/blog/, example.com/shop/. Il reste toujours rattaché à la même adresse que le site principal.

Est-ce important pour le SEO ?

Voici la réponse franche que la plupart des articles ne donnent pas : beaucoup moins qu’on ne le prétend. Google répète depuis des années qu’il n’a aucune préférence. Les deux configurations peuvent très bien fonctionner.

Si vous voyez des titres comme « nous avons déplacé notre blog vers un sous-répertoire et le trafic a bondi de 40 % », c’est parce que ces migrations se font rarement seules. Une équipe en profite généralement pour améliorer aussi les liens internes, supprimer les pages faibles et moderniser la plateforme. Ce sont ces changements simultanés qui font évoluer le trafic ; la structure des URL ne fait le plus souvent qu’accompagner le mouvement. J’examine ce point plus en détail dans l’onglet Avancé.

Alors, que choisir ?

Une règle simple :

• Utilisez un sous-répertoire pour les éléments étroitement liés au site principal — blog, centre d’aide ou documentation. Le routage, les mesures d’audience et la gestion du contenu restent réunis. Une propriété Domaine dans Search Console peut aussi agréger les sous-domaines ; le nombre de propriétés n’est donc pas le critère décisif.
• Utilisez un sous-domaine quand l’élément est réellement distinct — produit, équipe ou serveur séparé, ou versions nationales du site. Un sous-domaine n’a rien de problématique ; sa gestion demande simplement un peu plus de configuration.

L’erreur la plus fréquente

Ne migrez pas un sous-domaine qui fonctionne vers un sous-répertoire simplement parce qu’on vous affirme que les sous-dossiers se classent mieux. Si votre blog en sous-domaine obtient de bons résultats et reçoit de bons liens depuis le site principal, le déplacement apporte beaucoup de risques pour peu de bénéfices. Toute migration peut faire perdre des positions pendant la transition. Pour le raisonnement complet, les études de cas et les déclarations de Google et Bing, passez à l’onglet Avancé.

En bref — Sous-domaines et sous-répertoires sont tous deux viables pour la recherche, mais ils diffèrent sur le plan opérationnel. Google détermine site par site si un sous-domaine fait partie du site principal ou constitue une entité distincte. Le facteur décisif est l’intégration — liens internes, expérience cohérente et contenu associé —, non le point ou la barre oblique. Les études de cas qui attribuent de forts gains à un passage du sous-domaine au sous-répertoire sont presque toujours faussées par d’autres changements : meilleur maillage interne, suppression de contenus faibles, mise à niveau du CMS ou correction du suivi analytique. Ma position : ne migrez pas pour la seule structure des URL ; le risque dépasse généralement le bénéfice. Les sous-répertoires peuvent simplifier le routage, l’analytique et la publication, mais ce sont des avantages pratiques, pas un levier de classement. Bing vise l’abus de sous-domaines — location de répertoires, PBN — et non leur usage légitime. Enfin, selon la politique de Google de novembre 2024 sur l’abus de réputation d’un site, déplacer un contenu d’une structure à l’autre ne corrige pas une infraction aux règles antispam.

Ce que sont réellement ces structures

Un sous-domaine est un préfixe placé avant le domaine racine et séparé par un point — blog.example.com. Comme il s’agit techniquement d’un nom d’hôte distinct, il peut pointer vers un autre serveur, utiliser un autre CMS et appartenir à une autre équipe. Un sous-répertoire (ou sous-dossier) est un segment de chemin placé après le domaine et séparé par une barre oblique — example.com/blog/. Il conserve toujours le même nom d’hôte et relève donc du même « site » du point de vue de l’exploration et de l’analytique. Pour l’international, il existe une troisième option : un ccTLD comme example.de, toujours traité comme un site distinct.

Ce que dit réellement Google — et ce que cela implique

La documentation officielle de Google est sans ambiguïté : “You should choose whatever is easiest for you to organize and manage. From an indexing and ranking perspective, Google doesn’t have a preference.” (traduction) « Vous devez choisir ce qui est le plus simple à organiser et à gérer. Du point de vue de l’indexation et du classement, Google n’a pas de préférence. » Voilà l’idée principale : aucune des deux structures ne bénéficie d’un avantage général.

La nuance importe davantage. John Mueller a déclaré : “In general, we see these the same,” (traduction) « En général, nous les considérons de la même manière. » tout en ajoutant qu’il essaierait “personally try to keep things together as much as possible.” (traduction) « personnellement de garder les éléments aussi regroupés que possible. » Le mot clé est personnellement : c’est une préférence de simplicité opérationnelle, pas l’affirmation que les sous-répertoires se classent mieux.

Le point le plus profond formulé par Mueller est précisément l’absence de règle générale : “sometimes that can include sub-domains, sometimes that doesn’t include sub-domains. Sometimes that includes sub-directories, and sometimes that doesn’t include specific sub-directories.” (traduction) « parfois cela peut inclure des sous-domaines, parfois non. Parfois cela inclut des sous-répertoires, et parfois certains sous-répertoires ne sont pas inclus. » Autrement dit, Google décide site par site si un sous-domaine — voire un sous-répertoire — fait partie du site principal. Il s’appuie sur des signaux d’intégration : liens internes entre la section et la racine, identité visuelle et expérience cohérentes, proximité thématique du contenu et structure logique des sitemaps.

Gary Illyes a confirmé l’inverse à Pubcon 2023 : des sous-répertoires peuvent eux aussi être traités comme des sites séparés — “It’s not common on the English web but it is in other languages.” (traduction) « Ce n’est pas courant sur le Web anglophone, mais cela arrive dans d’autres langues. » Le véritable levier n’est donc pas la structure, mais l’intégration.

Ma position : les « gains » sont généralement faussés

J’ai défendu cette position à contre-courant pour Ahrefs en mars 2021, et elle reste valable. L’idée selon laquelle les sous-répertoires seraient supérieurs pour le SEO repose sur des études de cas où une section passe d’un sous-domaine à un sous-dossier avant d’enregistrer une hausse de trafic. Le problème : ces migrations ne modifient presque jamais uniquement l’URL.

Lors de ces déplacements, les équipes ont généralement aussi tendance à :

• améliorer le maillage interne — la section rejoint enfin correctement la navigation principale et les liens contextuels ;
• supprimer ou réécrire les contenus faibles dans le cadre de la migration ;
• moderniser le CMS ou la plateforme, ce qui améliore souvent la vitesse, les modèles et l’explorabilité ;
• corriger l’analytique, si bien qu’un trafic déjà présent est enfin mesuré dans une seule propriété — les lacunes de suivi entre domaines ou noms d’hôte sont fréquentes avec les sous-domaines.

Chacun de ces changements peut faire progresser le trafic. Attribuer tout le gain au remplacement d’un point par une barre oblique revient à confondre corrélation et causalité. Comme je l’écrivais dans cet article, tout changement introduit un risque : réfléchissez à deux fois avant de passer d’un sous-domaine à un sous-répertoire si votre seule raison est le SEO.

Cela ne signifie pas qu’aucune étude de cas n’isole la structure. Pink Cake Box est la plus propre que je connaisse : les vérifications dans Archive.org ne montrent aucun changement de conception ou de contenu en parallèle, tandis que les sessions organiques ont progressé d’environ 40 %. Le test inverse d’IWantMyName, passé d’un sous-répertoire à un sous-domaine avec une baisse d’environ 47 %, renforce ce constat. Je prends ces cas au sérieux. Ils restent cependant des exceptions mesurées proprement. Les cas de type HotPads ou HubSpot, souvent cités, comportaient des changements simultanés, ce que leurs responsables — notamment John Doherty pour HotPads — ont eux-mêmes reconnu. Les études de corrélation portant sur « 11,8 millions de résultats » et autres ensembles similaires restent, par nature, corrélationnelles : les sites organisés en sous-répertoires sont aussi souvent plus grands et plus mûrs en SEO.

Les vraies différences techniques — ce ne sont pas des mythes

Laissons de côté le débat sur le classement : il existe bel et bien des différences opérationnelles concrètes, qui favorisent souvent les sous-répertoires pour les contenus étroitement liés :

• Search Console. Un sous-domaine demande une validation séparée et sa propre propriété. Une propriété Domaine de GSC couvre toutefois tous les sous-domaines à la fois, ce qui atténue cette contrainte. Mueller : “We do have to learn how to crawl them separately but for the most part that’s just a formality for the first few days.” (traduction) « Nous devons apprendre à les explorer séparément, mais il ne s’agit pour l’essentiel que d’une formalité pendant les premiers jours. »
• Exploration. Avec un sous-répertoire, Googlebot sait déjà qu’il s’agit du même serveur ; aucune période de réapprentissage n’est nécessaire. Mueller formule ainsi cet avantage : “this helps us with crawling since we understand that everything is on the same server and can crawl it in a similar way.” (traduction) « cela nous aide pour l’exploration, car nous comprenons que tout se trouve sur le même serveur et pouvons l’explorer de manière similaire. »
• Analytique. Une seule propriété GA4 suffit par défaut, sans configuration interdomaines ou interhôtes pour mesurer le trafic de la section.
• Noms de site dans les résultats de recherche. Google accepte les noms de site pour les domaines et les sous-domaines, mais pas pour les sous-répertoires : c’est une véritable différence fonctionnelle documentée.
• Sources préférées et outils au niveau de la propriété. Certaines surfaces de Search Console fonctionnent au niveau du domaine ou du sous-domaine, pas du sous-répertoire.
• Popularité des liens. Les backlinks vers un sous-répertoire appartiennent sans ambiguïté au domaine racine. Pour un sous-domaine, la transmission de cette popularité vers la racine dépend de la manière dont Google l’intègre au site — toujours la même évaluation site par site.

Quand un sous-domaine est réellement pertinent

Les sous-domaines ne sont pas une erreur. Choisissez-en un lorsque :

• le produit ou service est réellement distinct — app.example.com, status.example.com, community.example.com ;
• une séparation technique est nécessaire — autre CMS, autre pile technologique, autre équipe ou infrastructure beaucoup plus simple à exploiter sur son propre nom d’hôte ;
• vous ciblez plusieurs pays — Google considère les sous-domaines (de.example.com), les sous-répertoires (example.com/de/) et les ccTLD (example.de) comme des options tout aussi valables pour le ciblage géographique. Les sous-répertoires sont les plus simples à gérer, les ccTLD envoient le signal géographique le plus fort et les sous-domaines se situent entre les deux ;
• une grande entreprise compte plusieurs divisions, et des propriétés GSC séparées par équipe constituent un avantage plutôt qu’un défaut.

Ce qui préoccupe Bing

Bing ne prescrit aucune structure aux sites légitimes. Dans “Some Thoughts on Website Boundaries” — « Quelques réflexions sur les limites d’un site » — (Frederic Dubut et l’équipe Bing Webmaster Tools, novembre 2019), sa préoccupation porte sur la structure de site artificielle : PBN, pages satellites et location de sous-domaines ou de sous-dossiers, où le contenu d’un tiers est accroché à un sous-domaine avec très peu de liens internes pour détourner les signaux du site au profit d’une entité sans rapport. L’avertissement de Bing est direct : “If you offer free hosting on your subdomains and 95% of your subdomains are flagged as spam, Bing will expand penalties to the entire domain, even if the root website itself is not spam.” (traduction) « Si vous proposez un hébergement gratuit sur vos sous-domaines et que 95 % d’entre eux sont signalés comme spam, Bing étendra les sanctions à l’ensemble du domaine, même si le site racine n’est pas lui-même indésirable. » Une entreprise normale qui utilise son propre sous-domaine n’est pas concernée.

Ce point rejoint la mise à jour de novembre 2024 de la politique de Google sur l’abus de réputation d’un site : “Moving content to a subdirectory or subdomain within the same site’s domain name doesn’t resolve the underlying issue and may be viewed as an attempt to circumvent spam policy.” (traduction) « Déplacer un contenu vers un sous-répertoire ou un sous-domaine au sein du même nom de domaine ne résout pas le problème sous-jacent et peut être considéré comme une tentative de contournement des règles antispam. » Aucune structure d’URL ne permet donc d’échapper à un problème de parasite SEO.

La solution du proxy inverse

Si une contrainte technique vous impose un sous-domaine — WordPress.com, CMS headless ou plateforme de documentation ou d’assistance impossible à auto-héberger — vous n’avez pas besoin d’une migration complète pour obtenir une URL en sous-répertoire. Un proxy inverse, couramment réalisé avec Cloudflare Workers, peut servir blog.example.com comme example.com/blog/ du point de vue du robot et de l’utilisateur. Tout le monde voit l’URL en sous-répertoire, tandis que le backend reste installé sur le sous-domaine. Cloudflare documente ce montage dans une série Workers en deux parties. Cette technique est légitime et largement utilisée ; vérifiez simplement que le contenu relayé vous appartient réellement et n’est pas loué à un tiers.

Faut-il migrer ? Évaluer le risque

Ma règle de décision :

• Ne changez rien si votre sous-domaine est établi, bien classé, correctement lié depuis la racine et bien intégré. Migrer pour la seule structure des URL apporte beaucoup de risques pour peu de bénéfices.
• Migrez si vous réalisez de toute façon une migration de plateforme plus vaste, ou si le sous-domaine souffre de véritables problèmes techniques ou de performance — autrement dit, lorsque le changement d’URL s’accompagne de corrections qui ont réellement un effet.
• Si vous migrez, corrigez d’abord les facteurs de confusion pour interpréter proprement le résultat : maillage interne, qualité du contenu, redirections 301 et analytique. Le changement de structure sera alors la seule variable.
• Suivez le processus officiel de Google pour les migrations de site : faites correspondre les anciennes URL aux nouvelles, redirigez-les toutes, mettez à jour les liens internes et les sitemaps, validez la nouvelle propriété dans Search Console, puis suivez un échantillon représentatif d’URL au lieu de supposer que tout s’est bien passé.

Prévoyez deux à quatre semaines de fluctuations pendant le traitement des redirections par Google. Lorsque la migration est correctement exécutée, le retour à la normale intervient généralement en quatre à six semaines.

Place de ce sujet dans l’ensemble

Ce choix n’est qu’un aspect de l’organisation d’un site. Les autres articles de ce groupe abordent les conventions de structure d’URL, l’architecture du site et la profondeur d’exploration, ainsi que la navigation à facettes. La dimension internationale recoupe les décisions relatives à hreflang et aux ccTLD dans le SEO international. Le principe commun reste le même : la structure sert à organiser et gérer le contenu ; elle ne constitue pas à elle seule un levier de classement.

Synthèse par IA

Version condensée de l’onglet Avancé :

• Sous-domaine = blog.example.com (nom d’hôte distinct). Sous-répertoire = example.com/blog/ (chemin du même nom d’hôte). ccTLD = example.de (toujours un site distinct).
• Google n’a aucune préférence générale. Sa documentation recommande de choisir la structure la plus facile à gérer et ne privilégie aucune option pour l’indexation ou le classement.
• Le traitement se décide site par site. Selon Mueller, un sous-domaine peut faire partie du site ou non, et il en va de même pour les sous-répertoires. Le facteur déterminant est l’intégration — liens internes, expérience cohérente et contenu associé —, pas le point ou la barre oblique. Illyes a confirmé que des sous-répertoires peuvent aussi être traités séparément.
• Position de Patrick : les « gains » de migration sont généralement faussés par l’amélioration du maillage interne, la suppression de contenus faibles, une mise à niveau du CMS ou la correction de l’analytique. Ne migrez pas pour la seule structure des URL ; le risque dépasse le bénéfice.
• Études de cas les plus propres : Pink Cake Box (environ +40 %, sans autre changement) et le déplacement inverse d’IWantMyName (environ −47 %). La plupart des autres cas cités comportaient des changements simultanés.
• Différences réelles, sans effet direct sur le classement : les sous-domaines demandent une validation GSC séparée ; les noms de site dans la recherche fonctionnent pour les sous-domaines, pas pour les sous-répertoires ; ces derniers évitent une phase de réapprentissage de l’exploration et utilisent une seule propriété analytique.
• Bing vise l’abus de sous-domaines — location, PBN —, pas leur usage légitime.
• Abus de réputation d’un site, novembre 2024 : déplacer un contenu d’un sous-domaine à un sous-répertoire, ou l’inverse, ne corrige pas une infraction aux règles antispam.
• Un proxy inverse, par exemple avec Cloudflare Workers, peut présenter un sous-domaine sous une URL en sous-répertoire lorsqu’une contrainte technique impose de conserver le backend sur le sous-domaine.

Documentation officielle

Documentation de première main publiée par les moteurs de recherche.

Google

• Bonnes pratiques pour la structure des URL — conseils de Google sur les URL ; les ccTLD ou sous-répertoires sont recommandés pour le ciblage géographique, sans préférence déclarée pour le contenu national.
• Gérer les sites multirégionaux et multilingues — les trois options d’URL valides pour le ciblage international — ccTLD, sous-domaine et sous-répertoire — avec leurs avantages et inconvénients.
• Noms de site dans la recherche Google — les noms de site sont pris en charge pour les domaines et les sous-domaines, pas pour les sous-répertoires.
• Regrouper les URL en double — méthodes de canonisation — redirections, rel="canonical", sitemaps — utiles lors d’une migration entre structures.
• Migration de site avec modification des URL — processus officiel de Google pour une migration de structure d’URL : correspondances, redirections, validation dans Search Console et suivi.
• Politique sur l’abus de réputation d’un site — novembre 2024 — déplacer un contenu entre sous-répertoire et sous-domaine ne corrige pas une infraction aux règles antispam.
• Sous-domaines et sous-répertoires — janvier 2008 — le plus ancien article officiel de Google sur le sujet.

Bing / Microsoft

• Some Thoughts on Website Boundaries — Frederic Dubut et l’équipe Bing Webmaster Tools présentent les modèles domaine unique, sous-domaine et sous-répertoire, ainsi que la sanction visant les « structures de site artificielles » — PBN, pages satellites, location de sous-domaines.
• Consignes Bing pour les webmasters — consignes générales, sans préférence imposée entre les structures pour les sites ordinaires.

Citations des sources

Déclarations publiques de Google et Bing. Lorsque la page source le permet, le lien profond mène directement au passage cité.

Google — aucune préférence

• “You should choose whatever is easiest for you to organize and manage. From an indexing and ranking perspective, Google doesn’t have a preference.” (traduction) « Vous devez choisir ce qui est le plus simple à organiser et à gérer. Du point de vue de l’indexation et du classement, Google n’a pas de préférence. » — documentation Google Search Central.

John Mueller, Google (Office Hours Hangout du 25 mai 2018, rapporté par Search Engine Journal)

• “In general, we see these the same. I would personally try to keep things together as much as possible.” (traduction) « En général, nous les considérons de la même manière. Personnellement, j’essaierais de garder les éléments aussi regroupés que possible. » Compte rendu
• “So if it’s the same site then try to put them on the same site, essentially, and use subdomains where things are really kind of slightly different.” (traduction) « S’il s’agit du même site, essayez donc, en substance, de tout placer sur le même site et utilisez des sous-domaines lorsque les éléments sont réellement un peu différents. » Compte rendu
• “There are lots of really strong opinions on this so, from my point of view, this is something that could go either way.” (traduction) « Les avis sont très tranchés sur ce sujet ; de mon point de vue, les deux solutions peuvent convenir. » Compte rendu

John Mueller, Google (sur le traitement site par site)

• “sometimes that can include sub-domains, sometimes that doesn’t include sub-domains. Sometimes that includes sub-directories, and sometimes that doesn’t include specific sub-directories.” (traduction) « Parfois cela peut inclure des sous-domaines, parfois non. Parfois cela inclut des sous-répertoires, et parfois certains sous-répertoires ne sont pas inclus. »

John Mueller, Google (sur l’exploration et Search Console, via Search Engine Journal)

• “this helps us with crawling since we understand that everything is on the same server and can crawl it in a similar way. Sometimes, it also makes it easier for users who recognize that these sections are all a part of the same bigger website.” (traduction) « Cela nous aide pour l’exploration, car nous comprenons que tout se trouve sur le même serveur et pouvons l’explorer de manière similaire. Cela facilite aussi parfois la compréhension des utilisateurs, qui reconnaissent que ces sections font toutes partie du même site plus vaste. » Compte rendu
• “You’ll need to verify subdomains separately in Search Console… We do have to learn how to crawl them separately but for the most part that’s just a formality for the first few days.” (traduction) « Vous devrez valider les sous-domaines séparément dans Search Console… Nous devons apprendre à les explorer séparément, mais il ne s’agit pour l’essentiel que d’une formalité pendant les premiers jours. » Compte rendu

Gary Illyes, Google (Pubcon 2023, à propos du traitement séparé possible des sous-répertoires, cité dans mon article Ahrefs)

• “Yes. It’s not common on the English web but it is in other languages.” (traduction) « Oui. Ce n’est pas courant sur le Web anglophone, mais cela arrive dans d’autres langues. » Source

Matt Cutts, Google (ancien responsable de l’équipe antispam)

• “They are roughly the equivalent. I would basically go with whichever is easier for you in terms of configuration, your CMSs.” (traduction) « Les deux solutions sont à peu près équivalentes. Je choisirais essentiellement celle qui est la plus simple pour vous en matière de configuration et de CMS. » (2013)

Google — abus de réputation d’un site (mise à jour de la politique en novembre 2024)

• “Moving content to a subdirectory or subdomain within the same site’s domain name doesn’t resolve the underlying issue and may be viewed as an attempt to circumvent spam policy.” (traduction) « Déplacer un contenu vers un sous-répertoire ou un sous-domaine au sein du même nom de domaine ne résout pas le problème sous-jacent et peut être considéré comme une tentative de contournement des règles antispam. » Accéder à la citation

Bing — structure de site artificielle (Frederic Dubut et l’équipe Bing Webmaster Tools, 4 novembre 2019)

• “If you offer free hosting on your subdomains and 95% of your subdomains are flagged as spam, Bing will expand penalties to the entire domain, even if the root website itself is not spam.” (traduction) « Si vous proposez un hébergement gratuit sur vos sous-domaines et que 95 % d’entre eux sont signalés comme spam, Bing étendra les sanctions à l’ensemble du domaine, même si le site racine n’est pas lui-même indésirable. » Accéder à la citation

Choisir — ou migrer — une structure : checklist

Décider où placer une nouvelle section

• Le contenu est-il étroitement lié au site principal — blog, documentation, centre d’aide ? → privilégiez un sous-répertoire.
• Nécessite-t-il un CMS, un serveur, une équipe ou une pile technologique distincts ? → un sous-domaine est raisonnable.
• S’agit-il d’un produit ou service réellement distinct — app., status. ? → choisissez un sous-domaine.
• Ciblez-vous plusieurs pays ? → sous-répertoire, sous-domaine et ccTLD sont tous valables ; tranchez selon le coût opérationnel et la force du signal géographique.
• Avez-vous besoin d’un nom de site dans les résultats de recherche pour cette section ? → seuls les sous-domaines sont éligibles, pas les sous-répertoires.

Avant de migrer d’un sous-domaine vers un sous-répertoire — seulement pour une vraie raison

• Vérifiez que le déplacement n’est pas motivé uniquement par le SEO ; si c’est le cas, reconsidérez-le.
• Corrigez d’abord le maillage interne, la qualité du contenu et l’analytique afin d’interpréter proprement le résultat sans fausser le test.
• Faites correspondre chaque ancienne URL à son nouveau chemin et configurez des redirections 301.
• Mettez à jour les liens internes, les sitemaps et les balises canoniques avec les nouveaux chemins.
• Validez la nouvelle structure dans Search Console, ou utilisez une propriété Domaine.
• Ne migrez pas pour échapper à un problème d’abus de réputation du site : cela ne le corrigera pas.
• Prévoyez deux à quatre semaines de fluctuations ; suivez les positions et les statistiques d’exploration jusqu’au retour à la normale, généralement en quatre à six semaines.

Si une contrainte vous impose un sous-domaine

• Envisagez un proxy inverse, par exemple Cloudflare Workers, pour le servir sous une URL en sous-répertoire plutôt que d’effectuer une migration complète.
• Assurez-vous que le contenu relayé vous appartient réellement et n’est pas loué à un tiers.

Modèles mentaux

1. La structure organise ; elle ne constitue pas un levier de classement. Le choix entre point et barre oblique détermine la manière dont vous organisez et gérez le contenu. Google n’a aucune préférence générale. Commencez toute discussion par ce constat : il élimine 90 % des mauvais conseils.

2. Le traitement se décide site par site, selon l’intégration. Google détermine pour chaque site si un sous-domaine en fait partie ou constitue une entité séparée. Les signaux portent sur l’intégration : liens internes, expérience cohérente, contenu associé et sitemaps logiques. Un sous-domaine bien intégré se comporte comme une partie du site ; un sous-répertoire mal intégré peut se comporter comme un site distinct. Optimisez l’intégration, pas l’URL.

3. Le test des facteurs de confusion. Avant de croire un récit du type « nous avons migré et le trafic a bondi », demandez-vous : qu’est-ce qui a changé d’autre ? Liens internes, contenu supprimé, nouveau CMS, analytique corrigée : si l’un de ces éléments évolue en même temps, le gain ne peut pas être attribué à la structure des URL. Les seuls tests propres sont ceux où rien d’autre n’a changé, comme Pink Cake Box.

4. Commodité ou capacité. Les sous-répertoires l’emportent sur la commodité — une propriété GSC, une configuration analytique, aucun réapprentissage de l’exploration. Les sous-domaines l’emportent sur la capacité — piles, équipes et serveurs distincts, noms de site dans la recherche, séparation nette de produits différents. Identifiez l’axe qui correspond réellement à votre situation.

5. La règle du risque de migration. Migrez uniquement lorsque le changement d’URL s’accompagne d’améliorations qui ont réellement un effet, ou lorsqu’un vrai problème technique l’exige. Un sous-domaine fonctionnel et bien intégré

• « les sous-dossiers se classent mieux » ne justifie aucune migration : ce serait un risque sans contrepartie.

Cette section doit-elle utiliser un sous-domaine ou un sous-répertoire ?

Les décisions de structure qui confondent cause et effet

Migrer uniquement parce que les sous-répertoires seraient mieux classés

Google n’exprime aucune préférence générale de classement. Conservez une section saine et bien intégrée là où elle se trouve, sauf si un véritable besoin de plateforme, de produit ou d’exploitation justifie le risque de modifier toutes les URL.

Modifier simultanément les URL, le CMS, le contenu, les liens et l’analytique

Une mise en production groupée rend le résultat impossible à attribuer. Corrigez d’abord les problèmes connus de contenu et de liens, documentez la situation initiale et isolez les changements lorsque c’est possible.

Traiter un sous-domaine comme s’il n’avait aucun rapport dans la navigation du site

Une séparation technique n’impose pas d’isoler les utilisateurs ni les liens. Ajoutez à tout sous-domaine légitime des liens contextuels et de navigation clairs, afin que sa relation avec le site principal soit compréhensible.

Vérifier un échantillon de migration en ligne de commande

Placez une ancienne URL de sous-domaine par ligne dans old-urls.txt, puis inspectez la première réponse et sa destination sous macOS ou Linux :

while IFS= read -r url; do printf '%s\t' "$url"; curl -sS -o /dev/null -w '%{http_code}\t%{redirect_url}\n' "$url"; done < old-urls.txt

Équivalent PowerShell :

Get-Content old-urls.txt | ForEach-Object { try { $r = Invoke-WebRequest -Uri $_ -MaximumRedirection 0 -SkipHttpErrorCheck; [pscustomobject]@{Url=$_; Status=$r.StatusCode; Location=$r.Headers.Location} } catch { [pscustomobject]@{Url=$_; Error=$_.Exception.Message} } }

Le premier saut doit être une redirection permanente vers l’URL exacte du sous-répertoire correspondant, et non vers la page d’accueil ou une chaîne de redirections. Exécutez une exploration complète et examinez la migration avant de considérer un simple échantillon comme une preuve suffisante.

Outils pour choisir une structure et gérer une migration

• SEO Migration Planner & Validator — construisez et examinez la correspondance entre anciennes et nouvelles URL, vérifiez les redirections déployées et comparez les sitemaps lorsqu’un déplacement est réellement justifié.
• Redirect Chain Mapper — vérifiez qu’une ancienne URL de sous-domaine atteint l’URL correspondante du sous-répertoire en un seul saut propre.
• Google Search Console — utilisez une propriété Domaine pour obtenir une vue d’ensemble, et des propriétés propres à chaque nom d’hôte lorsque les équipes ont besoin de rapports opérationnels séparés.
• Un robot d’exploration de liens — comparez la navigation, les liens entrants internes, les balises canoniques et la profondeur d’exploration avant et après le changement, afin de ne pas confondre une meilleure intégration avec un avantage du format d’URL.

Testez vos connaissances : sous-domaine ou sous-répertoire

Cinq questions rapides sur les véritables différences SEO entre sous-domaines et sous-répertoires. Choisissez une réponse à chaque question, puis vérifiez-la.

Des ressources qui méritent votre attention

Mes articles associés

• Sous-domaine ou sous-répertoire : les sous-répertoires ne sont pas meilleurs pour le SEO — mon argumentaire complet à contre-courant, avec les citations de Mueller et Illyes, les facteurs qui faussent les études de cas et les raisons de réfléchir à deux fois avant une migration motivée uniquement par la structure des URL.
• Guide d’initiation au SEO technique — la place des décisions de structure du site dans une démarche plus large.

Mes conférences

• Fonctionnement de la recherche (SlideShare) — ma présentation sur l’exploration, le rendu, l’indexation et le classement, utile pour comprendre pourquoi l’« intégration » compte davantage que l’URL. L’avertissement habituel s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Voici ma compréhension de ces systèmes… elle ne sera pas entièrement exhaustive ni exacte. »

Ressources du secteur

• John Mueller de Google : quand utiliser un sous-domaine ou un répertoire ? (Search Engine Journal, Matt G. Southern) — les citations de la permanence de mai 2018 dans leur contexte.
• Sous-domaines ou sous-dossiers : lequel est meilleur pour le SEO, et pourquoi ? (Search Engine Journal, Roger Montti) — Mueller sur l’exploration et le traitement dans Search Console.
• Quelques réflexions sur les limites d’un site (Bing, Frederic Dubut) — les modèles de limites d’un site selon Bing et la sanction des structures artificielles.
• Passer d’un sous-domaine à un sous-dossier améliore-t-il le SEO ? Études de cas et avis d’experts (cognitiveSEO) — la meilleure synthèse d’études de cas, transparente sur les facteurs de confusion.
• Sous-répertoires ou sous-domaines : lequel est meilleur pour le SEO ? (Portent) — une méthodologie solide et la validation du cas Pink Cake Box dans Archive.org.
• Étude sur les sous-domaines et les sous-répertoires : 20 000 mots-clés analysés (SE Ranking) — une étude corrélationnelle transparente portant sur 15 marchés et 1,5 million de positions dans les SERP.
• Bonnes pratiques SEO avec Cloudflare Workers, partie 1 : sous-domaine ou sous-répertoire (Cloudflare) — explication de la solution du proxy inverse, avec un guide de mise en œuvre dans une deuxième partie.

Journal des modifications