DEV Community

Cody Wang
Cody Wang

Posted on Edited on

A subdomain is a product decision, not a hosting decision

#webdev #design #seo #discuss

I added two subdomains to my own product domain today. Then I deleted both, about forty minutes apart. The interesting part isn't the deletion — it's that neither one was a hosting decision. Both were product decisions I made by accident.

The convenience trap

The setup: prismicaudit.com is my audit product. Its DNS is on Cloudflare, with a tunnel pointing at services on one small box — the main site on one port, a slice builder on another, a preview environment on a third. Each new app got a hostname because a hostname was the path of least resistance:

prismicaudit.com        → :8787
slicelab.               → :5300
builder.                → :8791
puck.                   → :5199
Enter fullscreen mode Exit fullscreen mode

Then I started selling homepage templates. Template #18 needed a sales page. The fastest thing to type was t18.prismicaudit.com. Twenty minutes later I had a second page, so I made templates.prismicaudit.com and moved it there. Two hostnames, maybe forty minutes of total existence.

My client's one-line reply: "Doesn't piling subdomains on prismicaudit look bad? And every subdomain should need my approval."

He was right, and not for the reason I first assumed.

What a subdomain actually claims

A subdomain is not a folder. It is a claim that this thing is a separate property:

  • It splits link equity. Every inbound link to t18.prismicaudit.com credits that hostname. Nothing flows back to the apex.
  • It splits the brand. A visitor who lands on the subdomain sees a different name in the URL bar. If it's a sales page, they now have to trust two names instead of one.
  • It splits your search console. Another property to verify, another sitemap, another set of zero-data reports.
  • It never gets cleaned up. The cost is paid later, by whoever audits the zone in eighteen months and finds five hosts, three of which 404.

The hosting reason was real — separate ports, separate services, one CNAME each. But "it's easy to route" is not the same as "it should exist." I had been treating DNS as a deployment detail when it's closer to a sitemap.

The rule I landed on

Two shapes, and nothing in between:

  1. Same product, path. Product pages live at example.com/t18/. One hostname, one property, one sitemap. The routing is slightly more work — a catch-all static server, or a rewrite — and that's the tax you pay for keeping the brand in one piece.
  2. Different product, own domain. If it deserves a subdomain, it probably deserves a domain. A subdomain is the worst of both: separate identity, shared reputation.

Anything else — a preview environment, an internal tool, a one-off landing page — belongs behind auth or on a throwaway host (*.vercel.app), not on the domain you're trying to build.

The part I got wrong twice

The first mistake was creating the subdomain. The second was moving the page to a second subdomain to fix the first one. Both times the reasoning was identical: the page already worked, so the only question left was where to point DNS. That framing hides the actual question — should this be a separate property at all?

The test I use now, before adding a hostname:

  • Will this page ever be linked to from outside? (If yes, path.)
  • Does it need its own brand or its own audience? (If yes, domain.)
  • Is it temporary, internal, or a preview? (If yes, not on this domain.)

If the answer is "I don't know yet," the default is a path. Paths are reversible for free. Subdomains cost you a redirect forever, and a small amount of credibility every time someone notices.

Both hostnames are gone now. The page lives on a Vercel project, and when it earns a permanent home it gets a path or its own domain — decided on purpose, not because the CNAME was easy to type.

I build these homepage templates and the audits that keep them fast: SliceLab · PrismicAudit.

Top comments (0)