SECURITY · WORDPRESS

WordPress sites keep getting hacked: how to harden yours (and what to do long term)

WordPress powers a huge share of the web, which is exactly why it is the most attacked platform on the planet. The good news: most intrusions follow a handful of predictable routes, and you can close nearly all of them. Here is what really goes wrong, and how to fix it.

Why do WordPress sites keep getting hacked?

Let's be fair to WordPress first. It is not bad or careless software. It runs a large part of the world's websites, and its core is maintained by a dedicated security team that patches issues quickly. The reason WordPress dominates the hacking headlines is simpler than a flaw in the platform: it is the most popular content management system in the world, so it is also the most valuable and most automated target. Attackers write bots that scan millions of sites for the same known weaknesses.

And here is the part that matters most. The majority of successful intrusions do not exploit WordPress core at all. They come through plugins and themes that are outdated or poorly written, and through weak login credentials. A typical business site stacks a page builder, a contact form, an SEO tool and a dozen smaller add-ons on top of WordPress, each maintained by a different author on their own schedule. Every one of those is code running on your site, and any one of them can become the open door.

What should you check in your WordPress install?

We put together a list of the five most important things worth reviewing. We'll go through each of them point by point further down, but here they are up front so you know where we are heading:

1. The quality, source and publisher of your plugins
2. Installing updates frequently
3. Avoiding plugins you don't need
4. Disabling comments and open registration when you don't use them
5. Good username and password hygiene for every user

None of these requires you to be a developer. They are decisions and settings, and together they close the routes that automated attacks rely on. Let's take them one at a time.

Are your plugins from a trustworthy source?

Plugins are the single biggest source of WordPress vulnerabilities, so this is where hardening starts. The risk is straightforward: a plugin is third-party code that runs with full access to your site. If its author abandons it, writes it carelessly, or you downloaded a cracked copy from a random site, you have effectively invited unknown code into your system.

In practice: install only reputable, actively maintained plugins from a trusted source. The official WordPress plugin directory or a well-known commercial publisher are the safe starting points. Before you install anything, check three things: when it was last updated, how many active installations and reviews it has, and whether the author responds to support questions. A plugin that hasn't been updated in two years is a warning sign, no matter how useful it looks. And never install "nulled" or pirated premium plugins, which are a common vehicle for hidden malware.

Are you installing updates often enough?

Most vulnerabilities that get exploited are already known and already patched. The site got hacked because nobody applied the update in time. That gap between a fix being released and you installing it is the window attackers live in, and their bots move fast.

In practice: turn on automatic security updates for WordPress core, and update your core, plugins and themes on a regular, deliberate schedule rather than "when you remember". Many plugins support automatic updates too, which is worth enabling for anything non-critical. Before a larger update, take a backup so you can roll back if something breaks. The one honest caveat is that updates can occasionally cause compatibility problems between add-ons, which is precisely the maintenance tax that comes with a plugin-heavy site. But an unpatched plugin is a far bigger risk than a rare update conflict.

Are you running plugins you don't actually need?

Every plugin on your site is part of your attack surface, whether you use it or not. A deactivated plugin still has its files sitting on the server, and a vulnerability in those files can still be exploited in some cases. Plugins you installed once "to try" and forgot about are pure risk with no benefit.

In practice: audit your plugin list and be ruthless. If you are not actively using a plugin, delete it completely, do not just deactivate it. Fewer plugins means fewer authors to trust, fewer updates to track and fewer doors to guard. As a rule of thumb, if you cannot explain what a plugin does and why it is there, it should not be there. A lean install is a more secure install, and it usually loads faster too.

Should you disable comments and open registration?

Two features are switched on by default in many WordPress setups that most business sites never actually need: public comments and open user registration. Both are magnets for automated abuse. Comment sections attract floods of spam and links to malicious pages, and open registration lets bots create accounts on your site, which is a foothold attackers can build on.

In practice: if your site does not genuinely rely on visitor comments, disable them site-wide in the discussion settings. If you are not running a membership or multi-author site, make sure "anyone can register" is turned off, and set the default new-user role to the lowest privilege. These two changes cost you nothing in functionality and remove a whole category of automated attacks and spam. When you do need comments, require moderation and use a reputable anti-spam approach rather than leaving the gate open.

Do all your users have good password hygiene?

The most sophisticated hardening in the world is undone by one administrator using "password123". Automated attacks constantly try to guess logins by hammering the WordPress login page with common username and password combinations. If even one account uses a weak or reused password, that is the way in.

In practice, apply this to every user, not just yourself: use strong, unique passwords, ideally generated and stored in a password manager. Turn on two-factor authentication so a stolen password alone is not enough. Avoid the obvious default administrator username "admin", which is the first thing bots try. And review your user list regularly: remove accounts for people who have left, and give each remaining user only the permission level their role actually requires. The fewer high-privilege accounts you have, the fewer valuable targets an attacker can aim at.

What is the long-term fix beyond hardening?

Everything above works, and if you run WordPress you should do all of it. But it is worth being honest about what hardening actually is: continuous maintenance work that never removes the underlying problem. A WordPress site is still a large body of third-party code, a database and a login panel, all of which need watching. You reduce the risk, but you never make it go away, and the moment you stop keeping up with updates the risk climbs again.

That is why it is worth making a long-term plan to move off WordPress, and to adopt static pages instead. A static site is a set of pre-built files delivered straight to the visitor. There is no database to break into, no login panel to attack and no plugins running code on every visit. The attack surface is a fraction of a typical WordPress install. There are no weekly security patches to chase, and because the pages are just files, they can be served fast from a CDN.

The move does not have to be dramatic. A sensible, lightweight path looks like this:

• Inventory your current content: list the pages, posts and forms you actually use.
• Rebuild the equivalent as static pages, keeping the content and structure your visitors know.
• Redirect the old URLs to the new ones so links, bookmarks and search rankings carry over.
• Retire the WordPress install in a controlled way once the new site is live and verified.

Done in that order, nothing gets lost and nobody hits a dead link. This is close to the arc we describe in the history of websites: hand-coded static pages, the WordPress era, and now a static comeback made practical by better tooling. It is also, for what it is worth, exactly why we left WordPress behind for the small-business sites we build.

Frequently asked questions