How to Choose Hosting for a Static Business Website

What static-first rules out

A static-first site is HTML, CSS, images and some JavaScript, built once and then served as files. There is no PHP interpreter running per request, no database to back up, no admin login for an attacker to find. That one fact removes most of what people worry about when they compare hosting. Uptime under load stops being a question of RAM and becomes a question of whether the host has a decent content delivery network. Security patching largely disappears, because there is nothing on the server to patch.

What it does not remove is the small tail of dynamic behaviour every business site needs. A contact form has to post somewhere. Analytics has to be collected. You may want a redirect from an old URL, a caching header on your fonts, or a Content Security Policy. So the honest way to frame the decision is this: the files are trivial to serve, and the platform earns its keep on everything around them.

Deploy from a repository, or expect to regret it

The first filter is how a change gets from your machine to the public site. If the answer involves dragging a folder into an FTP client, walk away. Manual upload means half-deployed states, files nobody can account for, and a site whose live version does not match anything in version control.

What you want is a host connected to your Git repository: you push a commit, it runs the build, and it swaps the result in atomically. Two consequences follow, and both matter more than they sound. The live site is always the output of a known commit, so you can see exactly what is published and when it changed. And a broken build fails before it goes live rather than half-way through, which is the difference between a bad afternoon and a bad week.

Preview deployments are the underrated part of this. A per-branch or per-pull-request URL means you can send a client the actual page rather than a screenshot, and you can look at a rewritten homepage on a phone before anyone else sees it. Once you have worked this way, going back to “upload it and check” feels reckless.

The domain and the certificate should take five minutes

Custom domains are where cheap hosting quietly costs you. What you are looking for is: point a DNS record, and the platform issues and renews a TLS certificate on its own, for the apex domain and the www subdomain, with one redirecting to the other so you do not split your canonical URLs.

Three things are worth confirming before you commit. First, that certificate renewal is automatic and free, not a line item and not a calendar reminder. Second, that the apex domain is supported properly, because a host that only accepts a CNAME will struggle with a bare domain unless your DNS provider supports flattening or an ALIAS record. Third, that you keep control of DNS. Where the nameservers live determines who can move the site, and you want that to be you.

Getting this right is dull and it stays right for years. Getting it wrong produces the specific failure that costs the most trust: a browser warning on a business site, seen by someone who was about to make an enquiry.

Redirects and headers separate the real hosts from the file dumps

Every static host will serve files. Fewer will let you say anything about how they are served, and that gap is where the cheapest options hurt.

You will need redirects. URLs change when a site is restructured, and a 301 from the old path is what carries your search rankings across. You will need response headers: cache-control so that fingerprinted assets can be cached hard and HTML cannot, plus the security headers a reviewer will ask about. You may need a custom 404 that actually looks like your site. Some of the older static hosting options, GitHub Pages included, give you very little control over headers and no native redirect rules, which is fine for a documentation site and a nuisance for a business one.

This also feeds directly into how quickly the site loads, which is a different problem with a lot of overlap. If a host makes it hard to set caching correctly, you have imported a performance issue that no amount of image optimisation will fix. We wrote about the rest of that problem in the specific things that make a small business site slow.

Work out where the form posts before you pick the host

A static site cannot process a form on its own, so the platform’s answer to that question shapes your build. Broadly there are three routes. The host provides form handling and emails you the submissions. You use a third-party form endpoint. Or you run a small serverless function on the same platform and control it yourself.

All three work. The differences that matter in practice are spam handling, where the submission is stored, and whether you can change your mind later. Anything that keeps a copy of enquiries on someone else’s dashboard has consequences for your privacy notice, and if you offer a form at all you need one, which is why this site publishes both a privacy notice and a cookies page. The contact page here sends messages straight to an inbox, which is the arrangement most small businesses actually want: no ticket queue, no second login to remember.

Analytics deserves the same thought. A script that sets cookies changes what your cookies page has to say. A server-side or cookieless option keeps the page honest and short. If you are still deciding what goes on the enquiry page itself, what belongs on a small business contact page covers the fields and the wording.

Read the shape of the bill, not the headline number

Static hosting is cheap, and the free tiers on the main platforms are genuinely generous for a business brochure site. The risk is not the monthly price. It is the shape of the overage.

Ask what happens when you exceed the included allowance. Some platforms cap you and the site stops serving, which is bad but predictable. Some charge per gigabyte of bandwidth with no ceiling, which is fine until a bot crawls your image gallery three thousand times or a post gets shared somewhere busy. Build minutes are the other meter worth understanding: if your build takes several minutes and you push twenty commits on a Friday, you want to know whether that is free or metered. Seat-based pricing catches out agencies more than owner-run businesses, but it is worth checking before you invite a second person.

None of this argues for the cheapest option. It argues for knowing which line on your usage graph can turn into an invoice.

Rollback, history and who is allowed to publish

Atomic deploys give you something valuable: a list of previous builds, each one a complete site, any of which can be made live again. If a change goes wrong at four on a Friday, one click puts yesterday back. Compare that with restoring a database backup on a dynamic site and the appeal is obvious.

While you are looking, check the access controls. Two-factor authentication on the account that can publish your website is not optional. If more than one person has the key, you want to be able to see who deployed what. Publishing is a decision rather than a mechanical step, a point we made at more length in what an agent builds and what a human still decides, and a deploy log is how that decision leaves a trace.

Exit cost is the honest measure of lock-in

The useful test is whether a competent stranger could take your repository and put the site live on a different host in an afternoon. If the answer is yes, you have very little lock-in and a strong negotiating position for as long as you own the domain. If the answer involves exporting content out of a proprietary editor, rewriting your form handler and unpicking platform-specific configuration, you are more committed than you thought.

Static-first architecture is what makes the answer yes. The build output is a folder of files. Any static host on earth will serve a folder of files. What creates lock-in is everything you let creep in around it: a bespoke function API, a CMS with no export, redirect rules written in a format nobody else reads. Keep those small and documented, and keep them in the repository rather than in a web dashboard, and moving becomes a chore instead of a project.

What this site runs on

This deployment is a worked example rather than a recommendation. The pages are built with Astro to static output, published to Cloudflare Pages in a single action, and served on a custom domain over HTTPS with a certificate issued automatically. The build agent runs elsewhere, on Fly, and hands over a dist/ folder. That separation is deliberate: the thing that builds the site and the thing that serves it have no need to be the same thing, and keeping them apart means either can be replaced.

The questions worth asking before you commit

• Does it build from my repository on push, and can I see a preview URL before anything goes live?
• Can I add my apex domain and get a certificate that renews itself, at no extra cost?
• Can I set redirects, cache-control and security headers in a file that lives in version control?
• Where do form submissions go, who stores them, and what does my privacy notice have to say about it?
• What happens when I exceed the free allowance: a cap, or an invoice?
• Can I roll back to a previous build in one action, and can I see who deployed it?
• If I wanted to leave next month, what would actually have to be rewritten?

Seven answers will tell you more than any comparison table. Most platforms in this category will pass five or six of them; the ones they fail are the ones you will be living with.