Should You Launch on a Subdomain or a Brand-New Domain?

Subdomain, subdirectory, or a new domain — what's the real difference?

These three get used interchangeably in hallway arguments, and picking the wrong one on a whiteboard becomes a painful migration later, so it's worth being precise. A subdomain lives in front of your root: blog.yoursite.com. Technically it's a distinct host — it can point at a different server, run a different stack, and be managed almost like its own site — but it still hangs off your registered domain. A subdirectory (or subfolder) is a path on the same host: yoursite.com/blog. It shares everything with the parent — same server context, same domain, same accumulated reputation. A new domain is a fully independent property: yourblog.com, with its own registration, its own reputation, and nothing inherited from anywhere.

The mental model that keeps you out of trouble: a subdirectory is a room in your house, a subdomain is a guest cottage on the same lot, and a new domain is a building across town. All three can be perfectly right — but they behave differently the moment search engines, backlinks, and customers get involved.

Does Google treat a subdomain as part of your main site?

Officially, Google says it handles subdomains and subdirectories just fine and doesn't hand out a ranking bonus for either — its own guidance, echoed for years by Google's John Mueller, is essentially 'use whichever is easier for you to run.' Take that at face value: there is no penalty for choosing a subdomain, and anyone who tells you subdomains 'don't rank' is repeating folklore.

The nuance that matters is how earned authority — the trust that accumulates from backlinks, age, and quality — flows between these setups. Within a single hostname, that authority moves freely, so a subdirectory inherits your main domain's standing the instant you publish. A subdomain is treated as closely related but semi-separate, so it leans on the parent's reputation less directly and has to establish some of its own footing. A brand-new domain inherits nothing at all and starts its climb from zero.

So for the narrow goal of ranking content that's meant to lift your existing brand, the order is clear: subdirectory first, subdomain a solid second, new domain a distant third. That ranking only applies when SEO on your current brand is the goal — plenty of good reasons override it, which is the rest of this guide.

When is a subdomain actually the right call?

Reach for a subdomain when the thing you're launching clearly belongs to your existing brand but is genuinely separate in function or infrastructure. This is why the web is full of them: your product's logged-in app at app.yoursite.com, developer docs at docs., a help center at help. or support., a real-time status page at status., a public API at api., or a regional split like uk. or de. Each is unmistakably part of the parent brand, yet each runs on its own stack, ships on its own schedule, or needs to be walled off from the marketing site.

The other honest reason is engineering reality. If the new surface runs on a different host, CMS, or framework, stapling it into a subdirectory usually means standing up a reverse proxy and babysitting it forever. A subdomain lets that system live cleanly on its own infrastructure while still wearing your name. When separation is the point — different team, different stack, different uptime guarantees — a subdomain is the tool built for the job.

• app. — the logged-in product, separate from the marketing site
• docs. / developers. — documentation on its own stack and search
• help. / support. — a hosted help center you can't easily reverse-proxy
• status. — an uptime page that must stay up when everything else is down
• api. — the machine-facing endpoint, isolated from human-facing pages
• Regional or language splits when infrastructure, not just content, differs

When should you register a new domain instead?

Register a fresh domain when you're launching something you intend to market as its own brand. A spin-off product, a standalone free tool, a community, an event, a media property, a company blog you want to grow into a destination in its own right — anything that should eventually stand on its own name rather than borrow yours belongs on its own domain. The tell is simple: if you'd ever print it on a t-shirt, say it out loud in a pitch, or want people to remember it without your company name attached, it wants a real name.

The second trigger is separation of identity. A scrappy consumer side-project riding on an enterprise B2B domain sends a confused signal, and vice versa. And if there's any chance you'll sell or spin the thing out, a separate domain is a clean, transferable asset — untangling a beloved product from a subdomain of the mothership is a genuine headache you can avoid by never tying the knot.

Go in clear-eyed about the cost, though: a new domain starts its SEO life at zero, needs its own backlinks and trust, and is one more name to renew, secure, and defend. You're trading inherited authority for brand independence. When the thing deserves to be its own brand, that's a trade worth making — when it doesn't, you're just orphaning content that could have lifted your main site.

Subdomain vs. subdirectory: where should your blog and content live?

This is the most common version of the fight, and it has a default answer: if the content exists to pull search traffic toward your main brand, put it in a subdirectory — yoursite.com/blog, not blog.yoursite.com. The subfolder inherits your domain's authority immediately, and there's a long, well-documented trail of teams moving a blog from a subdomain to a subfolder and reporting meaningful ranking and traffic gains afterward. It's one of the most repeated 'we moved it and traffic went up' stories in SEO for a reason.

Use a subdomain for content only when a hard constraint forces it: a hosted blogging or knowledge-base platform you truly can't wire into a subfolder, a separate content team on a separate stack, or a compliance need to isolate the system. 'It was slightly easier to set up' is not that constraint — the setup convenience you buy today is exactly what you'll pay back, with interest, in a migration later.

Note the asymmetry that makes this decision worth getting right the first time: moving content from a subdomain into a subdirectory is a real project with redirects and a temporary ranking dip, while starting in the subdirectory costs you nothing extra. When the SEO-optimal path is also the cheaper one to start on, take it.

Spinning it out onto its own domain? Lock the name down first

If a new domain is the answer, the classic failure mode is falling in love with a name before you know you can actually own it — only to find the .com is long gone, the matching name collides with an existing brand, or the clean version is parked and priced for a fool. Decide on the name last, after you've checked reality, not first.

ZeroTaken checks a name across .com and the alternatives side by side in one search and never logs your queries, so you can pressure-test a shortlist of spin-off names without tipping off an aftermarket bot about the one you want. It runs live availability checks rather than guessing, so an 'available' result is one you can trust before you commit business cards and a launch date to it.

What does guessing wrong actually cost you?

The reason this deserves more than thirty seconds is that reversing it is expensive. Moving between a subdomain, a subdirectory, and a separate domain means a wall of 301 redirects, re-earning rankings that briefly slide during the transition, chasing down and updating internal links, canonical tags, sitemaps, email footers, app deep links, and analytics, and burning engineering time that could have shipped features. Search engines usually sort it out eventually, but 'eventually' can be weeks of soft traffic while your competitors don't have that problem.

None of that is a reason to freeze — it's a reason to spend ten real minutes on the decision now. Get the structure right on day one and you never think about it again. Get it wrong and it resurfaces as a quarter-long project the moment your traffic starts to matter.

So — subdomain or a new domain?

Keep it on your existing domain whenever the thing is an extension of your current brand: default to a subdirectory for anything whose job is to rank and feed your main site, and reach for a subdomain when function or infrastructure genuinely demands separation — the app, the docs, the status page, the API. Register a new domain when you're building a brand of its own: something you'll market, remember, or maybe one day sell on its own name.

When you're honestly torn, ask one question: would I ever market this independently, spin it out, or want it to stand without the parent brand attached? If the answer is yes, give it its own domain now while it's cheap and painless. If the answer is no, keep it home, put it in a subfolder, and get back to building the thing that actually matters.