Skip to main content

Static Sites vs WordPress: Security by Design - Part 7

Part 7: How moving from WordPress to Hugo dramatically reduced security risks. From constant vulnerability patches to peace of mind by design.

4 min read
849 words
Static Sites vs WordPress: Security by Design - Part 7

If there’s one reason above all others why I walked away from WordPress, it’s security.

I’ve been hacked twice before: once at the AWS account level, and once directly through WordPress. Both were painful experiences that left me wary of running my own infrastructure. Rebooting this blog gave me the chance to rethink things from the ground up. This time, security wasn’t going to be something I patched after the fact. It was going to be baked in by design.

Previous posts in this series:

WordPress and Its Attack Surface

To be fair, WordPress isn’t inherently insecure. It powers a huge part of the internet and has a large community constantly fixing issues. But its popularity also makes it one of the most frequent targets.

When I ran WordPress, there were countless potential entry points:

  • Brute-force attacks on the login page
  • Vulnerabilities in plugins (and I had many)
  • SQL injections through forms or poorly configured themes
  • Outdated PHP versions on my server
  • Spam bots hammering the comment system

The result? A constant background hum of risk. I had to keep plugins updated, manage backups, and stay alert to suspicious behavior. And even then, I still got hacked.

Static Sites: A Different Approach

Moving to Hugo completely changed the equation. A static site, by definition, has no database, no backend, and no dynamic forms for attackers to exploit. What you see when you load the site is all there is: plain HTML, CSS, and JavaScript served through a CDN.

In other words, the attack surface shrinks dramatically.

  • No login page means no brute-force attempts
  • No plugins means no plugin vulnerabilities
  • No database means no SQL injection
  • No server side scripts means no hidden exploits waiting to be discovered

That doesn’t make a static site invincible, but it does make it a lot harder to attack.

The New Security Model

Running a static site doesn’t mean you can ignore security: it just shifts where you need to focus.

Here’s what I pay attention to now:

Repository security

My blog’s code lives on GitHub. That means enabling two-factor authentication, using strong access keys, and keeping my local environment secure.

Hosting security

Netlify takes care of a lot: HTTPS by default, protection against common attacks, and global distribution through a CDN. The responsibility is lighter but not gone.

DNS and domain

A weak DNS setup can undermine even the most secure site. I make sure domain registrar accounts are locked down with 2FA, and DNS settings are configured properly.

Content integrity

Even though Hugo generates static files, I still commit everything to Git. That gives me an audit trail and confidence that nothing sneaky slips into the codebase.

The Peace of Mind Factor

The biggest change isn’t technical: it’s psychological.

When I ran WordPress, I always had the nagging thought that something might break or get compromised. I dreaded plugin updates. I feared waking up to emails telling me my site was being used as part of a spam botnet (which, unfortunately, did happen).

With Hugo and Netlify, that weight is gone. There’s nothing to exploit in the same way. I can focus on writing instead of worrying.

That peace of mind is worth more than all the fancy dashboards and plugins in the world.

Takeaway for Readers

Security should be part of your blog’s design, not an afterthought. If you’re deciding between WordPress and a static site generator, think about:

  1. How much time do you want to spend patching, updating, and monitoring?
  2. How much risk are you willing to take on?
  3. Do you want to focus on content, or on defending infrastructure?

For many people, WordPress is fine. But if you want simplicity and security, a static site is hard to beat.

Final Thoughts

Rebooting my blog wasn’t just about making it faster or easier to host. It was about feeling safe again.

Security by design means that the choices I made (Hugo, Netlify, GitHub) naturally reduce risks instead of adding new ones. It’s not bulletproof, but it’s lean, simple, and strong enough for what I need.

And this time, I’m confident the site won’t end up as part of someone else’s spam network.


Series navigation:

What’s your approach to blog security? Have you experienced security issues with WordPress or other platforms? I’d love to hear about your security strategy and what measures you find most effective.

Share this post

Irhad Babic

Irhad Babic

Practical insights on engineering management, AI applications, and product building from a hands-on engineering leader and manager.