Static Sites Are Back. I Moved Clients Off WordPress and They're Not Going Back.

I built a dog grooming website as static HTML. No WordPress. No React. No build step. Just HTML files, a CSS stylesheet, and zero JavaScript frameworks. It loads in under a second on a cheap VPS, it's never been hacked, and the client hasn't called me once to fix a broken plugin.

That site — Fancy Pet Salon in Lynchburg, Virginia — is one of several projects where I chose static HTML over a CMS. A backyard cinema rental business. A developer portfolio (the one you're reading this on). Multiple marketing sites for client presentations. All static. All fast. All trouble-free.

I'm not some kind of purist who hates dynamic sites. I also run Kirby CMS for a company website and Laravel apps for quoting tools. The right tool depends on the job. But for a surprising number of web design projects, the right tool is plain HTML — and the industry has been over-engineering the wrong solution for years.

Why WordPress Became the Default (and Why That's a Problem)

WordPress powers something like 40% of the web. It became the default recommendation for every type of website because it has a plugin for everything, themes are cheap, and non-technical clients can log in and edit content. I've written in detail about why I moved away from WordPress for most projects.

The problem is what comes with all that. A typical WordPress site loads 30-50 HTTP requests on a fresh page load. It runs PHP on every request. It queries a MySQL database to build a page that looks the same every time. It needs regular updates to core, themes, and plugins — and if you skip those updates, you're running known vulnerable software on the public internet.

I've cleaned up hacked WordPress sites. It's miserable work. The attack surface is enormous. Every plugin is a potential entry point. Every outdated dependency is a known vulnerability. WordPress security is a full-time job, and most small businesses don't have someone doing it.

The maintenance cost is real too. Plugin conflicts, PHP version upgrades that break things, database bloat, performance degradation over time. I've seen WordPress sites that take 8 seconds to load because they have 40 active plugins and a page builder generating nested div soup. The client doesn't know why their site is slow. They just know it is.

What Static Actually Means in 2026

When I say "static site," I don't mean a geocities page from 1998. I mean pre-built HTML files served directly to the browser with no server-side processing. The page is already built before anyone requests it.

The result: page loads measured in milliseconds instead of seconds. Zero database queries. Zero PHP execution. The web server just hands over a file. That's it.

Modern static sites use Tailwind CSS for styling, can include JavaScript for interactive features, and look indistinguishable from any dynamic site. The Fancy Pet Salon site is bilingual (English and Spanish), has a full service menu, image galleries, and contact forms — all static HTML. Nobody visiting the site can tell it's not WordPress.

For hosting, static files are absurdly cheap to serve. A basic VPS handles thousands of concurrent visitors without breaking a sweat. Or deploy to Netlify for free and let them handle the CDN. I deploy several client preview sites to Netlify — push to git, it builds, it's live. Total hosting cost: zero.

The "But I Need a CMS" Objection

This is the pushback I always get. "My client needs to edit content. They can't write HTML."

Fair point. Not every site can be purely static files that only a developer touches. But here's the thing: there are more options than just "WordPress or hand-coded HTML." The space between those two extremes is where the interesting solutions live.

Option 1: Flat-File CMS

I use Kirby CMS for J.M. Field Group's company website. Kirby is a flat-file CMS — it stores content in text files instead of a database. There's an admin panel where non-technical users can edit pages, add images, and manage content. But the underlying architecture is simpler than WordPress by an order of magnitude.

No database means no SQL injection attacks. No plugin ecosystem means no plugin vulnerabilities. Updates are rare and non-breaking. The site loads fast because there's minimal processing — Kirby reads a text file and renders a template. It's the CMS simplicity I wanted without the WordPress baggage.

Other flat-file options: Grav, Statamic (Laravel-based), and Cockpit. They all share the same philosophy: give editors a UI without the database overhead.

Option 2: Headless CMS + Static Generator

If you need more structured content management — multiple authors, content types, editorial workflows — a headless CMS is the move. The CMS handles content editing (Contentful, Sanity, Strapi, or a dozen others). A static site generator (Eleventy, Hugo, Astro) pulls the content at build time and generates HTML files.

The result is the same: static HTML served to visitors. But editors have a proper CMS interface for managing content. The build step adds complexity, but it's automated — content changes trigger a rebuild and deploy.

This approach is more setup than WordPress. It's also more scalable, more secure, and more performant at every stage. For content-heavy sites with multiple contributors, it's the right architecture.

Option 3: Just Use Static HTML

For many sites, the honest answer is that nobody edits the content anyway. I've seen WordPress installations where the client logged in once after launch and never again. The blog has three posts from 2019. The homepage hasn't changed in two years. The client is paying for WordPress hosting, plugin updates, and security monitoring for a site that's effectively static already.

For these sites — and there are a lot of them — just build it as static HTML. The dog groomer's site doesn't need a CMS. The rental business site doesn't need a CMS. The marketing presentation site definitely doesn't need a CMS. Build it, deploy it, and it runs maintenance-free until the content actually needs to change. When it does, a developer makes the edit in five minutes.

The Performance Numbers

I'm not going to pretend this is a controlled study. These are real numbers from real sites I manage.

I'm not cherry-picking a bad WordPress example. That's a normal WordPress site. The fast ones are the exception, not the rule.

Security Is the Underrated Win

A static HTML file has no attack surface. There's no code executing on the server. There's no admin panel to brute-force. There's no database to inject. There's no plugin with an unpatched vulnerability. The web server delivers a file. That's it.

For any site that handles sensitive information or represents a business that can't afford downtime, the security argument alone is worth considering static.

When WordPress (or a CMS) Is Still the Right Call

I'm not saying WordPress should never be used. There are legitimate cases:

• E-commerce with WooCommerce — if you need a full online store with inventory management, WordPress + WooCommerce is still a reasonable choice. Shopify is better for most people, but WooCommerce has its place.
• Membership sites or LMS platforms — if users log in, have accounts, and interact with dynamic content, you need a dynamic backend. WordPress handles this fine.
• High-frequency content publishing — if you publish 5+ articles a week with multiple authors, the editorial workflow of a CMS earns its keep. Though at that volume, a headless CMS + SSG is probably better.
• Client insists on it — sometimes the client already knows WordPress, their team knows WordPress, and the switching cost isn't worth the technical benefits. Pragmatism beats purism.

How to Decide

Ask two questions:

1. Does anyone besides a developer actually need to edit this site regularly?

If no: static HTML. Ship it and move on.

If occasionally: flat-file CMS like Kirby. Simple, secure, and editors can update content without calling you.

If frequently, with multiple people: headless CMS + static site generator. More setup, but the right architecture for content-heavy sites.

2. Does the site need user accounts, e-commerce, or dynamic functionality?

If no: static or flat-file CMS.

If yes: you need a dynamic backend. Laravel, Rails, Django, or yes, WordPress. Match the framework to the complexity.