What “online” means for a static site

Putting a static website online means one thing: a public HTTPS hostname returns the files you built, in the order and paths you intended. It is not “the marketing platform finished onboarding,” and it is not “DNS exists somewhere.” Done looks like this: open the preview URL, see your index.html, load CSS and images without 404s, click the primary call-to-action, then—only after that—attach a custom domain and wait for its certificate.

StaticHost is file hosting. You build locally (or in your own CI). You upload a zip of finished files or connect a GitHub tree that already contains those files. The platform does not run npm, Hugo, or Jekyll for you. nginx answers with try_files $uri $uri/ =404. There is no SPA rewrite to index.html. There is no mailbox product and no bundled CDN product. Plans are Starter $9, Pro $30, Scale $65, Business $130—short trial, no forever-free tier.

If you want a longer product map after this procedure, see where to host a static website and static website hosting for small websites.

Numbered path from folder to HTTPS

  1. Freeze a site root on disk. One folder. index.html at the top of that folder. Assets referenced with paths that resolve from / (for example css/sale.css, img/hero.webp). If you use a generator, run the production build on your machine and treat dist, public, or _site as the only candidate for upload.
  1. Reject junk before packaging. No node_modules, no .env, no editor swap files, no source-only trees that the browser will never request. Size matters for plan quotas: Starter includes 2 GB; heavier media may need Pro (10 GB) or above.
  1. Package correctly. Zip the *contents* of the site root so index.html sits at the archive root—or point GitHub at a branch that already has that layout. Nested project-name/index.html at the zip root is the classic blank-home failure.
  1. Create the site and deploy. Upload the zip or connect the repo. Open the HTTPS preview the moment the deploy finishes. Preview TLS does not wait on your DNS.
  1. Verify behavior, not vibes. Hard-refresh. Check Network for CSS/JS. Click every sale link and the legal footer if you have one. If a client-side route has no matching file on disk, expect 404—hash routes or prerendered HTML files are the remedies, not a host-side fallback.
  1. Only then attach DNS. Add the domain in the dashboard, create the records it shows, wait for verification, then wait for the certificate on that hostname. Keep sharing the preview URL until the custom name is green.
  1. Mark done. Preview good, custom hostname HTTPS when you need it, deploy history available for rollback. Maintenance is edit → rebuild if needed → redeploy.

Skip: pointing the apex domain on day zero, uploading WordPress, asking for mailboxes, and assuming deep SPA paths will rewrite themselves. For the “no servers to babysit” framing of the same product, see static website hosting without server management.

What to skip on purpose

Skip remote-build theater. StaticHost will not compile your campaign theme in the cloud. Skip cPanel muscle memory. Skip “we will add email later on this same invoice”—use a mail provider. Skip forever-free assumptions; after the short trial you are on a paid plan with explicit site and storage limits. Skip wiring a CDN console for a weekend page that is mostly text and one hero image—optimize weight instead.

Also skip announcing the custom domain before preview sign-off. That single habit prevents most embarrassed Slack messages during launches.

Worked example: weekend sale landing page

You need sale.example.com live by Friday noon for a 20% weekend promotion. The page is one HTML file, a stylesheet, a 180 KB WebP hero, and a form that posts to a third-party waitlist. No CMS. No member login.

Local tree:

weekend-sale/
  index.html
  css/sale.css
  img/hero.webp
  img/og-card.png

Build is “save the files.” Zip the contents of weekend-sale/ (not the parent Downloads folder). Deploy to StaticHost on Starter ($9) if this is your only site. Open the preview URL. Confirm the hero loads, the coupon code copies, and the form action still points at the external endpoint over HTTPS.

Do not flip DNS Thursday night “to be ready.” Flip DNS Friday morning after the preview matches the approved PDF from marketing. After DNS verifies, wait for the certificate, then retest on sale.example.com. If the 2 PM price tweak needs a hotfix, edit locally, re-zip, redeploy, and keep the previous deploy one click away in history.

That is a complete put-online loop for a campaign page: files, preview, domain, cert—nothing else required.

Failure: pointing DNS before the preview looks right

The most expensive early mistake is emotional, not technical. Marketing wants the real hostname in the email blast draft. Someone adds A/AAAA or CNAME records while the zip still has a broken stylesheet path or yesterday’s headline. Propagation starts. Partial resolvers show the new host. The preview URL—which was ready to catch the bug in five minutes—gets ignored because attention moved to DNS timelines and “why is SSL pending.”

What goes wrong in practice: you debug certificate status while the real defect is css/sale.css 404ing because the zip nested one folder too deep. Or you announce HTTPS on the custom name before issuance finishes and browsers warn users on launch morning. Or you discover mixed-content images only after DNS is live and cache gossip has begun.

Fix the order. Preview is the launch environment until you say otherwise. DNS is a cutover step after the file tree is trustworthy. Certificates follow verified DNS. If you must draft emails early, paste the preview hostname or wait. Reversing that order does not buy time; it spends it on the wrong queue.

What “done” looks like on paper

Write these checks once and keep them:

  • / returns your sale page with the correct H1 and price.
  • Stylesheet and hero return 200 on the preview host.
  • Primary CTA works (external form or tel:/mailto: as designed).
  • Optional: custom domain resolves and shows a valid padlock after verification.
  • You know which deploy is live and how to roll back.

When those are true, the static website is online. Everything else is iteration.

Questions people actually ask

Do I need a build server to put a static site online?

No. Hand-written HTML is enough. If you use a generator, run it where you already develop—laptop or your CI—then upload the output. StaticHost hosts files; it does not run npm or Hugo for you.

Why do some paths 404 even though the React app worked on localhost?

Local dev servers often rewrite unknown routes to index.html. StaticHost uses try_files $uri $uri/ =404 with no SPA fallback. Ship hash routes or real HTML files per URL.

Can I get email on the same plan?

No. StaticHost does not provide mailboxes. Keep DNS MX at a mail provider and use web hosting only for the site files.

When should I upgrade from Starter?

When you need a second site, staging, or more than 2 GB. Pro is $30 for three sites and 10 GB with staging; Scale ($65) and Business ($130) raise site and storage caps further.