One morning I opened the login stats for our own website and saw a number I wasn’t expecting. 429 failed login attempts. In a single day. A few days earlier the peak had been close to 900.
My first thought was probably the same one you’d have. Is the password too weak? Are we about to be hacked? But it turned out the problem wasn’t the password at all, it was something far more ordinary. And the fix needed neither an expensive security plugin nor a consultant.
This is about WordPress security for you as a business owner, not for a developer. What actually gets sites hacked, what can you do yourself in an afternoon, and what can you genuinely stop worrying about?
Where the risk actually sits
The first thing worth clearing away is a common feeling: that WordPress itself is insecure. That isn’t quite true.
The security firm Patchstack reviews every new vulnerability found in the WordPress world each year. For 2025, around nine in ten sat in plugins, with almost all the rest in themes. WordPress itself, the core, accounted for just a handful, all of them low severity. In other words, your risk lives in what you add on top of WordPress, not in WordPress itself.
You sometimes hear that WordPress accounts for an overwhelming share of all hacked sites. That’s true, but the figure is misleading. WordPress runs such a large slice of the web that it comes out on top even when you count fairly. It says more about how common it is than how secure it is.
So where does the risk sit, concretely? In two places: your plugins and your login. The rest of this article is about those two.
How the bots actually get in
They guess your password, but they need the username first
Most attacks on a small website aren’t targeted. They’re automated programs, bots, that probe thousands of sites at once around the clock. They simply try to guess their way in through the login page.
To log in, you need two things: a username and a password. And here our own mistake was instructive. WordPress was leaking our username for free, through two addresses anyone could open. A list of the site’s users, and an old link type that led straight to the account name.
So the bots already had half the key. They only had to guess the password. That’s why we were seeing hundreds of attempts a day.
The interesting part is the fix. We didn’t install a heavy security plugin to block the attempts. We closed the leak. A couple of lines of code in the theme shut those two addresses for visitors who aren’t logged in, so the username was no longer handed out for free. That didn’t make the site untouchable, and it doesn’t replace two-factor login or a limit on login attempts. But it removed information that should never have been left in the open. We treated the cause, not just the symptom.
A plugin has a hole
The other way in is through a plugin. Remember that nine in ten vulnerabilities sit right there?
Most plugins are perfectly fine. The problems start when a plugin stops being maintained. The developer loses interest, nobody patches the holes anymore, but the plugin stays installed and keeps working, apparently. It’s like a window that looks shut but has broken in the frame.
The worst are so-called nulled plugins, pirated copies of paid versions. They’re often free for a reason: someone has built in a backdoor. And in 2026 a real supply-chain attack showed why trusting a plugin is no longer only about how often it updates. An attacker bought up a plugin maker and planted a backdoor across dozens of the company’s plugins, which then activated through an ordinary update. That means the advice to “update everything” still holds, but no longer covers the whole distance. Fewer, carefully chosen plugins are a safer foundation.
What you can do yourself, without heavy plugins
The good news is that you can influence a lot of this yourself, without paying for a big security suite that grinds away in the background on every page load.
Clear out the plugins. Every plugin you don’t use is a door you don’t need. Go through the list and remove anything you don’t actively benefit from.
Check the health of the ones you keep. On each plugin’s page on WordPress.org you can see when it was last updated, how many people use it, and whether it carries a warning that it’s untested or closed. A plugin untouched for a year is a warning sign.
Protect the login. A long, unique password is the foundation, but the single strongest protection against guessing bots is two-factor login, a code from your phone on top of the password. Add a limit on the number of login attempts too.
Keep PHP current. PHP is the engine that runs WordPress, and an old version is both slower and less secure. More on that shortly.
Notice what isn’t at the top of the list: “install a big security plugin.” For a simple business site that’s often more than you need, and the measures we used are a few lines of code that only run where they’re needed, with no noticeable effect on how fast the site loads. If you run a webshop, a membership site, or a site with many users, a proper security layer can be well worth it. The point is to choose by need, not out of worry.
The parts that need a little more
Some of security isn’t a one-off fix but something that has to be kept alive. Three things are worth a look of their own.
The PHP version. Most WordPress sites actually run a version of PHP that no longer gets security updates. As a rule of thumb, a business site in 2026 should be on PHP 8.3 or newer. You can usually see which version you’re on under Tools and Site Health in WordPress, and switching is often a couple of clicks at your host. But it should be tested first, so nothing stops working.
Updates without crashing the site. Hitting “update all” straight on the live site is the most common way to accidentally break something. Security updates should go in quickly, but larger updates do better tested on a copy first.
Backups you can actually restore. A backup is worthless the day it won’t roll back. What matters isn’t only that copies exist, but that someone checks now and then that they really work.
See the pattern? This is ongoing work, and that’s exactly why many people choose to hand it to someone else.
When the plugins themselves become the risk
Sometimes the answer isn’t a better plugin, but fewer plugins.
As a site grows it’s easy to accumulate a plugin for every little feature. One for forms, one for booking, one to show reviews, one for a calendar. Soon a handful of different developers each run a piece of your website, and each one is a possible way in. The average site runs between twenty and thirty plugins.
For recurring, business-critical functions, it can then pay off to build your own custom solution instead. One thing to keep track of instead of five, built to do exactly what you need, without a foreign update channel running straight into the site.
But be honest with yourself about when it doesn’t pay off. For everyday functions like forms, payments, or search-engine optimisation, a mature, well-maintained plugin is usually safer than custom code only one person understands. The goal is a small, vetted set of plugins, not zero.
If the worst does happen
Imagine a site with a contact form or a shop gets hacked. Then it isn’t just your own downtime at stake, it’s your customers’ data.
In the eyes of the law it can be a personal data breach. And then a clear deadline applies: a serious breach normally has to be reported to the supervisory authority within 72 hours of you discovering it. In some cases you also have to tell the customers affected.
This deserves its own walkthrough, and we cover the whole sequence in a separate article. But the point here is simple: security on a business site isn’t only about the site. It’s about the trust of the people who handed you their details.
Frequently asked questions
Do I need a security plugin like Wordfence?
Not necessarily. A plugin like that can help, but it runs on every page load and can weigh the site down. For an ordinary business site, much of the same protection can be reached with lightweight measures: closing leaks, limiting login attempts, and turning on two-factor. Heavy suites are rarely wrong, but they’re often more than you need.
Is WordPress insecure?
No, not in itself. The vast majority of vulnerabilities sit in plugins and themes, not in WordPress. A well-kept WordPress site with few, updated plugins and a protected login is perfectly safe for a business.
How do I know if my site is hacked?
Common signs are the site suddenly showing strange ads or text, Google warning visitors, the site going slow for no reason, or you no longer being able to log in to the admin. If you’re unsure, it’s better to have someone look than to guess.
Do I have to report a breach?
Usually yes, if the breach is likely to create a risk for the people affected. If the site collects personal data and it leaks in a break-in, it normally counts as a personal data breach that must be reported to the supervisory authority within 72 hours of you discovering it. In more serious cases the affected customers must be informed too.
How often do I have to update?
Security updates should go in as soon as they arrive, because holes are exploited fast. Larger updates do better tested first. In practice that means a check at least every month, ideally more often.
Want to know where your site stands?
The nice thing about a site that’s looked after is that security never has to become a crisis. It becomes a quiet habit in the background, while you get on with what you actually run a business to do.
If you’re not sure how your site is doing right now, we’re happy to look at the essentials: your plugins, your login, and your PHP version. Get in touch, and we’ll tell you straight what needs attention and what you can safely leave as it is.
Last updated: June 2026. The security landscape shifts, so individual figures and recommendations may change over time.