Static hosting with a custom domain

Preview first, domain second

StaticHost gives every site an HTTPS preview hostname immediately after deploy. Use it until the file tree is correct. Only then attach a custom domain. Mixing “first DNS cutover” with “first zip ever” turns path bugs into public incidents.

This procedure covers adding a domain, DNS verification, certificate issuance, and post-cutover checks—including the SPA =404 footgun that domains do not fix.

Before DNS

• Site loads on preview over HTTPS.
• index.html is at the site root (not nested)—zip guide.
• Asset paths work on preview.
• You know whether you want apex (example.com), www, or both.
• You can log into the DNS provider that hosts the zone.

Add the domain in StaticHost

In the site settings, add the hostname(s). The dashboard shows the DNS records to create—typically hostnames and values for apex and/or www (A/ALIAS/ANAME/CNAME depending on provider capabilities). Copy them carefully; trailing dots and wrong record types are common failures.

Create DNS records

At your DNS provider:

1. Create the exact records StaticHost displays.
2. Remove conflicting old A/CNAME records pointing at a previous host if you are migrating.
3. Keep TTL moderate (300–3600s) during migration so fixes propagate faster.

Wait. Propagation is not instant worldwide. StaticHost verifies DNS when it sees the expected answers. Until verification succeeds, do not expect a certificate on the custom hostname.

Certificates after verification

When DNS verifies, StaticHost issues the TLS certificate for that hostname. HTTPS on the custom domain becomes real at that point—not before. Preview TLS never required your DNS; custom-domain TLS does.

If issuance lags, re-check records, CAA records that might block issuance, and that you did not typo the domain. Mixed content after HTTPS works is a separate class of bug—free SSL / mixed content.

Apex and www strategy

Pick a canonical host and redirect the other if your DNS/provider tooling supports it. Consistency matters for cookies you set client-side and for share URLs. Rebuild static generators with the correct baseURL/site/url config after the canonical name is chosen (Hugo, Jekyll, Astro all have such keys).

Post-cutover verification

1. https://your-domain/ loads the same tree as preview.
2. Certificate matches the hostname (padlock details).
3. HTTP→HTTPS behavior is acceptable for your audience.
4. Deep links: multi-page HTML fine; history-mode SPA still 404 without files—domains do not add SPA fallback.
5. External API CORS allows the new origin.
6. Roll back deploy if content is wrong; DNS rollback if you pointed the wrong place.

Migrations without drama

1. Deploy to StaticHost; QA on preview.
2. Lower TTL ahead of time.
3. Flip DNS.
4. Watch verification and cert.
5. Keep the old host read-only briefly until you trust the cutover.

Plans and extras you will not find

Domain hosting here is for website DNS pointing—not email. No mailbox product, no cPanel zone editors beyond what the product UI exposes for site domains, no forever-free. Plans: Starter $9 (1 site, 2 GB), Pro $30 (3 sites, 10 GB, staging), Scale $65 (10 sites, 30 GB), Business $130 (30 sites, 100 GB, teams). Trial ~1 day.

HTML-focused twin: HTML website with custom domain.

Worked example: moving www.example.com off a legacy host

You already QA’d the new static build on StaticHost’s HTTPS preview. Assets 200. No nested zip. Multipage routes exist as files (or you accepted hash routing).

Day −2: Lower TTL on the existing www record to 300 seconds. Add www.example.com in StaticHost; note the required CNAME/A targets from the dashboard. Do not flip yet.

Day −1: Create the new records in a draft change set if your DNS UI supports it. Confirm apex strategy: maybe apex ALIAS to the same target, or redirect apex → www at the DNS/CDN layer you control. StaticHost is not an email host—leave MX alone.

Day 0: Apply DNS. Wait for StaticHost verification. Wait for certificate issuance. Open https://www.example.com/ and compare to preview. Run CORS checks against the API. Hard-refresh a deep page—domains do not invent SPA fallback (try_files $uri $uri/ =404).

Day +1: If all good, decommission the old host’s site (keep DNS MX/TXT for mail untouched). If content is wrong, roll back the deploy; if DNS is wrong, fix records—not the zip.

Failure table: custom domains

Extra procedure: domain go-live checklist (printable)

1. [ ] Preview HTTPS equals the intended release.
2. [ ] index.html at site root; no nested folder surprise.
3. [ ] Generator baseURL/site uses the future canonical HTTPS URL (rebuild if needed—StaticHost will not run Hugo/npm).
4. [ ] Hostnames listed in StaticHost match what users will type.
5. [ ] DNS records copied exactly; old conflicting web records removed; MX preserved.
6. [ ] TTL lowered for the cutover window.
7. [ ] Verification succeeded.
8. [ ] Certificate issued; padlock checked.
9. [ ] Mixed content grep clean on the custom hostname.
10. [ ] SPA/deep-link expectations documented and tested.
11. [ ] Rollback owners named (deploy vs DNS).
12. [ ] No assumption of mailboxes, cPanel, forever-free, or a built-in CDN product.

Follow the order—HTTPS preview, then DNS, then cert—every time. Related: static hosting with free SSL, pricing.

Multi-brand hostnames and certificate inventory

Product companies sometimes attach several hostnames to related marketing sites—regional vanities, partnership URLs, legacy brand redirects. Each hostname you care about must be added, DNS-verified, and certificated. A certificate on example.com does not silently cover oldbrand.example without configuration. Inventory hostnames in a spreadsheet with columns: site ID, hostname, DNS provider, verified (Y/N), cert (Y/N), canonical (Y/N).

During migrations, remove hostnames you no longer serve so you are not managing dead cert surfaces. CAA records at the DNS provider can block issuance if they allow only another CA—adjust CAA when verification succeeds but certificates never arrive. StaticHost still will not host your email on those domains; keep MX untouched while you rearrange web records. Plans limit how many *sites* you run; follow the UI for per-site hostname rules, and size Starter→Business by inventory reality.

FAQ

Can I use a free subdomain from somewhere else?

You can CNAME compatible hostnames if the dashboard allows that name. Follow the records shown.

Why does preview work but the custom domain show the old site?

DNS still points elsewhere or cache/TTL. Check what dig/nslookup returns versus what StaticHost expects.

Does a domain fix React refresh 404s?

No. Routing architecture does—React.

How many domains per site?

Follow the product UI limits for your plan; site *counts* are plan-limited as above.

Is DNS included in the $9 plan?

You bring a domain from a registrar. StaticHost issues certs after your DNS verifies; registrar fees are separate.