I spent years on WordPress. Not because I loved it—because I didn’t think about it. WordPress was the default. Need a blog? WordPress. Help center? WordPress. German-language reference site about the command line? Sure, WordPress. It’s what everyone uses, right?
And for a while, it was fine. I didn’t think about it much, which is exactly how problems accumulate.
The wake-up call came on a Tuesday in December, when I SSH’d into my server and discovered that WP Total Cache had silently accumulated gigabytes of cached files. Not megabytes. Gigabytes. For a personal blog with modest traffic.
The Plugin Tax
Here’s the thing about WordPress that nobody warns you about when you install it for the first time: the platform itself does almost nothing. Want pretty URLs? Plugin. Want your site to load in under four seconds? Plugin. Want to not get hacked this week? Plugin. SEO? Plugin. Contact form? Plugin. Backups? Plugin.
Before I knew it, I was running a dozen plugins on a site that published maybe ten blog posts a year. Each plugin with its own update cycle, its own settings page, its own idea of what my database schema should look like. Some played nice together. Some didn’t. I spent more time maintaining the infrastructure than writing actual content.
And the real kicker? Half those plugins existed solely to fix problems that WordPress itself created.
The Cache Monster
WP Total Cache deserves its own section because it was the single most counterproductive piece of software on my server. Its job—in theory—was to make WordPress fast. In practice, it layered page caches, database caches, object caches, browser caches, and minified asset caches on top of each other. Each cached copy multiplied across every URL, every query string variation, every logged-in-versus-logged-out state.
The result? A /wp-content/cache/ directory that kept growing. Gigabytes of files, sitting there, for a site that could have been served as a handful of static HTML pages from the start.
The cache was larger than every piece of actual content I’d ever written combined.
The Security Treadmill
Running WordPress in production means constant maintenance. New vulnerability in a plugin? Update now. Core security patch? Update now. PHP version no longer supported? Update everything now.
I’d log into the admin panel and see a little red badge—three updates available. Except ignoring these could mean someone injects a crypto miner into your help pages.
For a solo developer who just wants to publish a blog post every few weeks, this is an absurd amount of operational overhead.
The Breaking Point
The tipping point wasn’t a single catastrophic event. It was the slow, creeping realization that I was spending more time on WordPress maintenance than on actual content. Updating plugins, clearing caches, monitoring security alerts, debugging weird PHP errors after an update broke something.
I’d sit down to write a blog post and end up clicking through plugin updates and cache settings instead.
At some point I stepped back and thought: I’m a developer. I write HTML, CSS, and PHP for a living. Why am I running a database-driven CMS with a WYSIWYG editor I never use, behind a caching layer that generates more data than my actual content, protected by security plugins that wouldn’t be necessary if I weren’t running WordPress in the first place?
The answer was inertia. Pure, comfortable inertia.
Enter Hugo
Static site generators had been on my radar for years—I just never had a strong enough reason to make the switch. That changed when I actually tried Hugo.
Hugo takes Markdown files, runs them through templates, and spits out plain HTML. No database. No PHP runtime. No plugin ecosystem. No admin panel. No cached copies of cached copies. Just files.
The mental model is so simple it’s almost insulting after years of WordPress complexity: you write content in Markdown, you define your templates in HTML, you run a build command, and you get a folder of static files ready to upload.
My entire blog—every post, every page, every asset—builds in under a second. The output is a directory of HTML files that any web server can serve without breaking a sweat. No .htaccess rewrites to route requests through index.php. No database connections. No PHP process spinning up for every page view.
Three Sites, One Month
Once I decided to make the switch, I didn’t ease into it. I migrated three websites to Hugo in January 2026.
blog.dominicrodemer.com went first—New Year’s Day, because apparently that’s how I celebrate fresh starts. Posts migrated, Bootstrap 5 theme built from scratch, full-text search added via SQLite FTS5. The entire migration took a single day.
help.pdf-pro.net came next, and this one was the real challenge. A help center with dozens of articles in eleven languages. WordPress had been handling this with a multi-language plugin that I’d rather not name, and the migration required a completely different content organization strategy. A few days of focused work.
kommandozeile.org followed mid-January. A German-language command-line reference site. I imported the existing articles from a WordPress SQL dump and then kept adding more, because creating content is suddenly fun again when you’re not fighting your CMS.
What I Actually Gained
The benefits weren’t theoretical. They were immediate and tangible:
Speed. Pages that WordPress had to render on every request now load instantly. They’re static files. There’s nothing to render.
Security. Static HTML files can’t be hacked through a plugin vulnerability. There’s no admin panel to brute-force. No database to inject into. The attack surface shrinks to almost nothing.
Simplicity. My deployment is rsync with checksums. Changed files get uploaded. Unchanged files don’t. No clearing caches, no warming caches, no wondering if the cache is showing stale content.
Version control. Every post, every template, every config change lives in Git. I can see exactly what changed, when, and why. Try getting that kind of history out of a WordPress database.
Cost. Server requirements dropped. No PHP workers, no MySQL, no memory-hungry caching layers. Just a basic web server serving files.
Creative velocity. This one surprised me. When the overhead disappears, writing becomes enjoyable again. I published more content in the weeks after migrating than in the years before on WordPress. Partly because I had a backlog—but mostly because the friction was gone.
The Honest Tradeoffs
I’m not going to pretend Hugo is perfect for everyone. If you need a contact form, you’ll need a separate solution. If you want non-technical people to edit content, they’ll need to learn Markdown and Git (or you’ll need to set up a CMS frontend like Decap). If you rely on WordPress plugins for e-commerce, membership sites, or complex workflows—yeah, Hugo isn’t going to replace that.
But for a developer running a personal blog, a documentation site, or a content-heavy reference site? WordPress is massive overkill.
What’s Next
This is the first post in a series about my WordPress-to-Hugo migration. In the next posts, I’ll get into the practical details—how to actually export your WordPress content and set up Hugo from scratch, build a search system without a database-driven CMS, and handle multi-language sites with localized URLs. The real how-to stuff.
If you’re a developer running WordPress and have that nagging feeling that there has to be a better way—there is. And it’s simpler than you think.