Why Static Site Generators Beat WordPress for Almost Everything I Publish
I still run about twenty WordPress installs and I have no plans to burn them down. WordPress is competent software. It solved publishing for people who never wanted to open a terminal, it outlasted two decades of fashion, and a big share of the web runs on it for reasons that are not nostalgia. I’ve patched enough of my own installs to know the thing works.
So take this as coming from someone with money on both sides of the table.
Static generators win. Not narrowly, and not on page speed, which is the boring argument everyone reaches for first. They win on the thing that actually costs me time.
Ask what the software does while you’re asleep
A Hugo site does nothing. The files sit in a folder, the HTML sits on Cloudflare’s edge, and six months later the site is byte-for-byte what I pushed. There is no process. There’s nothing to wake up.
A WordPress site is awake the entire time. Cron fires. Core phones home about updates. Plugin authors ship on their own calendar, and those versions arrive whether or not I asked for them. I lost most of a morning to Shortcodes Ultimate going from 7.5.0 to 7.5.1 and quietly changing behaviour across several sites at once. The fix was a rollback. Which is another way of saying the fix was to undo somebody else’s work on my property.
A static site can’t update itself into a bug, because nothing is running to update.
Ask where the post actually lives
On WordPress it lives in a database row. MySQL usually; SQLite on the installs where I run wp-sqlite-db, wrapped in whatever markup the editor felt like emitting that year. To get it out I export a WXR file and hope the importer on the other end agrees with me about attachments. My writing is a guest in somebody else’s schema, and the schema has opinions.
In Hugo the post is a file. content/posts/thing.md, frontmatter at the top, markdown underneath. If Hugo disappeared tomorrow the file is still a file, still readable in any text editor, still diffable, still in git with every revision I ever made. Moving a Hugo site to a different generator is an afternoon. Moving a WordPress site anywhere is a project with a name.
That’s the whole argument, really. The rest is consequences.
Ask what breaks
Hosting a static site costs nothing worth measuring. There’s no PHP process per visitor, so there’s no caching plugin bolted on to cache pages that were never going to change, and no cache to go stale and serve last week’s post to half the visitors. There’s no login form to be brute-forced every night by bots that will never stop. There’s no mu-plugins folder holding the custom PHP that keeps a theme from falling over.
My build is go run main.go on one site and hugo on most of the rest. Output goes to dist/ or public/, Cloudflare Pages picks it up from GitHub, and the failure modes are the kind you can read: a token expired, a build step didn’t run, a path was wrong. Compare that to diagnosing why a page renders differently for logged-out visitors on a Tuesday.
What I’m still not going to pretend
WordPress is better at the things static sites genuinely can’t do. Comments, without renting a third party. A media library that handles uploads and resizing so you never think about it. Someone who is not you logging in from a laptop and clicking Publish. Commerce, if you need it. Search that works out of the box instead of being a JSON index you generate and then argue with.
And one more admission, since I’d be annoyed if somebody else skipped it: I’ve written two of my own static generators. Fastpack in Go, single file, zero dependencies, powering about thirty-seven posts. Flatpack in Node, using marked, for a small blog. Both are a hobby. Neither is a recommendation. If you want out of WordPress, run Hugo and spend the saved hours writing.
The twenty installs I still have will stay where they are, because moving a live site costs more than tolerating it. Every new site goes static. That decision hasn’t been close for years.
The files are just sitting there.