Why I chose Hugo over WordPress for this blog

When I decided to start this blog, one of the first questions I had to answer was: which platform should I use? For many people, WordPress is the obvious choice—it powers over 40% of all websites on the internet, after all. Unlike many others, however, I’ve never really liked WordPress. Part of this stems from its terribly grown, unstructured codebase that has accumulated technical debt over nearly two decades. More recently, political turmoil within the WordPress project around the behavior of Matt Mullenweg and the company Automattic has further soured my view of the platform. After working with Hugo for a while now, I’ve found it suits my needs much better—particularly for static content like a personal blog.

What appeals to me about static sites

Hugo is a static site generator. Unlike WordPress, which dynamically generates pages on every request by executing PHP code and querying a database, Hugo pre-builds all pages during the build process. The result is a collection of simple HTML, CSS, and JavaScript files that can be served directly by any web server—no server-side processing required.

This difference is what drew me to Hugo in the first place.

Infrastructure: minimal overhead

With WordPress, you need a complete LAMP or LEMP stack: a web server, PHP runtime, and a MySQL or MariaDB database. Each component requires configuration, maintenance, updates, and monitoring. You need to worry about PHP version compatibility, database backups, and ensuring all components play nicely together.

Hugo eliminates almost all of this. All I need is a simple web server capable of serving static files. No database to back up, no PHP to update, no complex dependencies to manage. For someone who already spends enough time maintaining systems, this simplicity is genuinely refreshing.

Security: a smaller attack surface

The security aspect is what really convinced me. WordPress sites are constantly under attack. Vulnerabilities in the WordPress core, in themes, or in any of the thousands of plugins can provide attackers with entry points. The fact that PHP code executes on every request creates countless opportunities for exploitation—SQL injection, remote code execution, file upload vulnerabilities, and more.

With Hugo, there’s simply no code running on the server. Static HTML files can’t be exploited in the same way. I don’t have to worry about plugin vulnerabilities or about someone finding a way to inject malicious code. The attack surface is limited to the web server itself and potentially client-side JavaScript—both far smaller concerns than managing an entire WordPress installation.

Performance: fast by design

Because Hugo serves pre-built static files, performance is excellent. There’s no database query overhead, no PHP execution time, no template rendering on each request. The web server simply reads a file from disk (or from cache) and sends it to the client.

This also means the blog can handle traffic spikes without issues. There’s no database to overwhelm, no PHP processes to exhaust. For a personal blog, this level of performance is probably overkill—but it’s nice to know it’s there.

Learning curve and workflow

I won’t pretend that Hugo doesn’t have a learning curve. Understanding templates, shortcodes, and the build process takes some time. But for me, the trade-off has been worth it: complete control over the site’s structure, fast performance, minimal infrastructure, and better security.

That said, Hugo isn’t without its downsides.

The trade-offs: no built-in content management

The biggest downside is the lack of direct content editing within the blog itself. Unlike WordPress, content management shifts to editing local Markdown files and publishing via Git. For non-technical users, this workflow can feel cumbersome compared to WordPress’s web-based editor.

This limitation is solvable—there are headless CMS solutions that can provide a friendlier editing interface while keeping the benefits of static site generation. But that adds another layer of complexity that somewhat defeats the purpose of simplicity.

For my own use, the Git-based workflow is actually something I appreciate. Version control, offline editing, and working in my preferred text editor are things I value. But I understand this approach isn’t for everyone.