Live is a file tree under HTTPS

Making a static website live is a cutover you control: good files on the host, HTTPS you can click, then a domain if you want one. It is not a WordPress “go live” wizard, and it is not a remote theme compile. StaticHost serves what you upload. Build on your laptop or CI. Upload zip or GitHub files. nginx uses try_files $uri $uri/ =404 with no SPA index fallback. No email, no CDN product, no forever-free plan—Starter $9, Pro $30, Scale $65, Business $130 after a short trial.

Landing-page and docs-shaped static sites use the same live checklist; for placement advice see where to host a static landing page, hosting for a small static website, and static website hosting for documentation.

Think of “live” as three gates. Gate one: the artifact is complete on disk. Gate two: the preview hostname proves that artifact over TLS. Gate three: the custom hostname, if any, has verified DNS and a certificate. Crossing gates out of order is how launches get noisy.

Numbered go-live sequence

  1. Decide the artifact. Hand-written pages or generator output (_site, public, dist). One root. index.html at that root. If your generator offers a production flag, use it so asset URLs match the real origin.
  1. Prove it offline. Browse through a local static server when you can; at minimum open index.html and confirm relative links for CSS, fonts, and posts. Note any absolute URLs that still point at localhost.
  1. Package without nesting accidents. Zip contents so the archive root is the site root. Or use a GitHub branch that already mirrors that layout. StaticHost will not run Hugo for you if you push Markdown sources alone. Do not include node_modules or CMS databases “just in case.”
  1. Create the site and deploy. Pick a plan for site count and storage. Deploy. Copy the HTTPS preview URL into your notes beside the git SHA or zip filename you shipped.
  1. Acceptance on preview. Home, an interior page, feeds or assets you care about, mobile width once. Check the Network panel for 404s. Fix and redeploy until boring. Use deploy history if a new upload is worse than the last good one.
  1. DNS cutover last. Add domain, publish records, wait for verification, wait for certificate. Retest on the real hostname. Watch for mixed content if any asset still uses http://.
  1. Live checklist signed. Padlock on the hostname you share publicly, deploy history noted, rollback understood, monitoring of the primary CTA done once by a human who is not you.

Skip: importing a WordPress database into a static host. Skip mailbox setup. Skip declaring victory when only DNS changed but files still 404. Skip enabling imaginary SPA fallbacks—the platform will not add them.

What to skip when “going live”

Skip treating the host like an application server. Skip uploading wp-content and hoping. Skip changing production URLs in a CMS before HTTPS exists on the new side (irrelevant if you are truly static—but people mix migrations). Skip SPA fallback assumptions. Skip forever-free expectations for a commercial personal brand. Skip buying Scale ($65) or Business ($130) on day one when Starter ($9) or Pro ($30) matches your site count—you can upgrade when slots or storage run short.

Also skip performative complexity: object storage plus three CloudFront behaviors for a personal blog home is a hobby, not a go-live requirement.

Worked example: personal blog home page

You wrote a small blog in Eleventy on your laptop. Output lands in _site/ with index.html, posts/hello/index.html, and hashed CSS. You want you.example live this weekend.

Steps you actually take:

_site/
  index.html
  posts/hello/index.html
  css/index-3f2a.css
  feed.xml

Run npx @11ty/eleventy locally (StaticHost will not). Zip _site contents. Deploy. Preview shows the home list and the first post. Atom feed returns as a static file—fine. Click the post permalink; because the file exists on disk, it returns 200. A fictional /posts/missing/ path 404s, which is correct under try_files $uri $uri/ =404.

You do not migrate an old WordPress blog by dropping an SQL dump onto StaticHost. If you still have WordPress elsewhere, export content to Markdown, rebuild with Eleventy, and host the static output. The live moment is the preview looking right, then DNS.

Plan: Starter ($9) is enough for one blog and 2 GB. Add Pro ($30) later if you want a staging site for draft redesigns. Keep the ESP for newsletters separate; the blog host does not send mail.

Failure: skipping a database dump on a WordPress move

People arrive at “make the static site live” after years on WordPress and carry the wrong muscle memory. They copy themes and uploads but skip exporting posts (the database dump or a proper WXR/content export). On a PHP host that mistake is fatal. On StaticHost the mistake is conceptual: there is no MySQL to import into. Uploading a half-migrated public_html tree with PHP files does nothing useful—PHP will not execute, and your articles are still trapped in the old database you never exported.

Spend the energy fixing the process, not the host. If the destination is static, your go-live depends on content already rendered to HTML (or Markdown fed through a local generator). Dump or export first, transform second, upload third. If you still need WordPress runtime behavior, stay on a PHP host and do not call the project static. Mixing “I skipped the dump” with “I switched to static hosting” produces empty sites and false blame on DNS or TLS timing.

A related trap: renaming WordPress siteurl options toward the new domain before the static rebuild exists. You break the old site and still have nothing on the new one. Sequence exports and builds before any DNS or URL cutover.

Definition of done

  • Public URL serves your blog home with styles intact.
  • At least one post URL returns 200 with the expected body.
  • Optional custom domain has a valid certificate after DNS verification.
  • You can roll back the last deploy without SSH.
  • No lingering belief that a SQL file belongs on this host.
  • Primary CTA (subscribe form to an external ESP, or mailto) works from the live hostname.

When those hold, the static website is live. Maintenance is edit → rebuild → redeploy, not plugin theater.

Operational notes after the first live day

Bookmark the preview URL even after the custom domain works; it remains useful for testing a deploy before you call it production. Lower DNS TTLs a day before future migrations. Keep a local copy of the exact zip or commit you marked live. If you add a second property—docs, a landing page—use another site slot on Pro or higher rather than nesting unrelated brands under one root with confusing paths.

Static hosting without server management is the point; do not reinvent servers beside it. When requirements shift toward application runtimes, change products deliberately instead of forcing databases onto a file host.

Questions people actually ask

Can I make a site live without a custom domain?

Yes. The HTTPS preview URL is a real public site. Attach a domain when you want the branded name; certificates for that name follow DNS verification.

Will StaticHost build my Eleventy or Hugo blog?

No. Build locally or in CI you control, then upload the output folder. The host stores and serves files.

What happens to unknown post URLs?

They 404 unless a file or directory exists. There is no rewrite of all paths to index.html.

Which plan do I need for a personal blog?

Usually Starter at $9/mo (1 site, 2 GB). Move to Pro ($30) for staging or additional sites; Scale ($65) and Business ($130) are for larger site counts and storage.