Why I Still Ship Static Sites in 2026

My main site is HTML and CSS on a CDN. No framework, no build server, no runtime. It has never gone down, it costs about four dollars a month, and I've deployed it from an airport lounge on hotel wifi more than once.

This is not a purity argument. Static has real costs and there's a clear line where I stop recommending it. But that line is much further out than most people assume.

Why static, still

The failure surface is almost nothing. No server to patch, no database to corrupt, no dependency to break at 3am. The things that wake people up in the night mostly don't exist here.

It's fast without effort. Not "fast after we optimised it" — fast because there's nothing between the request and the file. Performance work stops being a project and becomes a non-issue.

It doesn't rot. A site I built in 2019 still builds and deploys today, unchanged. I can't say that about a single framework project from the same year, and the maintenance cost of that difference is enormous over five years.

Nobody can take it away. The files are on my disk. Any host will serve them. There's no platform whose pricing or policy change can strand me, which — after three separate platform surprises — I now weigh heavily.

What it actually costs you

Honest list, because the advocacy usually skips this part:

• Anything personalised is out unless you fetch it client-side, at which point you've reinvented a slower version of a dynamic site.
• Content editing needs a workflow. Non-technical people cannot update a static site without you building them something. This is the objection that kills it for most teams, and it's legitimate.
• Search, comments, forms and auth all need a third party. Each one is a small dependency you were trying to avoid.
• Large sites need a generator, and now you have a build step and a tool that can go out of date. Static isn't free of tooling above a certain size — it's just cheaper tooling.

Where I stop recommending it

Three clear signals, any one of which is enough:

1. Users have accounts and see different things. This is the real line. Personalisation is what dynamic servers are for, and fighting it is how people end up with a static site wrapped in so much JavaScript that every original benefit is gone.
2. Non-technical people publish daily. A CMS costs less than the editing workflow you'd have to build and support.
3. Content changes faster than you can deploy. If it's minute-to-minute, you want a database.

Note what isn't on that list: page count, traffic volume, or having forms. I've run a 260-page static site with hundreds of thousands of monthly visitors and none of that was the difficult part.

The question isn't "is static powerful enough". It's "do different users need to see different things". Almost everything else is solvable.

My current setup

Deliberately dull:

• A ~200-line Python script that assembles pages from a content file and a shared shell. Not a framework. I can read all of it in one sitting, which is the point.
• Plain CSS with custom properties. One file. No preprocessor, no utility framework, no build.
• A CDN host with git-push deploys. Any of the major ones; they're interchangeable, which is exactly the property I want.
• A hosted form endpoint for the newsletter and contact page. The one dependency I've accepted, chosen because exporting my data out of it takes one click.

The whole thing is about 600 lines of code I fully understand. When something breaks — and it does, occasionally — I can find it in minutes. That's what I'm actually buying.

What it costs and what it delivers

Concrete numbers from my own site, which is 37 pages and gets a bit over 60,000 visits a month.

The row I'd point at is the second-to-last. Zero dependencies isn't a performance claim, it's a maintenance one: there is nothing to patch, nothing to upgrade, and no morning where a security advisory reorganises my day. Over five years that compounds into a genuinely large amount of time.

Page weight matters more than the raw numbers suggest, too. 62KB versus 1.8MB is not a subtle difference on a hotel connection in a country with poor infrastructure — which, given what I write about, is a meaningful share of my readers.

How I'd migrate an existing site

If you've decided static is right and you're currently on a CMS, the order matters. This is the sequence I've used twice and would use again.

1. Export the content to plain text first, before touching anything else. Markdown or HTML files on your disk. Do this even if you abandon the migration — you now own your content, which was the most valuable part regardless.
2. Map every existing URL. Every one, including the ugly ones with query strings. This list is what stands between you and losing your search traffic, and rebuilding it after the fact is miserable.
3. Rebuild the templates, not the design. Resist redesigning at the same time. If traffic drops you want exactly one variable to investigate.
4. Set up 301 redirects for anything whose URL changes. Ideally nothing changes. Where it must, redirect at the host level rather than with client-side JavaScript, which search engines handle poorly and slowly.
5. Launch, then verify crawlability the same day. Fetch the sitemap, check a sample of pages return 200, confirm the canonical tags point where you expect. Most migration disasters are discovered three weeks late.
6. Keep the old stack running for a month. Cheap insurance, and it gives you somewhere to check what a page used to say.

The step people skip is the second one. I've watched two migrations lose most of their organic traffic, and both times the cause was the same: URLs changed, nobody mapped them, and the redirects were reconstructed from memory weeks later.

Questions I get about this

Found an error in this piece? Tell me — corrections get made in the open with a dated note, never a silent edit. The log is public.