Subdomains, wildcards and how to structure a domain you own

Once you own a name, everything else is organisation: what goes on the bare name, what goes on a subdomain, what goes in a path. The decisions are easy to make and expensive to reverse, because reversing them means a migration.

Subdomain or subdirectory

The recurring question: should the blog live at blog.yourname.com or yourname.com/blog?

For content that belongs to the same site and audience, a subdirectory is generally preferable. Everything accumulates on one property, and there is no ambiguity about whether the two are the same site.

A subdomain makes sense when the thing is genuinely separate: a different technology stack, a different team, a different audience, or something that might one day be spun out. Application dashboards, documentation, status pages and regional sites are reasonable subdomains.

The test: would you be comfortable if this ranked and was perceived as a distinct site? If yes, subdomain. If no, subdirectory.

Wildcard records

A wildcard entry answers for every subdomain you have not defined explicitly. Convenient — one record covers everything — and it is why a new subdomain can work immediately without a DNS change.

The cost is that every conceivable subdomain resolves, including ones you never created. If what they resolve to is a sensible page, that is harmless. If it is an error or, worse, a service that will accept any hostname, it is a loose end.

Explicit records for the subdomains you actually use, plus a wildcard as a safety net pointing somewhere deliberate, is a reasonable arrangement.

Certificates

A certificate covers the names listed on it. A single-name certificate for the bare domain does not cover www, and neither covers arbitrary subdomains.

Either list the names you use explicitly, or obtain a wildcard certificate covering everything at one level. Note that a wildcard covers one level only: it will not cover a name two levels deep.

Automate renewal. Expired certificates are among the most common and most avoidable outages, and they always happen at the worst moment.

Conventions worth adopting early

Pick one canonical form — with or without www — and redirect the other to it permanently. Serving both is the same split-presence problem as running two domains, in miniature.

Serve everything over the secure form and redirect the insecure one. Keep subdomain names short and descriptive. Avoid a subdomain whose name duplicates a path you also use, which produces two addresses for the same idea and confuses everyone including you.

Write down what exists

Keep a list of every subdomain, what it serves and who is responsible. Forgotten subdomains pointing at services nobody manages are how a domain ends up hosting something its owner did not authorise — typically a subdomain still pointing at a service the account was closed on, which someone else can then claim.

Review that list annually alongside your renewal audit. It takes ten minutes and it is the only reliable way to notice the record nobody remembers creating.