Faut-il privilégier un sous-domaine ou un nouveau domaine pour lancer un service ?

Pourquoi Google insiste-t-il sur l'expérience utilisateur plutôt que sur le SEO ?

La déclaration de 金谷武明 coupe court à un débat vieux comme le web : sous-domaine vs nouveau domaine. Google affirme clairement que cette décision doit reposer sur la cohérence perçue par l'utilisateur, pas sur des calculs SEO hypothétiques. L'idée est simple — si votre service prolonge naturellement votre offre principale, un sous-domaine fait sens. Si c'est un univers distinct avec sa propre identité, un domaine séparé s'impose.

Le moteur de recherche traite les deux structures différemment sur le plan technique, mais cette distinction n'est pas figée. Google peut considérer un sous-domaine comme une extension du domaine principal ou comme une entité séparée selon le contexte. Ce flou intentionnel oblige à penser d'abord à la cohérence éditoriale, pas à des micro-optimisations.

Qu'est-ce qui constitue une décision « optimisée pour le SEO » selon Google ?

Google pointe du doigt les décisions prises uniquement pour manipuler le référencement. Créer un sous-domaine parce que « ça hérite de l'autorité du domaine principal » ou lancer un nouveau domaine pour « éviter de polluer le domaine principal avec du contenu risqué » — voilà le genre de raisonnements que Google juge contre-productifs.

Ces stratégies partent du principe que Google a une règle mécanique fixe pour évaluer sous-domaines et domaines. La réalité est plus complexe — l'algo ajuste son traitement selon les signaux contextuels : maillage interne, cohérence thématique, comportement utilisateur. Forcer une structure pour « gagner » en SEO revient à parier sur une règle qui n'existe pas.

Quelle est la conséquence concrète d'une décision purement SEO ?

Google parle de « regrets stratégiques ultérieurs ». Concrètement, ça signifie se retrouver coincé avec une structure qui ne correspond plus à l'évolution du service. Un sous-domaine créé pour « profiter de l'autorité » devient un boulet quand le service prend son autonomie et mérite sa propre marque. Inversement, un domaine séparé lancé pour « tester sans risque » complique le maillage et la cohérence quand le service s'intègre finalement à l'offre principale.

Ces migrations tardives — passer d'un sous-domaine à un domaine ou inversement — sont coûteuses en ressources et en risque SEO. Redirections massives, refonte de l'architecture, perte temporaire de positions… tout ça parce que la décision initiale était guidée par des gains SEO imaginaires plutôt que par la logique du service.

• Choisir la structure en fonction de la perception utilisateur, pas des hypothèses SEO
• Google ajuste son traitement des sous-domaines et domaines selon le contexte — pas de règle mécanique
• Les décisions SEO-first mènent souvent à des migrations coûteuses quand le service évolue
• Un sous-domaine convient si le service prolonge naturellement l'offre principale
• Un nouveau domaine s'impose si l'identité du service est distincte de la marque mère

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

Oui, et c'est d'ailleurs ce qui rend cette position Google aussi frustrante pour les SEO. On constate régulièrement que des sous-domaines bien conçus performent aussi bien que des répertoires, tandis que d'autres sont traités comme des sites complètement distincts. La différence ne tient pas à la structure technique elle-même, mais à la cohérence éditoriale et au maillage.

Les exemples ne manquent pas — des sites e-commerce avec un blog.monsite.com qui rankent excellemment parce que le contenu prolonge naturellement l'offre produit, et d'autres où le sous-domaine végète parce qu'il ressemble à un satellite mal ficelé. Google ne dit rien de nouveau ici, il rappelle juste que le contexte l'emporte sur la mécanique.

Quelles nuances faut-il apporter à cette recommandation ?

Google esquive un point crucial : le poids de l'historique et de l'autorité acquise. Dire « pensez utilisateur, pas SEO » fonctionne pour un lancement, mais quand tu as déjà un domaine avec 10 ans de backlinks et d'autorité, l'équation change. Un nouveau domaine part de zéro — pas de trust, pas d'historique, pas de backlinks. C'est un handicap réel que Google minimise dans sa déclaration.

L'autre nuance concerne les secteurs YMYL et les sites avec forte exigence de trust. Un nouveau domaine dans la santé ou la finance met des mois, voire des années, à établir sa crédibilité auprès de Google. Dans ces cas, un sous-domaine du domaine principal peut bénéficier d'un transfert de confiance — même si Google ne le formalisera jamais ainsi. [À vérifier] dans quelle mesure ce transfert de trust opère vraiment, mais les observations terrain suggèrent que ça joue.

