Almost no small business gets hacked on purpose. Sites get hacked by automated scanners that crawl the whole internet looking for a known-vulnerable plugin, a reused admin password, or an install nobody has updated in a year.
That changes what the defense looks like. Since nobody picked you, there's no one to outsmart. You only need to avoid being an easy match in a list of millions. That's mostly a maintenance problem, and maintenance problems have boring, reliable answers.
What's knocking on the door
A vulnerability gets disclosed in a plugin. The plugin author ships a fix. The disclosure is public, because that's how the ecosystem works: researchers publish and sites update. Within a day or two, someone writes that vulnerability into a scanning tool, and that tool starts working through every WordPress site it can find, checking whether the old version is still in place.
Nobody is reading your homepage and deciding you look worth the trouble. A script checks a version string, and if it matches, it tries the exploit. If that works, it drops a file, and if not, it moves on within milliseconds. Your traffic, your industry and your revenue don't come into it.
What happens next is usually mundane and commercial: spam pages injected into your site to sell counterfeit goods, redirects that send mobile visitors to a scam, a mailer that burns through your domain reputation, or a backdoor left in place for later. Ransom demands and defacement exist but they are the minority. Most compromises are built to go unnoticed, because that way they last longer.
The real causes, roughly ranked
This is the order we see when we take over a site that has been compromised, or is about to be.
- Out-of-date plugins with a public vulnerability. This is by far the most common cause, and it's rarely an exotic zero-day. Usually it's a bug that was patched weeks or months ago on a site where nobody applied the update.
- Plugins and themes that are installed but abandoned. Either abandoned by you (deactivated and left sitting there, still on disk, still reachable) or abandoned by the developer, who stopped shipping fixes two years ago. Deactivated does not mean gone.
- Reused or weak admin passwords. Credential stuffing is cheap. If an address and password of yours leaked in some unrelated breach, bots will try that pair against your login form along with everyone else's.
- Stale core and stale PHP. Running an old PHP version means running one that stopped getting security fixes. It's less obvious than a plugin bug, but it makes every other weakness worse.
- Too many admin accounts. The contractor from 2021, the agency that redesigned the site, the intern. Every one of them is a door, and you do not control their laptops.
- Pirated premium plugins. The free download of a paid plugin is free because someone added something to it.
- Weak neighbors on shared hosting. Real, but rarer than the internet suggests, and largely a function of how the host isolates accounts.
None of these are sophisticated. Almost every compromise we have cleaned up traces back to something that had a published fix available before it happened.
Update lag is the main risk
The timeline that decides whether you get hit goes like this. A vulnerability is disclosed and patched. Exploitation attempts start appearing in the wild, often within days, sometimes within hours for a widely-installed plugin. Your site is exposed for exactly as long as it takes you to apply that update.
If you update monthly, your average exposure is about two weeks per vulnerability. If you update whenever you happen to log in, you're exposed for however long that takes, which for most small businesses is measured in seasons. If updates get applied within a day or two, the window mostly closes before the scanners arrive.
Patching cadence is the main security measure, and everything else comes a distant second. We wrote more about what a real maintenance routine covers in what website maintenance should include, because the same cadence that keeps a site secure is the one that keeps it working.
What does not help much
Some things sold as security are fine but marginal. We would rather say so plainly than let you feel protected by them.
- Renaming the login URL. It cuts down log noise a little, but scanners find it, so it isn't a defense.
- Hiding the WordPress version number. The exploit does not read the version. It just tries the payload.
- Changing the database table prefix. Popular advice, near-zero effect against modern attacks, and a decent chance of breaking a plugin.
- Malware scanners as the primary plan. A scanner tells you after the fact. It helps with detection but does nothing to prevent an attack, and it won't remove the injected spam pages.
- A security plugin bolted on top of an unpatched site. Adding a firewall while leaving a nine-month-old vulnerable plugin in place is putting a lock on a door that is not attached to a wall.
None of these are scams, but they come a long way behind patching, and they let people feel finished when they aren't.
What does help, in order
Update fast, and update everything: core, plugins, themes, and the PHP version underneath. Delete what you do not use, rather than deactivating it. Give every person the smallest role that lets them do their job, and remove accounts when people leave. Use unique passwords and two-factor on admin accounts. Keep the number of plugins reasonable, because every plugin is a supply chain you did not audit.
Then assume it might happen anyway, and make that survivable. That means backups you have actually restored from, kept somewhere other than the server they're meant to rescue. Ours run twice daily, verified, off-site, with 30-day retention. Those 30 days count for more than people expect, because a backdoor can sit unnoticed for weeks, and with a seven-day window your clean copy is already gone. There is more on the mechanics in backups, monitoring, and recovery.
Why snapshots turn a disaster into an afternoon
The difference between a bad week and a bad hour is whether you have a clean copy and someone competent to roll back to it. Cleaning an infected site by hand is slow, uncertain work: you're hunting injected files, checking for a second backdoor and hoping you found the last one. Restoring a verified snapshot from before the compromise, then patching the hole that let it in, takes minutes.
Get the order right: restore, then patch. A restore on its own puts the vulnerable plugin right back, and the same scanner returns.
How we handle this
Mostly, we patch. Updates get applied on a schedule that closes the window, and when something needs judgment (a major version bump, a plugin that conflicts, a theme that won't survive the update), a person looks at it rather than a cron job pushing it through and breaking your checkout. That's what maintenance and security means here.
If a site arrives already infected, we say so, quote the cleanup before doing it, and get on with it. If something goes wrong later, you email us and a real engineer answers the same day. There is no ticket queue to shout into.
Most sites we take over have at least one plugin with a known vulnerability sitting on it, and the owner had no idea, because nothing had visibly broken yet.
Frequently asked questions
Would I know if my site had been hacked?
Often not, for a while. Defacement is obvious, but the common outcomes are hard to spot: spam pages on URLs you never visit, redirects that only fire for mobile or search traffic, or a backdoor doing nothing yet. The usual first signals are a Google Search Console warning, a sudden drop in search traffic, or your email starting to land in spam.
Do I need a security plugin?
It won't save you on its own. A firewall and login rate-limiting are reasonable additions on a site that is already patched and has clean admin accounts. On a site that is nine months behind on updates, a security plugin is decoration. Fix the cadence first, then decide whether you want the extra layer.
My site is small. Why would anyone bother?
Nobody chose you. Scanners work through the entire address space without regard to who you are, and a small site is worth the same to them as a large one: somewhere to host spam, send mail, or park a redirect. Being small won't protect you, which is oddly reassuring, because the fix is the same boring maintenance either way.
