Should you choose a subdomain or a new domain for launching a service?

Why does Google emphasize user experience over SEO?

The statement from 金谷武明 cuts to the heart of a debate as old as the web: subdomain vs new domain. Google clearly states that this decision should be based on the perceived consistency by the user, not on hypothetical SEO calculations. The idea is simple—if your service naturally extends your core offering, a subdomain makes sense. If it's a distinct universe with its own identity, a separate domain is necessary.

The search engine treats both structures differently from a technical standpoint, but this distinction isn't set in stone. Google can view a subdomain as a extension of the main domain or as a separate entity, depending on the context. This intentional ambiguity forces one to think first about editorial coherence, not micro-optimizations.

What constitutes an 'SEO-optimized' decision according to Google?

Google points to decisions made solely to manipulate rankings. Creating a subdomain because 'it inherits the authority of the main domain' or launching a new domain to 'avoid polluting the main domain with risky content'—these are the types of reasoning Google deems counterproductive.

These strategies assume Google has a rigid mechanical rule for evaluating subdomains and domains. The reality is more complex—the algorithm adjusts its handling based on contextual signals: internal linking, thematic coherence, user behavior. Forcing a structure to 'win' in SEO amounts to betting on a rule that doesn’t exist.

What are the concrete consequences of a purely SEO-driven decision?

Google talks about 'subsequent strategic regrets'. In practical terms, this means ending up with a structure that no longer aligns with the service's evolution. A subdomain created to 'capitalize on authority' becomes a burden when the service gains independence and deserves its own brand. Conversely, a separate domain launched to 'test without risk' complicates linking and coherence when the service ultimately integrates into the main offering.

These late migrations—switching from a subdomain to a domain or vice versa—are resource-intensive and risky for SEO. Massive redirects, overhauling architecture, temporary loss of rankings... all because the initial decision was driven by imaginary SEO gains rather than service logic.

• Choose structure based on user perception, not SEO assumptions
• Google adjusts its treatment of subdomains and domains based on context—no mechanical rule
• SEO-first decisions often lead to costly migrations when the service evolves
• A subdomain fits if the service naturally extends the primary offering
• A new domain is necessary if the service's identity is distinct from the parent brand

Is this statement consistent with what we observe in practice?

Yes, and this is what makes Google's position so frustrating for SEOs. Well-designed subdomains often perform as well as directories, while others are treated as completely separate sites. The difference doesn't lie in the technical structure itself, but in the editorial coherence and linking.

There are plenty of examples—e-commerce sites with blog.mysite.com that rank excellently because the content naturally extends the product offering, and others where the subdomain languishes because it looks like a poorly connected satellite. Google isn't saying anything new here; it's just reminding us that context trumps mechanics.

What nuances should be added to this recommendation?

Google is skirting a crucial point: the weight of history and acquired authority. Saying 'think user, not SEO' works for a launch, but when you already have a domain with 10 years of backlinks and authority, the equation changes. A new domain starts from scratch—no trust, no history, no backlinks. That's a real handicap that Google downplays in its statement.

The other nuance pertains to YMYL sectors and sites with high trust requirements. A new domain in health or finance takes months, if not years, to establish credibility with Google. In these cases, a subdomain of the main domain can benefit from a trust transfer—even if Google never formalizes it this way. [To verify] the extent to which this trust transfer truly operates, but field observations suggest it plays a role.

Finally, the statement ignores brand protection strategies. Launching an experimental or risky service on a new domain allows for isolating reputational and algorithmic risks. If Google penalizes that content, the main domain remains intact. This is a legitimate defensive logic that the 'user-first' position doesn't consider.

In which cases doesn't this rule really apply?

Let's be honest—when you launch a service in an ultra-competitive sector, SEO matters just as much as UX. Saying 'forget about SEO' isn't realistic if your business model relies on organic acquisition. In this context, inheriting authority from a main domain via a subdomain can be crucial for reaching profitability quickly.

Similarly, certain technical structures impose a choice—e.g., a web application hosted on a distinct infrastructure that technically requires a subdomain. In these cases, the choice is constrained by the architecture, not by UX or SEO considerations. Google acts as if all decisions are free, while technical and budget constraints often guide the choice.

What should you actually do when launching a new service?

Start by defining the service's identity—not its technical structure. Ask yourself: will my users perceive this service as a natural extension of my current offering, or as something fundamentally different? If it's a coherent complement, a subdomain (or a directory) makes sense. If it's a distinct brand with its own positioning, a new domain is necessary.

Next, map out the real user journeys. How do your clients move from one universe to another? If the service is discovered via the main site and fits into a continuous journey, maintaining domain coherence aids navigation. If users are arriving directly at the new service through distinct channels, separating domains becomes logical. Internal linking and branding coherence should guide the choice.

What mistakes should you avoid in this decision?

Never assume that a subdomain 'automatically inherits' authority from the main domain. This is a persistent misconception. Google can treat a subdomain as a separate entity if the content, linking, and editorial intent diverge too much from the root domain. If you create a subdomain just to 'benefit' from your authority, you risk ending up with an isolated site that gains nothing.

Conversely, don't launch a new domain out of fear of 'polluting' your main domain with different content. Google doesn't penalize thematic diversity if it remains coherent with your overall business. An e-commerce site adding a blog or community space doesn't dilute its authority—it enriches it, provided the content is of high quality and well-linked.

And this is where it often gets tricky—many decisions rely on untested SEO assumptions rather than actual analysis of user journeys. Test your structure with real users, observe how they navigate, and identify friction points. If your structure creates confusion or disrupts the journey, it's the structure that needs adjustment—not a theoretical SEO solution.

How can you check that the chosen structure remains relevant over time?

Regularly audit the perceived coherence among your different universes. If your subdomain evolves into a standalone offer with its own identity, consider migrating to a distinct domain. If your separate domain becomes fully integrated into the main offering, consolidation may make sense. These evolutions are normal—this is why Google speaks of strategic regrets.

Also monitor navigation metrics—bounce rates between domains, cross-domain journeys, and user behavior. If your users never transition from one universe to another, it's a signal that the separation is warranted. If, on the contrary, they constantly navigate between the two, maintaining distinct domains creates unnecessary friction. Behavioral data will tell you if your structure holds up.

• Define the service's identity before choosing the technical structure
• Map real user journeys to identify natural coherence
• Never assume that a subdomain automatically inherits authority
• Test the structure with real users to detect navigation friction
• Regularly audit coherence across domains as the service evolves
• Monitor cross-domain navigation metrics to validate the relevance of the structure