Enfin, la déclaration ignore les stratégies de protection de marque. Lancer un service expérimental ou risqué sur un nouveau domaine permet d'isoler le risque réputationnel et algorithmique. Si Google pénalise ce contenu, le domaine principal reste intact. C'est une logique défensive légitime que la position « user-first » ne prend pas en compte.

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

Soyons honnêtes — quand tu lances un service dans un secteur ultra-concurrentiel, le SEO compte autant que l'UX. Dire « oublie le SEO » n'est pas réaliste si ton modèle économique repose sur l'acquisition organique. Dans ce contexte, hériter de l'autorité d'un domaine principal via un sous-domaine peut être décisif pour atteindre la rentabilité rapidement.

De même, certaines structures techniques imposent un choix — par exemple, une application web hébergée sur une infrastructure distincte qui nécessite techniquement un sous-domaine. Dans ces cas, le choix est contraint par l'architecture, pas par une réflexion UX ou SEO. Google fait comme si toutes les décisions étaient libres, alors que les contraintes techniques et budgétaires orientent souvent le choix.

Que faut-il faire concrètement lors du lancement d'un nouveau service ?

Commence par définir l'identité du service — pas sa structure technique. Pose-toi la question : est-ce que mes utilisateurs percevront ce service comme une extension naturelle de mon offre actuelle, ou comme quelque chose de fondamentalement différent ? Si c'est un complément cohérent, le sous-domaine (ou un répertoire) fait sens. Si c'est une marque distincte avec son propre positionnement, un nouveau domaine s'impose.

Ensuite, cartographie les parcours utilisateurs réels. Comment tes clients passent-ils d'un univers à l'autre ? Si le service est découvert via le site principal et s'inscrit dans un parcours continu, maintenir la cohérence de domaine facilite la navigation. Si les utilisateurs arrivent directement sur le nouveau service via des canaux distincts, la séparation de domaine devient logique. Le maillage interne et la cohérence du branding doivent guider le choix.

Quelles erreurs éviter dans cette décision ?

Ne pars jamais du principe qu'un sous-domaine « hérite automatiquement » de l'autorité du domaine principal. C'est une idée fausse persistante. Google peut traiter un sous-domaine comme une entité séparée si le contenu, le maillage et l'intention éditoriale divergent trop du domaine racine. Si tu crées un sous-domaine juste pour « profiter » de ton autorité, tu risques de te retrouver avec un site isolé qui ne bénéficie de rien.

Inversement, ne lance pas un nouveau domaine par peur de « polluer » ton domaine principal avec du contenu différent. Google ne pénalise pas la diversité thématique si elle reste cohérente avec ton activité globale. Un site e-commerce qui ajoute un blog ou un espace communautaire ne dilue pas son autorité — il l'enrichit, à condition que le contenu soit de qualité et bien maillé.

Et c'est là que ça coince souvent — beaucoup de décisions reposent sur des hypothèses SEO non vérifiées plutôt que sur une analyse réelle du parcours utilisateur. Teste ta structure avec de vrais utilisateurs, regarde comment ils naviguent, identifie les frictions. Si ta structure crée de la confusion ou casse le parcours, c'est elle qu'il faut ajuster — pas forcer une solution SEO-théorique.

Comment vérifier que la structure choisie reste pertinente dans le temps ?

Audite régulièrement la cohérence perçue entre tes différents univers. Si ton sous-domaine évolue vers une offre autonome avec sa propre identité, envisage une migration vers un domaine distinct. Si ton domaine séparé finit par s'intégrer complètement à l'offre principale, une consolidation peut avoir du sens. Ces évolutions sont normales — c'est pour ça que Google parle de regrets stratégiques.

Surveille aussi les métriques de navigation — taux de rebond entre domaines, parcours cross-domaine, comportement utilisateur. Si tes utilisateurs ne passent jamais d'un univers à l'autre, c'est un signal que la séparation est justifiée. Si au contraire ils naviguent constamment entre les deux, maintenir des domaines distincts crée de la friction inutile. Les données comportementales te disent si ta structure tient la route.

• Définir l'identité du service avant de choisir la structure technique
• Cartographier les parcours utilisateurs réels pour identifier la cohérence naturelle
• Ne jamais partir du principe qu'un sous-domaine hérite automatiquement de l'autorité
• Tester la structure avec de vrais utilisateurs pour détecter les frictions de navigation
• Auditer régulièrement la cohérence entre domaines à mesure que le service évolue
• Surveiller les métriques de navigation cross-domaine pour valider la pertinence de la structure