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. It is bulk, not malice.
That distinction matters, because it changes what the defense looks like. You are not trying to outsmart a person who chose you. You are trying to not be the easy match in a list of millions. That is mostly a maintenance problem, and maintenance problems have boring, reliable answers.
What is actually knocking on the door
A vulnerability gets disclosed in a plugin. The plugin author ships a fix. The disclosure is public, because that is how the ecosystem works — researchers publish, 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 is checking a version string. If it matches, it tries the exploit. If it works, it drops a file. If it does not, it moves on within milliseconds. Your traffic numbers, your industry, and your revenue are irrelevant to this process.
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 quietly burns your domain reputation, or a backdoor left in place for later. Ransom demands and defacement exist but they are the minority. Most compromises are quiet, because quiet lasts longer.
The real causes, roughly ranked
This is the order we actually 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 the overwhelming first place. Not exotic zero-days — bugs that were 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 is quieter than a plugin bug but it widens everything else.
- 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. This is not a moral point, it is a mechanical one.
- Weak neighbors on shared hosting. Real, but rarer than the internet suggests, and largely a function of how the host isolates accounts.
Notice what is not on this list: sophistication. Almost every compromise we have cleaned up traces back to something that had a published fix available before it happened.
The update-lag window is the whole game
Here is the timeline that decides whether you get hit. 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 when you happen to log in, your exposure is however long that is — and for most small businesses, honestly, it is measured in seasons. If updates get applied within a day or two, the window mostly closes before the scanners arrive.
That is the entire mechanism. Patching cadence is not one security measure among many. It is the measure. Everything else is 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. Mild reduction in log noise. Not a defense. Scanners find it.
- 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. Useful for detection, useless as prevention, and it will not un-inject the 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. They are just downstream of the thing that matters, and they let people feel finished when they are not.
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 — not backups sitting on the same server as the site they are meant to rescue. Ours run twice daily, verified, off-site, with 30-day retention. Thirty days matters more than people expect, because a quiet backdoor can sit unnoticed for weeks, and a seven-day window means 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 are 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.
That order matters. Restore, then patch. A restore alone puts the vulnerable plugin right back and the same scanner returns.
How we handle this
We patch. That is the unglamorous core of it: 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 will not survive the update — a person looks at it rather than a cron job pushing it through and breaking your checkout. That is 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. Nothing visibly breaking is not the same as nothing being wrong. It is just the part before.
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 quiet — 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 is not the thing that saves you. 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 — a place to host spam, send mail, or park a redirect. Being unimportant is not a defense, which is oddly reassuring: the fix is the same boring maintenance either way.
