Most WordPress sites don't need WordPress. They need a few pages of text, a contact form that emails someone, a picture on the homepage, and a blog index that almost nobody scrolls past page one of. The stack they're running to serve that content is a PHP interpreter, a MySQL database, a theme framework, twenty plugins on staggered update cycles, and a continuous low-level war against the bots knocking on /wp-login.php. The server costs fifteen dollars a month when things are quiet, and occasionally falls over when they aren't.
A static site built with Hugo serves the exact same content from a CDN for nothing, loads in a fraction of the time, and has no admin URL to defend. That's not a niche case. It's most of the web.
Static generators like Hugo, Zola, and Eleventy have been the right default for brochure sites, blogs, docs, and portfolios for years. The one argument that held back wider adoption was that WordPress was easier to set up for someone who didn't want to learn anything. That argument is gone now, because an LLM can scaffold a themed Hugo site in a single prompt. What's left is the comparison on the things that always mattered: performance, cost, security, and complexity. WordPress loses all four.
01. FOUR PAGES, FORTY KILOBYTES
Load a vanilla WordPress install in a browser. The initial HTML is around 60KB before anything dynamic has happened. Add the theme's CSS and JS and the page crosses 400KB before a single image. Time to first byte on a cold request against a modest VPS sits somewhere between 400 and 700ms, because the server is booting the PHP interpreter, opening a database connection, executing the theme's templates, and rendering markup on every request that doesn't hit cache.
A Hugo site with a stock theme serves a similar-looking page in roughly 40KB of HTML and CSS combined. The server isn't rendering anything. The CDN hands over a prebuilt file. TTFB is typically under 50ms because the response is already on the edge, sitting in front of the user's network. Core Web Vitals scores fall out of this for free. LCP under 2.5 seconds is trivial when the HTML is pre-rendered and the critical CSS is inline.
This isn't a framework vs framework benchmark. It's rendering vs not rendering. WordPress decides what the page looks like on every request. Hugo decided at build time and the decision is frozen into the file you're reading. For a site that updates once a week, rendering on every request is pure waste.
02. THE HOSTING BILL
Cheapest plausible WordPress hosting is not free. Managed WordPress starts at eight to fifteen dollars a month for a single site, and that's before you hit a traffic tier, decide you want automatic backups, or add a staging environment. A raw VPS is cheaper per box, but now you own the security updates, the database backup job, and the 3am reboot when the LAMP stack falls over.
Static hosting is free until the traffic is absurd.
Cloudflare Pages, Netlify, and Vercel all have free tiers that cover roughly 100GB of monthly bandwidth and unlimited requests. For a personal site, a small business brochure, or a developer blog, you will never reach those limits. If your site gets linked on Hacker News and takes a million requests in two hours, the static bill is still zero. A WordPress site on a fifteen dollar VPS is unreachable for the entire time the link is trending, because the PHP workers are busy rendering the same homepage over and over.
The scale curve is what's interesting. WordPress costs grow roughly linearly with traffic, because you're buying CPU to render pages. Static costs are flat, then step up once you cross a free tier. Most sites never cross it. The ones that do are paying tens of dollars a month for traffic that would have cost hundreds on managed WordPress.
03. THE ATTACK SURFACE
Patchstack's State of WordPress Security in 2026 report logged 11,334 new WordPress-related vulnerabilities in 2025, a 42% jump on the year before. Ninety-one percent of them landed in plugins. Core took six in total, all low priority. And 46% of the disclosures arrived with no patch available on the day they were published, meaning nearly half of every year's findings are live in the wild with nothing to install to fix them. A typical install runs twenty plugins from nineteen different authors, each on their own release cadence, each able to execute arbitrary PHP on your server the day one of them ships a bad version.
The attack surface of a Hugo site is the CDN.
That's the whole sentence. There is no database, no PHP runtime, no admin login, no XMLRPC endpoint, no user accounts, no plugin ecosystem. Compromising a static site means compromising Cloudflare or Netlify, and if that happens, the WordPress installs on those same providers have bigger problems too.
TIP
Every installed WordPress plugin is a supply chain dependency with commit access to your server. A plugin that stops receiving updates doesn't get removed automatically. It sits in wp-content accumulating known vulnerabilities while continuing to run on every request.
Maintenance reduces to the same shape. WordPress asks for attention in two places. Core updates, which are usually fast and safe. And plugin updates, which are neither. A plugin abandoned by its author turns into a silent liability that nobody on the support forum is going to fix for you. You either audit the code yourself, swap the plugin for a maintained alternative, or accept the risk.
A Hugo site needs the Hugo binary updated occasionally. That's a binary swap. If a theme is abandoned, the site still works forever, because the theme has already done its job at build time. The generated HTML has no runtime dependency on anything, and nobody can push a compromised update to a file that's already sitting on a CDN.
This is the axis where the WordPress argument is weakest, and it's the one people routinely underweight. Every running WordPress install is an ongoing commitment to patch discipline. Every static site is a folder of files that will still load in ten years if the hosting account still exists.
04. WHAT YOU ACTUALLY OWN
Open the hood on a WordPress site and count the moving parts. The platform is PHP, at a specific version range that you probably didn't pick. A web server, usually Apache or nginx, configured to hand requests to PHP. A database, usually MySQL or MariaDB, tuned for whatever plugins you installed. A theme, which is itself a collection of PHP templates and a compiled CSS bundle. Plugins, typically between fifteen and thirty, each carrying JavaScript, CSS, and database tables. A caching layer, because the default rendering path is too slow to be used unaided.
A Hugo site is a single binary, a folder of Markdown, and a theme that's usually a Git submodule.
my-site/
├── config.toml
├── content/
│ ├── _index.md
│ ├── about.md
│ └── posts/
│ └── 2026-04-15-hello.md
├── layouts/
├── static/
│ └── images/
└── themes/
└── ananke/ (git submodule)You can list every file that contributes to the output. hugo reads the content directory, applies the theme's templates, and writes HTML to public/. That's the entire build system. There is no state outside those files.
The architect's question isn't which is more powerful. WordPress is more powerful. The question is which you can still understand in two years. WordPress drifts. Plugin versions move independently, the database schema accumulates rows from plugins you removed, the PHP version gets forced up by your host, the theme gets patched or doesn't. By year three, nobody on earth can tell you exactly what's running on the server. A Hugo project looks the same in year three as it did on day one, because it's a directory of text files and a tool that converts them.
That's what local-first means for websites. You own the canonical content as Markdown, the build tool is a single open source binary, and the output is vanilla HTML. You never bought anyone's platform.
05. WHERE STATIC ISN'T ENOUGH
Worth being honest about where the argument breaks down.
There are legitimate reasons to reach for a dynamic runtime, and WordPress is one option among several for each of them. Membership and paywalled content need server-side logic. WordPress can handle that, and so can Ghost, Memberful, or a small custom application. Busy comment sections need real-time moderation. WordPress can do it, and so can Disqus, Discourse, or hosted widgets like Giscus bolted onto a static site. E-commerce at scale needs catalogs, cart state, and payment flows, and for most storefronts Shopify is the more pragmatic answer than WooCommerce. It ships payments, inventory, and tax compliance as a managed service instead of a plugin stack. BigCommerce and Squarespace Commerce cover similar ground.
The last real pull toward a full CMS is the non-technical editor. When the person maintaining the site is going to live inside the admin panel every week and a Git workflow is the wrong abstraction for them, WordPress works. So do Ghost, Webflow, and Squarespace. Headless CMSs like Sanity, Decap, and TinaCMS sit in the middle ground, pairing a familiar admin UI with a static build pipeline so the output is still a folder of HTML on a CDN.
These are all real use cases. None of them has a single correct answer. And they're still a small fraction of the WordPress installs currently running on the internet. The rest are blogs that update once a month, brochures that don't update at all, and small business pages that were set up once and haven't been touched since. For all of those, static is enough.
06. THE LAST MOAT
Until recently, the honest answer to "why WordPress" for a non-technical user was that it shipped with a theme picker, a visual editor, and a plugin store. Setting up a Hugo site required cloning a repo, editing TOML, and understanding how templates worked. That friction was the real moat.
The moat is drying up fast. A single prompt to a capable LLM now produces a Hugo site with a chosen theme, a styled homepage, a blog index, an about page, and an RSS feed, ready to drop onto Netlify by dragging the folder into a browser. The entire setup that used to take a technical evening now takes a chat. The LLM is also the one who debugs the site when the user reports "it looks broken on my phone", and the user never needs to learn how templates work because they can ask for changes in English.
This doesn't kill WordPress outright. Plenty of people will keep using it, and the WordPress economy around themes, hosting, and agency work is not going anywhere soon. But the one argument that defended WordPress against static for most of its addressable market is gone. WordPress was easier because humans were slow. The humans aren't slow anymore.
THE LESSON
Static is enough for most of the web because most of the web is text with occasional pictures. The reasons to pick WordPress are real, but they describe a minority of the sites currently running it. Every other site is paying for a dynamic runtime to serve content that doesn't change between requests. That runtime gets paid for in hosting costs, update cycles, and a security posture that needs tending on a schedule.
If you're starting a new personal site, a blog, a docs page, or a small business brochure, pick a static generator. Ship it on a free CDN. Update it when there's something to say, and leave it alone when there isn't. That used to be the harder path. It isn't anymore.
