Faut-il vraiment préférer un sous-répertoire à un sous-domaine pour son microsite ?

Pourquoi Google prend-il position aussi clairement sur ce sujet ?

John Mueller ne fait généralement pas dans la recommandation binaire. Quand il tranche aussi nettement, c'est que la confusion sur le terrain est massive — et elle l'est. Pendant des années, les SEO ont débattu : sous-domaine ou sous-répertoire pour un blog d'entreprise, un espace presse, un site événementiel ?

La réponse de Mueller coupe court : pour un contenu lié au domaine principal, le sous-répertoire gagne. Pourquoi ? Parce que Google traite le sous-domaine comme une entité quasi-distincte dans son système de crawl et de classement. Chaque sous-domaine démarre avec un budget crawl propre, un profil de liens indépendant, et des signaux d'autorité séparés.

Qu'est-ce que ça change concrètement pour le PageRank et les signaux ?

En sous-répertoire, chaque lien externe obtenu par votre microsite renforce directement l'autorité du domaine racine. Le PageRank circule naturellement entre /blog et /produits via le maillage interne. C'est un atout massif si vous lancez un contenu éditorial pour booster la visibilité d'un site e-commerce jeune.

En sous-domaine, vous fragmentez vos signaux. Un lien vers blog.votresite.com ne profite pas mécaniquement à www.votresite.com. Google doit établir la relation entre les deux entités — et rien ne garantit qu'il le fasse efficacement. Résultat : vous diluez votre potentiel SEO au lieu de le concentrer.

Dans quels cas le sous-domaine reste-t-il pertinent alors ?

Mueller cite un exemple précis : forum vs site principal. Si votre microsite sert une fonction radicalement différente — forum communautaire, plateforme support, espace revendeurs — le sous-domaine se justifie. L'objectif n'est plus de mutualiser l'autorité, mais d'isoler un contenu dont la nature, les publics ou les objectifs divergent.

Autre cas d'usage : les sites multilingues ou multi-régionaux où le sous-domaine facilite la gestion technique (serveurs locaux, hreflang, ciblage géographique distinct). Mais attention : Google sait crawler et indexer des structures en /fr/ ou /en/ sans problème — le sous-domaine n'est pas une obligation.

• Sous-répertoire : Pour microsites thématiques, blogs, ressources, landing pages événementielles liées à l'activité principale
• Sous-domaine : Pour contenus fonctionnellement distincts (forum, support, marketplace tierce, app web séparée)
• Consolidation PageRank : Le sous-répertoire mutualise l'autorité ; le sous-domaine la fragmente
• Maintenance technique : Un seul CMS, un seul sitemap, une seule Search Console en sous-répertoire — vs gestion dupliquée en sous-domaine

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et massivement. Les tests A/B menés sur des migrations sous-domaine → sous-répertoire montrent des gains de trafic organique dans 70-80% des cas, surtout pour les sites jeunes ou moyennement autoritaires. La raison ? Le PageRank cesse d'être compartimenté. Le maillage interne devient efficace. Le crawl budget se concentre.

Mais — et c'est là que Mueller reste prudent — certains sous-domaines massifs et bien établis (ex : support.microsoft.com, developers.google.com) performent très bien. Pourquoi ? Parce qu'ils ont accumulé leur propre autorité au fil des années, avec des profils de liens indépendants. Migrer un tel sous-domaine en sous-répertoire serait risqué et coûteux pour un gain marginal.

Quelles nuances faut-il apporter à cette directive ?

Premier point : Mueller parle de microsites liés au contenu principal. Si votre microsite traite d'un sujet connexe mais avec un positionnement éditorial distinct, la question se complique. Exemple : une marque de cosmétiques qui lance un média lifestyle sous-domaine — l'objectif peut être justement de découpler l'image pour toucher une audience plus large sans diluer la marque produit.

Second point : la question des CMS et stacks techniques. Si votre site principal tourne sur un CMS propriétaire legacy et que votre microsite nécessite WordPress ou un stack moderne, le sous-domaine peut être un moindre mal technique. Mais attention : ce n'est qu'un pansement. À moyen terme, refondre l'architecture pour unifier en sous-répertoire reste préférable si le contenu est complémentaire.

