Every few months someone announces that WordPress is dead, usually while WordPress is powering about four in ten websites on the internet. At the same time, "headless" and "static" get recommended for projects that would have been fine as five WordPress pages.
The honest answer is that all three shapes work. They fail for different reasons, and the deciding factor is almost never performance — it's how the content gets edited six months after launch.
The three shapes
| Shape | What it is | Best when | Watch out for |
|---|---|---|---|
| Classic WordPress | Server-rendered CMS, plugins, themes or blocks | You or a team edit content weekly | Plugin sprawl, security patching, heavy themes |
| Headless CMS + framework | Content API (Sanity, Contentful, Payload, Storyblok) feeding Astro or Next.js | Design and speed matter, content volume is high, devs are involved long term | Two systems, previews, build pipelines, higher running cost |
| Static + git CMS | Markdown in a repo, built to HTML (Astro, Hugo, Eleventy) and edited via Pages CMS, Decap, Keystatic or VS Code | The site is a marketing site that changes monthly | Editors have to accept markdown/git, or you build a small front end for them |
WordPress in 2026
It's still the default for a reason: a client can log in and change a price without calling anyone, hosting is cheap, and every second developer in Auckland knows it. The block editor has matured, full-site editing is usable, and managed WordPress hosting in the NZ$30–120/month range is genuinely fast if you pick the right provider.
The real cost is maintenance, not licensing. Plugins need updating, PHP versions move, and one abandoned plugin is a security incident waiting to happen. The 2024 WordPress/WP Engine dispute also reminded everyone how much of the ecosystem depends on a company being willing to keep the lights on commercially. None of that means "don't use it" — it means budget a few hours a year for care, or pay someone who does.
WordPress is the right answer when editing frequency is high and the content model is ordinary: pages, posts, products, a few custom post types.
Headless in 2026
Headless means the CMS only stores content and an API serves it to a separately built front end. The wins are real: you can pick the framework, ship the fastest possible front end, and reuse the same content across a website, an app and perhaps a kiosk.
The cost is usually under-estimated. You now run two systems: a content platform with its own pricing and its own failure modes, and a front end with a build pipeline. Previews need plumbing. Editors lose the convenience of "click publish, see it live" unless someone builds draft preview properly. A small business rarely has anyone who can maintain either half in-house, which locks the project to whoever built it.
Headless pays off for content-heavy sites — publishers, marketplaces, directories, multi-brand groups — where the content model itself is the product. It's rarely worth it for a 10-page brochure site, even a beautiful one.
Static in 2026
This is the shape I reach for most often for small business sites, and it's the least fashionable option in agency land because it's the cheapest to run. Markdown in a repository, a build step, HTML and CSS deployed to a CDN (Cloudflare Pages, Netlify, Vercel). No database, no PHP, no admin surface to attack, and TTFB that's hard to beat.
Editing is the trade-off. If the person updating content is comfortable with a git-based editor — Pages CMS and Decap both give a decent browser UI on top of a repository — static is genuinely practical. If not, either wrap it in a decent editing front end or pick a CMS instead.
This site is the static shape. The news pages you're reading are plain HTML generated at build time; there's no server-side code in the path at all.
The AI content problem nobody budgets for
Whatever you choose, the workflow matters more than the tool. Google's spam policies now explicitly target scaled content abuse — mass-produced pages generated to manipulate rankings. A CMS that makes publishing 200 AI-written location pages trivially easy is a liability, not a feature.
Practically: keep a human in the loop, publish less and mean it, and make sure the person responsible for accuracy is named. That rule applies equally to a WordPress install and a markdown repo.
How I'd choose
- Who edits, and how often? Weekly by a non-technical person → classic CMS. Monthly by someone comfortable with a browser-based git editor → static is fine. A team of five with a design system → headless.
- Is content the product? If yes, invest in the content platform. If no, keep the stack boring.
- Who maintains it in two years? If the answer is "nobody", choose the shape with the fewest moving parts — which is usually static, then WordPress, then headless.
- What's the budget, honestly? Static hosting is close to free. A headless stack can quietly cost more per month than the site earns.
- Does the decision survive a redesign? Content should outlive the front end. Any CMS that locks your text inside a page builder is a future migration.
None of these choices is permanent. But a website is usually a three-to-five-year decision, and the expensive mistake is picking the shape that impresses other developers rather than the one the content owner can actually run.
If you're weighing these up for a specific site, tell me who updates it and how often — that one answer usually settles it.