A support site can sit on a subdomain, support.example.com, or a subdirectory, example.com/support. The subdirectory inherits your main domain's existing authority; the subdomain is usually far easier to host separately. Once you have chosen, the DNS records that make it resolve, and the certificate and redirect work around them, are the same either way.
This page is one part of a larger guide. For the whole subject in one place, see self-hosting a feature request board.
Subdomain or subdirectory: which is actually right?
Search engines have historically treated a subdomain as a distinct site from the domain it hangs off. That means support.example.com starts with its own reputation, separate from whatever authority example.com has built, and largely has to earn trust from scratch. A subdirectory, example.com/support, is read as part of the same site, so it inherits the domain's existing authority immediately. For a small company whose domain already ranks for its product name, that is the whole argument for a subdirectory: new pages start with a running start instead of nothing.
Set against that is a genuinely practical point in the subdomain's favour: hosting. A subdirectory usually has to be served from the same platform as the main site, because most hosts do not let you point one path at a different backend without proxy rules on the main site itself. A subdomain is just a different DNS name, so it can point anywhere: a different host, a different deploy pipeline, a team shipping on its own schedule. If your support site is a separate codebase built by a different tool, a subdomain is often the pragmatic choice, even though it gives up some inherited authority.
Which DNS record do you actually need?
| Record | Points to | When you use it |
|---|---|---|
| A | An IPv4 address | The apex domain, or any host, when your provider gives you a fixed IPv4 address to target |
| AAAA | An IPv6 address | The same cases as A, for providers that also publish an IPv6 address |
| CNAME | Another hostname | A subdomain, when your host gives you a hostname to point at rather than a fixed IP |
| ALIAS / ANAME | Another hostname, flattened to an IP at query time | The apex domain, when your host only gives you a hostname and your DNS provider supports this record type |
Most hosting platforms give you a hostname rather than a fixed IP, because the address behind it can change without warning you. That is easy to handle for a subdomain: point support.example.com at the hostname with a CNAME and the record is done. It is not that simple for the apex domain itself.
Why can't you CNAME an apex domain?
The DNS specification does not allow a CNAME record to coexist with any other record at the same name:
If a CNAME RR is present at a node, no other data should be present
RFC 1034, Domain Names: Concepts and Facilities
The apex of a domain, example.com with nothing in front of it, always carries other records: at minimum the NS records delegating the zone, and usually an SOA record describing it. A CNAME at the apex would conflict with those, so the standard forbids it and most authoritative DNS servers simply refuse to create one.
ALIAS and ANAME exist to work around that. They are not part of the DNS standard, but a feature some providers layer on top of it: you configure one like a CNAME, but the provider resolves the target hostname to its current IP at query time and answers with an A record, avoiding the conflict. Not every provider offers this. If yours doesn't, the apex domain is the one case where a subdomain is genuinely easier to configure than the bare domain.
A worked example, using generic placeholder hostnames:
support CNAME host.example-platform.net.
@ ALIAS host.example-platform.net.
www CNAME example.com.What about www?
Most sites serve both example.com and www.example.com, and the reason is that www is itself a subdomain, so it can always take a CNAME even on a provider with no ALIAS support. Whichever one you settle on as canonical, redirect the other to it permanently. Which one you pick barely matters technically; what matters is picking one and staying consistent everywhere you control a link.
How does TLS fit in, and how long does propagation take?
A TLS certificate has to be issued for the exact hostname it will serve, and issuance almost always requires proving you control the domain, either by publishing a specific DNS record or by serving a particular file at a URL on it. The DNS record has to exist and be visible before the certificate can be issued, and most managed hosts run this check automatically the first time they see your new domain attached.
Propagation is the wait between changing a DNS record and every resolver on the internet actually seeing the new value. It is governed by the record's TTL, time to live, which tells resolvers how long they may cache what they already looked up. A record with a TTL of one hour can take up to an hour to update everywhere; one with a TTL of a day can take a day. Set the TTL low, a few minutes, before any planned change, and only raise it once things have settled. Leaving a high TTL in place before a move is one of the two mistakes that actually bites: the change looks broken for hours while some resolvers still answer with the old value, and there is nothing to do but wait.
One payment, no subscription, unlimited products.
How do you make sure only one host actually wins?
Once both support.example.com and example.com/support could, in principle, serve pages, decide which is canonical and set up a permanent redirect from the other to it. Practically, whichever address a person or an old link points at should still work. For search engines, serving the same content at two addresses without a redirect splits whatever links and signals arrive at either one, since a crawler has no reliable way to know the two pages are really the same thing.
A canonical redirect fixes both problems in one change, and it needs to happen when you set up the domain, not as an afterthought once pages start showing up twice in search results. That is the second mistake that actually bites: standing up the host and the DNS records, and never getting round to the redirect, so both addresses quietly serve the same content indefinitely, with neither getting full credit for it.
If you are also setting up notification email on this domain, the same zone will carry SPF, DKIM and DMARC records too. See SMTP for self-hosted tools for what those do. And once traffic reaches your host over a valid certificate, the response headers it sends matter just as much as the certificate; see security headers for a public feedback page for what to add.
Frequently asked questions
Do I need both an A record and an AAAA record?
Only if your host publishes an IPv6 address to target. An A record alone is enough for the site to work; the matching AAAA record simply lets visitors on IPv6-only networks connect directly instead of through an IPv4 gateway.
Can I run a subdomain and a subdirectory pointing at the same content?
You can, but it recreates the exact problem a canonical redirect exists to solve: two live addresses serving the same content, splitting search signal between them. If you want both for convenience, pick one as canonical and redirect the other, the same as with www.
What happens if I change hosting providers later?
You update the DNS records to point at the new provider, and a new TLS certificate gets issued once it can prove control of the domain. The wait during the switch is propagation of the changed record, governed by whatever TTL was set beforehand, which is why lowering it ahead of a planned move matters.
Does subdomain versus subdirectory affect how AI tools cite a page too?
The mechanism is the same one: a subdomain is generally read as a separate entity from the root domain, and a subdirectory as part of it, whichever system is doing the reading. This guide does not put a number on it either way.
How do I know when propagation is actually finished?
Query the record with a DNS lookup tool such as dig or nslookup, against a public resolver rather than your own machine's cache, and confirm it returns the new value. Check from more than one resolver, since each can hold the old cached answer for a different length of time.