Choisir entre blog.example.com et example.com/blog suscite souvent des débats animés parmi les développeurs et les experts en SEO. La vérité est que les propres défenseurs de Google disent que l'une ou l'autre approche convient – "la recherche web est à l'aise avec l'utilisation de sous-domaines ou de sous-répertoires" – mais la structure du site affecte toujours l'exploration, l'analyse et la perception de votre contenu par les utilisateurs et les moteurs de recherche. Dans cet article, nous allons démystifier les idées reçues avec des exemples concrets : de la mise en place de sites multilingues aux tableaux de bord SaaS, des blogs aux catégories de commerce électronique et aux microsites spécifiques aux services. En chemin, nous découvrirons des insights issus des récentes mises à jour de l'algorithme de Google et partagerons des statistiques et des expériences SEO concrètes.
Ce que Google pense vraiment (Spoiler : c'est votre choix)
Les conseils de Google ont été constants : mettez le contenu dans des sous-dossiers ou des sous-domaines selon ce qui a du sens pour vous, pas à cause d'un avantage de classement. John Mueller de Google a souligné à plusieurs reprises que Google traite ces structures comme "à peu près équivalentes" pour le classement. En fait, il a dit qu'il "essaierait personnellement de garder les choses ensemble autant que possible" et d'utiliser des sous-domaines uniquement lorsque les sections sont vraiment distinctes. En d'autres termes, si vous n'avez pas de raison technique ou organisationnelle convaincante de diviser un site, plus simple est généralement mieux. Cela fait écho aux conseils antérieurs de Matt Cutts de Google : "Ils sont à peu près équivalents... choisissez celui qui est le plus facile" pour votre contenu et votre CMS.
Pour l'exploration et l'indexation, Google peut gérer les deux sans problème. Les robots d'exploration peuvent visiter et indexer des sous-dossiers ou des sous-domaines, bien que vous deviez noter que vous pourriez avoir besoin de propriétés distinctes dans Google Search Console pour chaque sous-domaine (plus de détails à ce sujet plus tard). En fin de compte : ne vous attendez pas à un coup de pouce magique de classement juste en choisissant des sous-domaines. Au lieu de cela, pensez à votre architecture : regrouper les pages liées sous un même domaine simplifie le maillage interne et l'analyse, tandis que les sections isolées (applications, campagnes, centres d'aide, etc.) peuvent vivre sur des sous-domaines si nécessaire.
Même les documents de SEO international de Google montrent que les deux approches sont des options valables. Par exemple, il recommande de donner à chaque langue sa propre URL (soit un sous-dossier, soit un sous-domaine) et de les marquer avec des balises hreflang. Google illustre explicitement cela avec des modèles comme de.example.com vs. example.com\/de\/, en listant les avantages et les inconvénients de chacun. En pratique, cela signifie que vous pouvez choisir des sous-dossiers ou des sous-domaines pour les langues et les régions — assurez-vous simplement d'utiliser des annotations hreflang appropriées afin que Google sache quelle version afficher à chaque utilisateur.
Multilingue & Ciblage géographique
Si votre site nécessite plusieurs langues ou des versions spécifiques à un pays, les deux structures peuvent fonctionner, mais chacune a ses nuances. Par exemple, le site Web de Nike utilise des sous-répertoires pour différents pays : nike.com/au/ (Australie), nike.com/gb/ (Royaume-Uni), nike.com/ca/ (Canada), etc. Google interprète ceux-ci comme faisant partie de la structure principale du site. À l'inverse, Wikipédia exécute chaque langue en tant que sous-domaine (par exemple, en.wikipedia.org, de.wikipedia.org, etc.), ce que Google peut également gérer comme des sites distincts.
L'essentiel est d'indiquer à Google ce qui est quoi. Utilisez des liens hreflang pour pointer vers chaque URL de version linguistique, qu'il s'agisse d'un sous-dossier ou d'un sous-domaine. Les propres documents multi-régionaux de Google énumèrent les avantages de chaque configuration : les sous-domaines (comme de.example.com) facilitent l'hébergement de régions sur différents serveurs ou le ciblage géographique séparé, tandis que les sous-répertoires (example.com/de/) simplifient l'hébergement (même serveur) et partagent l'autorité du domaine. En bref, la décision dépend souvent de votre technologie et de votre organisation. L'approche de Nike avec les dossiers montre comment une seule base de code peut facilement desservir plusieurs pays, tandis qu'une grande entreprise SaaS ou technologique pourrait préférer les sous-domaines pour des versions régionales véritablement indépendantes.
Produits SaaS, Applications et Tableaux de Bord
Pour les produits logiciels en tant que service (SaaS) ou les applications web, un modèle courant est un site marketing sur le domaine principal, une application ou un tableau de bord sur un sous-domaine. Les experts du secteur recommandent cette séparation : gardez votre page d'accueil et votre marketing de contenu sur example.com, et placez l'application connectée (ou "portail client") sur quelque chose comme app.example.com ou dashboard.example.com. Il y a des avantages concrets ici. D'une part, vous pouvez utiliser différentes piles technologiques ou serveurs : peut-être que votre site principal est un site statique ou un CMS, et votre application est une application React ou utilise OAuth. En isolant l'application sur un sous-domaine, vous pouvez appliquer un certificat SSL séparé ou des cookies basés sur le domaine sans toucher à la configuration du site principal.
Le guide d'architecture SaaS de Winderwind illustre bien le point : "Le site Web marketing doit être sur le domaine principal et séparé de l'application produit. L'application produit doit vivre sur son propre sous-domaine". Ils citent même des exemples réels : Stripe utilise dashboard.stripe.com, Xero utilise my.xero.com, GoCardless utilise manage.gocardless.com, et ainsi de suite. Séparer les bases de code a un autre avantage : vous pouvez mettre à jour le site marketing (par exemple, faire des tests A/B ou des changements rapides de copie) sans risquer de temps d'arrêt ou de régression dans l'application utilisateur critique.
Il existe d'autres scénarios de type service également : si votre site a un blog qui nécessite un CMS particulier, ou un centre d'aide sur un service tiers. Par exemple, Weglot note qu'une entreprise appelée Flodesk utilise help.flodesk.com pour sa base de connaissances (hébergée sur un centre d'aide externe), plutôt que flodesk.com/help. De même, si vos ressources de développement ou vos outils tiers ne s'intègrent pas facilement avec votre domaine principal, un sous-domaine peut héberger cette section sans friction.
Cependant, rappelez-vous que les sous-domaines doivent être traités indépendamment à certains égards. Vous devrez peut-être configurer des propriétés de Search Console (les outils pour webmasters de Google) distinctes pour chaque sous-domaine, et les analyses peuvent nécessiter un suivi inter-domaines pour relier les données. Si vous choisissez un sous-domaine pour votre application, assurez-vous de tout configurer correctement afin que le trafic circule correctement et que Google sache que les deux parties appartiennent à la même marque.
Blogs et sections de contenu
Les blogs, sections d'actualités et hubs de contenu sont l'un des cas d'utilisation les plus courants pour ce débat. Ici, les compromis SEO sont souvent au premier plan. De nombreux spécialistes du marketing de contenu préfèrent les sous-répertoires pour les blogs, car cela consolide la valeur SEO sous un seul domaine. En fait, des recherches et des études de cas suggèrent que le contenu dans des sous-dossiers tend à bénéficier aux classements du domaine principal. Weglot souligne que les moteurs de recherche traitent les sous-répertoires comme faisant partie de votre domaine principal, donc l'« Autorité de Domaine » que vous avez se transfère à ces pages.
Par exemple, si example.com a une autorité élevée, alors example.com/blog/hello-world hérite de cette force. Par conséquent, tous les backlinks vers vos articles de blog rehausseront également l'autorité du domaine racine.
Cette intuition est soutenue par des études de cas. Une entreprise a rapporté que son sous-domaine de blog "attirait du trafic" mais "ne bénéficiait pas à notre site principal" - c'était "comme si nous avions organisé une fête, mais que certains de nos invités s'amusaient dans une pièce séparée, tandis que la zone principale ne profitait pas pleinement de leur présence". En d'autres termes, leur site principal manquait le coup de pouce SEO. Ils ont constaté que migrer le blog vers example.com/blog était mieux aligné avec leurs objectifs (tout l'amour SEO restait sur le site principal). En général, les sous-dossiers tendent à s'intégrer de manière transparente : le blog semble faire partie de votre site, ce qui peut être plus facile pour la navigation et pour que les utilisateurs partagent des liens. Cela dit, certaines grandes entreprises utilisent encore des sous-domaines pour les blogs ou les sections de contenu sans catastrophe. Par exemple, HubSpot gère son blog sur blog.hubspot.com (et a d'autres sous-domaines comme ecosystem.hubspot.com pour différents contenus). Si votre blog ou centre de ressources est très grand ou nécessite une architecture séparée, un sous-domaine peut fonctionner. La position de Google ne vous pénalisera pas pour ce choix, mais vous devrez construire l'autorité de ce sous-domaine séparément.
Pour les sites e-commerce avec de nombreuses pages de catégories et de produits, la règle générale est de tout garder sous le domaine principal. Imaginez une boutique en ligne avec des catégories comme /electronics/phones ou /clothing/shirts ; il est généralement préférable de les placer sous example.com/category/.... Pourquoi ? Parce que tout le capital SEO (backlinks, liens internes, texte d'ancrage, etc.) reste sur le domaine de la marque. Comme le note SEMrush, "Google considère souvent les sous-domaines comme des entités distinctes, tandis que les sous-répertoires sont vus comme faisant partie du domaine principal". En pratique, cela signifie que tout lien vers example.com/shop/widget renforce toutes les pages sur example.com (y compris d'autres catégories), tandis qu'un lien vers shop.example.com renforcerait uniquement le site de ce sous-domaine.
La plupart des grands sites de vente au détail suivent ce modèle. Par exemple, Amazon, eBay et Walmart utilisent tous des sous-dossiers (comme amazon.com/books/, ebay.com/electronics/phone-accessories/, etc.) plutôt qu'un sous-domaine de shopping séparé. Lorsque les robots d'exploration et les algorithmes de Google évaluent les pages de catégories, ils intègrent cette valeur dans les métriques du domaine racine. Cette consolidation conduit souvent à une autorité de domaine plus forte au fil du temps. Cela dit, il existe des raisons légitimes pour lesquelles un site e-commerce pourrait utiliser un sous-domaine (par exemple, s'intégrer avec Shopify ou une autre plateforme). Si vous le faites, sachez simplement qu'il est traité comme un mini-site autonome. Toute autorité SEO que vous avez construite sur example.com ne se transfèrera pas automatiquement ; vous devrez obtenir des backlinks pour le sous-domaine séparément.
Parfois, une entreprise propose des services ou marques distinctement différents sous une même bannière, et elle peut décider de mettre en avant ces différences via des sous-domaines. Par exemple, Lego (le fabricant de jouets) gère un site de campagne spécial sur ideas.lego.com où les utilisateurs soumettent de nouvelles idées de produits. Ce sous-domaine marque clairement une initiative séparée de lego.com. De même, si votre site héberge plusieurs microsites pour des campagnes marketing ou des hubs communautaires, les mettre sur des sous-domaines peut aider à organiser les choses. Comme le dit Weglot, "si vous menez des campagnes de marketing digital qui nécessitent un branding et des pages de destination séparés, il pourrait être logique de les placer sous différents sous-domaines". Un autre exemple : si vos services sont très divers (disons, vous faites à la fois du design et de la construction), vous pourriez utiliser design.example.com et build.example.com pour que chacun ait son propre look et message. Techniquement, un sous-domaine est juste un hôte différent, donc vous pouvez le pointer vers sa propre base de code ou serveur. Mais souvenez-vous, cela signifie aussi que les moteurs de recherche traiteront chacun comme largement séparé. Dans ces cas, n'utilisez des sous-domaines que si vous souhaitez réellement des efforts de marketing séparés - sinon, vous risquez de diviser votre poids SEO.
Table de Décision : Sous-domaine vs Sous-répertoire
Considération
Sous-domaine (sub.example.com)
Sous-répertoire (example.com/sub/)
Autorité SEO
Site séparé. Les backlinks bénéficient principalement au classement du sous-domaine (ne booste pas le domaine principal). Nécessite de construire l'autorité pour chaque sous-domaine.
Site partagé. Les backlinks vers les sous-répertoires augmentent l'autorité de tout le domaine. Le PageRank circule sur l'ensemble du site.
Infrastructure
Indépendante. Peut utiliser un hébergement, CMS ou technologie différents pour chaque sous-domaine. Bon pour les microservices/apps.
Unifié. Tout le contenu sur un seul serveur/pile. Déploiement et maintenance plus simples, mais moins de flexibilité pour les technologies mixtes.
Configuration & Suivi
Plus complexe. Nécessite DNS et peut-être SSL pour chaque sous-domaine, suivi séparé dans Search Console et analytics (configuration inter-domaine).
Plus simple. Un seul certificat serveur, une propriété Search Console (avec sous-répertoires) et un code analytique unique pour tout couvrir.
Cas d'Utilisation
Applications, tableaux de bord, ou services entièrement séparés ou nécessitant des serveurs dédiés. Contenu multilingue/régional (chaque langue sur son propre hôte). Campagnes spéciales ou intégrations tierces (par ex. centre d'assistance à help.example.com).
Contenu intégré. Blog d'entreprise, sections d'actualités ou de ressources destinées à renforcer le SEO du site principal. Contenu principal du site (par ex. catégories de boutique, docs) devant bénéficier du domaine principal.
Flexibilité
Élevée. Peut déplacer le sous-domaine vers un nouvel hôte ou une nouvelle plateforme sans toucher au site principal.
Moindre. Tout le contenu est lié à l'hôte principal ; migrer des sections séparément est plus difficile.
Autorité de Domaine
Isolée. Le sous-domaine peut avoir son propre score “Autorité de Domaine” (dans les outils SEO) indépendant de la racine.
Unifiée. Une seule autorité de domaine pour tout ; les sous-répertoires partagent généralement les signaux SEO de la racine.
example.com/app/ (pages de l'application), example.com/jp/ (section pays), example.com/blog/ (blog d'entreprise).
Dans le duel sous-domaine vs sous-répertoire, le décideur ultime est généralement les besoins de votre projet, pas les algorithmes de Google. Comme le rappelle John Mueller de Google, “si vous êtes du genre ‘eh bien ça m'est égal', alors je garderais tout sur le même site”. En pratique, cela signifie que si tout votre contenu – blog, catégories, docs – est étroitement lié, le mettre sous un seul domaine (avec des sous-répertoires) maximisera généralement votre autorité SEO et simplifiera votre flux de travail. D'autre part, si vous avez une bonne raison technique ou organisationnelle – comme une application SaaS séparée, une campagne marketing distincte, ou un centre d'assistance sur une autre plateforme – un sous-domaine est parfaitement acceptable et ne vous pénalisera pas aux yeux de Google. Préparez-vous simplement à le gérer comme un “mini-site” distinct (avec son propre suivi et stratégie de liens). En résumé : aucune structure n'est intrinsèquement meilleure pour le SEO. Les algorithmes de Google ont évolué pour reconnaître et indexer les deux sans biais. Concentrez-vous sur la clarté, l'expérience utilisateur et la maintenance pratique. Pour la plupart des développeurs, l'approche recommandée est de commencer par des sous-répertoires pour la simplicité et la consolidation SEO, et de réserver les sous-domaines pour les cas bien définis où l'indépendance ou l'évolutivité est plus importante. Gardez vos objectifs à l'esprit, surveillez votre trafic et vos classements après tout changement, et itérez. Avec une planification réfléchie, vous pouvez faire fonctionner efficacement l'un ou l'autre choix pour votre site.