Troisième nuance — et Mueller ne l'évoque pas : les risques de cannibalisation. En sous-répertoire, si votre microsite cible des mots-clés trop proches de vos pages principales sans stratégie de maillage claire, vous pouvez créer du conflit interne. Le sous-domaine isole ce risque. [A vérifier] : Google affirme savoir gérer la cannibalisation intra-domaine, mais les observations terrain montrent encore des flottements SERP sur des sites mal structurés.

Dans quels cas cette règle ne s'applique-t-elle franchement pas ?

Si vous gérez un réseau de marques ou un groupe avec des entités juridiques distinctes, chaque marque mérite son propre domaine racine — pas un sous-répertoire du site holding. Exemple : LVMH ne mettra jamais Louis Vuitton en lvmh.com/louisvuitton. Ici, le sous-domaine n'est même pas pertinent : c'est un domaine à part entière qui s'impose.

Autre exception : les campagnes temporaires à fort budget média. Lancer un site événementiel en sous-domaine permet de le tuer proprement après l'événement sans toucher à l'arborescence principale ni multiplier les redirections 301. Mais si l'événement est récurrent (ex : soldes annuels), mieux vaut un /soldes permanent en sous-répertoire.

Que faut-il faire concrètement si on lance un nouveau microsite aujourd'hui ?

Choisissez le sous-répertoire par défaut, sauf raison technique ou éditoriale impérieuse. Structurez l'URL dès le départ : /blog, /ressources, /evenements, /presse. Évitez les niveaux de profondeur inutiles : /fr/blog/articles/2024/janvier — préférez /blog/titre-article. Plus c'est plat, mieux c'est pour le crawl et le PageRank.

Si votre CMS actuel ne permet pas d'ajouter facilement un sous-répertoire (cas des plateformes SaaS rigides), challengez ce choix technique. Un CMS headless ou une architecture hybride (frontend Next.js + backend API) permet de gérer plusieurs sections sous un même domaine sans duplication d'infrastructure. C'est plus complexe, mais SEO-friendly dès la conception.

Quelles erreurs éviter absolument lors d'une migration sous-domaine → sous-répertoire ?

Erreur classique : migrer sans nettoyer le maillage interne. Si vos anciennes pages en sous-domaine contiennent des dizaines de liens internes vers d'autres pages du sous-domaine, et que vous redirigez tout en bloc, vous créez des chaînes de redirections. Résultat : dilution du PageRank et crawl ralenti.

Autre piège : oublier de mettre à jour les sitemaps et les canonical. Après migration, votre sitemap doit pointer vers les nouvelles URLs en sous-répertoire, et chaque page doit avoir un canonical propre. Si Google trouve encore des canonicals pointant vers l'ancien sous-domaine, il va hésiter — et vous perdrez du temps d'indexation.

Troisième erreur : ne pas surveiller la Search Console après migration. Configurez une propriété distincte pour le sous-répertoire si besoin, ou filtrez les rapports pour isoler les URLs migrées. Surveillez les erreurs 4xx, les soft 404, les pages indexées mais non soumises. Une migration propre prend 4 à 8 semaines pour stabilisation complète — ne lâchez pas avant.

Comment vérifier que la structure actuelle de mon site est optimale ?

Faites un crawl Screaming Frog ou Oncrawl de votre domaine principal et de vos sous-domaines. Exportez les URLs indexées via Search Console. Comparez les volumes de pages, les profils de liens (Ahrefs, Majestic), et les performances de trafic (GA4). Si un sous-domaine capte moins de 10% du trafic du domaine principal et traite d'un sujet complémentaire, il est candidat à la migration.

Analysez aussi le maillage interne : combien de liens relient le sous-domaine au domaine principal ? Si c'est moins de 5-10 liens stratégiques, vous avez déjà un problème de cloisonnement. Le sous-répertoire résoudra ça mécaniquement, mais il faudra ensuite optimiser le maillage pour faire circuler le PageRank efficacement.

• Privilégier le sous-répertoire pour tout microsite lié au contenu principal (blog, ressources, événementiel)
• Réserver le sous-domaine aux contenus fonctionnellement distincts (forum, support, app web séparée)
• Planifier les redirections 301 en mappant chaque URL sous-domaine vers son équivalent sous-répertoire
• Nettoyer le maillage interne avant migration pour éviter les chaînes de redirections
• Mettre à jour sitemap, canonicals, hreflang et robots.txt après migration
• Surveiller Search Console et Analytics pendant 6-8 semaines post-migration pour détecter toute anomalie