A static site starts to feel real when it leaves the preview URL and lands on a domain you own.
That step is also where simple projects get messy. DNS records, apex domains, www, HTTPS certificates, redirects, old URLs, and browser caching all arrive at once. None of it is hard in isolation. The trouble is doing it in the right order.
Preview URL first, domain second
Use the preview URL as the working link until the site is approved.
That gives you a clean split:
- The preview URL proves the uploaded files work.
- The custom domain proves the public launch is ready.
If you connect a domain too early, every content fix becomes mixed with DNS debugging. Keep those problems separate. Upload the folder, open the HTTPS preview, test the site, then connect the domain.
On DeployPages, the homepage upload flow gives you that preview-first path. Once the site is ready, move to custom domains and free SSL.
Apex domain or www?
You usually have two choices:
| Domain type | Example | Best for |
|---|---|---|
| Apex domain | example.com | The cleanest public address |
www subdomain | www.example.com | Very common, usually easy to route |
| Custom subdomain | docs.example.com, app.example.com | Docs, campaigns, side projects, previews |
GitHub's own Pages documentation recommends thinking carefully about apex and www setup and notes that www subdomains are the most stable type for GitHub Pages because they are not affected by changes to GitHub server IP addresses. The exact record requirements vary by host, but the operational lesson is broader: choose one primary address, then redirect the other one there.
For most marketing sites, portfolios, and docs sites, either of these is fine:
example.comas primary, withwww.example.comredirecting to it.www.example.comas primary, withexample.comredirecting to it.
Do not let both serve separate copies of the same site. That creates duplicate URLs for users and search engines.
DNS records in plain English
You do not need to memorize every DNS record type. For static hosting, these are the ones you will usually meet:
| Record | What it does | Typical use |
|---|---|---|
CNAME | Points a subdomain to another hostname | www.example.com to a host-provided target |
A | Points a domain to an IPv4 address | Apex domain when the provider gives IPs |
AAAA | Points a domain to an IPv6 address | Apex domain when IPv6 is supported |
ALIAS or ANAME | Points an apex domain to a hostname | Provider-specific alternative to A |
TXT | Stores verification text | Domain ownership checks |
Your host should tell you exactly which record to add. If it does not, that is a product problem, not a user problem.
Use a lookup tool after editing records. DeployPages includes a DNS lookup tool for checking whether the public internet can see the change yet.
HTTPS is part of the launch, not a bonus
A custom domain without HTTPS looks broken to users, browsers, and search engines.
Before announcing the link, check:
- The domain opens with
https://. - The certificate covers the exact hostname you are using.
- The
http://version redirects to HTTPS. - The non-primary hostname redirects to the primary hostname.
- Browser warnings are gone in a private window.
If DNS is still propagating, HTTPS provisioning can take time. Do not keep changing records every few minutes unless the values are wrong. Wait, check, then change only the thing that needs changing.
The SSL checker is useful here because it lets you verify the certificate from outside your browser cache.
How custom domains fit static site deployment
The cleanest deployment chain looks like this:
| Stage | URL | Purpose |
|---|---|---|
| First upload | Temporary preview URL | Check the files and share internally. |
| Review | Stable preview URL | Send to clients, teammates, or stakeholders. |
| Launch | Custom domain | Public traffic and SEO. |
| Update | New deployment version | Fix or improve without breaking the old version. |
| Recovery | Rollback | Restore a known-good version if the update fails. |
That chain is one reason a static host should do more than store files. Once a site has a real domain, you need version awareness. A broken upload should not take down the public link without a recovery path.
DeployPages keeps rollback as a product-level feature, not as a manual "find the old ZIP" exercise. See instant rollback for the release-control side.
Common custom domain mistakes
Uploading the wrong build before connecting DNS
If the preview URL is broken, the domain will be broken too. Fix the files first.
Mixing two primary hostnames
Pick example.com or www.example.com. Redirect the other.
Forgetting old links
If you are replacing an existing site, check important old paths. Static sites can still need redirects.
Assuming DNS changed because the dashboard changed
Your DNS provider's dashboard is not the same as public DNS resolution. Use lookup tools.
Launching without metadata
Before a domain launch, set a real title, description, favicon, and social image. The metadata generator and OG image tool can help with the boring but visible parts.
When a custom domain is worth it
Add a domain when:
- The site represents a business, person, product, event, or client.
- The link will be printed, shared in ads, or added to a profile.
- SEO matters.
- People will revisit the site later.
- You need trust beyond a temporary preview URL.
Skip the domain for disposable previews, quick feedback loops, or internal demos that will be replaced tomorrow.
Static hosting works best when it lets you move at both speeds. Preview links should be fast. Domain launches should be deliberate.