WordPress vs. Hugo: Why I Rebuilt This Site with Hugo
WordPress is easier to start. Hugo is worth it once you're tired of fighting the theme.
If you’ve been following along, you know Next Step Linux started life on WordPress. It’s now running on Hugo. This post is the “why” behind that switch — not as a blanket “WordPress bad, Hugo good” take, but as a rundown of what each one actually does well, and why Hugo ended up being the right fit for a distro-guide site run by someone who’s comfortable in a terminal.
The short version
WordPress is a full content management system: a database, a PHP application, an admin dashboard, and a huge ecosystem of themes and plugins. Hugo is a static site generator: you write content in Markdown, run one command, and it spits out plain HTML files you upload to a host. No database, no PHP, no admin panel — just files.
Both are excellent tools. They’re just built for different jobs.
How they compare
| WordPress | Hugo | |
|---|---|---|
| What it is | Dynamic CMS (PHP + MySQL) | Static site generator (single Go binary) |
| Editing content | Browser-based admin dashboard, block editor | Markdown files in a text editor |
| Hosting needs | PHP + MySQL support required | Any static file host — no server-side processing |
| Speed | Depends on hosting, caching, plugin bloat | Extremely fast — pages are pre-built HTML |
| Security surface | Database, PHP, plugins, themes all need patching | Almost none — there’s no live application to exploit |
| Customization | Themes + a huge plugin ecosystem | Full control over templates and markup, DIY for extra features |
| Learning curve | Low to start, low for non-technical users | Requires comfort with Markdown, terminal, and Git |
| Version control | Awkward — content lives in a database | Natural — content is just files, works great with Git |
| Comments, forms, search | Plugins handle this out of the box | Needs third-party services (Formspree, Disqus, etc.) or DIY |
Why WordPress made sense at first
WordPress is the obvious default for a reason. When I first set up the site, it got me a working homepage and post structure in minutes, no coding required. If your goal is “get a blog live today without touching code,” it’s hard to beat. The plugin ecosystem means almost any feature — contact forms, SEO tools, image optimization — is a few clicks away.
Where it started working against me
A few things kept nagging at me the more I used it:
- I was fighting the theme, not writing content. I write my guides as hand-crafted HTML/CSS — tables, code blocks, custom callouts. Every WordPress theme I tried injected its own styles, so I was constantly overriding CSS just to get my own markup to render the way I wanted.
- Overhead I didn’t need. A database, PHP runtime, and admin dashboard are a lot of moving parts for a site that’s fundamentally a collection of static guides. Every plugin and theme update is another thing that can break or need patching.
- Speed and hosting friction. Even with caching plugins, a WordPress site has more layers between a visitor’s request and the page they see than a static file ever will.
- It didn’t match how I actually work. I’m on Linux, comfortable in the terminal, and I already think in files and Git commits — not database rows and a browser-based editor.
Why Hugo won
- No fighting the CMS. Hugo takes Markdown and a template and outputs exactly the HTML I tell it to. There’s no theme CSS quietly overriding my tables, code blocks, or links.
- Speed, basically for free. Since every page is pre-built static HTML, there’s no database query or PHP processing on each request. Pages load fast without me having to think about caching layers.
- Security is a non-issue. There’s no admin login, no PHP, no database to exploit. The attack surface is close to zero because there’s no live application running — just files on a host.
- Git-native workflow. Every guide is a Markdown file. I can track changes, branch, and review history the same way I would for code — which fits a site about Linux and distros far better than a database-backed post editor.
- One binary, no dependency mess. Hugo ships as a single executable. No PHP version to manage, no MySQL to keep patched, no plugin compatibility matrix to worry about after an update.
- It fits the content. Distro guides are essentially structured technical documents — headings, tables, code blocks. That’s exactly what Markdown + a static template are built for.
What I gave up
To be fair to WordPress, moving to Hugo wasn’t free:
- No built-in comments, search, or contact forms — those now come from third-party services or get built by hand.
- No admin GUI — adding a post means creating a Markdown file and running a build, not filling out a form in a browser.
- Steeper entry point for anyone else contributing — a non-technical collaborator would need to learn Markdown and basic Git, where WordPress’s editor is friendlier for that.
For a solo, technical, terminal-first site like this one, none of that was a real cost. For a lot of other sites — a small business site, a client project, a blog for a non-technical writer — it would be a dealbreaker, and WordPress is still the better call.
The takeaway
There’s no universal winner here. WordPress is the right tool when you want a dashboard, plugins, and non-technical editing out of the box. Hugo is the right tool when you want speed, security, full control over your markup, and a workflow that lives in files and Git rather than a database. For Next Step Linux — a guide site built by someone who already writes raw HTML and lives in a terminal — Hugo was the obvious fit.