Hardly any small business site is attacked by a person: it is found by a program testing known flaws against millions of addresses. And the flaw is almost always in a plugin installed two years ago, no longer maintained by anyone, still active because nobody remembers what it was for.
When a small business gets its site hacked, there is almost never someone on the other side who chose it. What there is, is a program crawling the internet, testing a list of already-published flaws against millions of addresses, and finding yours because it runs an old version of a plugin somebody installed two years ago to add a contact form. It is not personal. That is precisely why it is so common.
Every plugin is somebody else's code holding your keys
A WordPress site with twelve plugins is a site running code from twelve different teams with the same permissions as the site itself: they can read the database, write files and create users. None of them is shut inside its own box. So the security of the site is not that of the best-built plugin, but that of the worst of the twelve.
And the plugin does not need to be bad. Nearly all of them are written in good faith; the thing is that a gallery, a form or a visual builder are large pieces of software, and all large software has flaws discovered after release. The difference between a healthy plugin and a dangerous one is not whether it has flaws: it is whether somebody is fixing them.
The abandoned plugin is the real problem
The typical case is not a plugin with a bug. It is a plugin whose author stopped maintaining it three years ago and which is still installed and active because nobody remembers what it was for. When the flaw turns up there is no update to install: there is nobody on the other side.
Checking takes ten minutes. Open the plugin list and look, one by one, at when each was last updated and whether it claims to have been tested with your version of WordPress. Anything untouched for over a year is a candidate for removal. And removal means deleting it, not deactivating it: a deactivated plugin is still files on the server, and a good share of known flaws are exploited just the same without it being active.
What you have installed is visible from outside
Plenty of owners assume a small site is of no interest to anyone, which is true, and which protects nothing: the programs doing the scanning do not tell a small site from a big one, only a vulnerable one from a patched one. And working out what you have installed is trivial, because plugins leave their name and version in the code that serves the page, in the paths of their own stylesheets and in the text files they ship with.
Which means the list of your plugins and their versions is public, and on the other side there is a public list of known flaws by plugin and version. Crossing the two is the entire job of the program that finds you.
A compromised site hardly ever looks compromised
The black screen announcing the hack is the minority of cases, because announcing it ruins the business of whoever got in. The common version is far quieter: new casino or pharmacy pages hanging off your domain, links injected into your articles, or a redirect that only fires when the visit comes from Google on a phone. Set up that way, the owner opens their site every day and sees it looking perfect.
You almost always find out from outside: Search Console warns that odd pages have appeared, the business email starts bouncing because the server was used to send spam, or Google puts the red dangerous-site screen in front of your address. By the time that happens you have spent weeks losing rankings that took months to earn.
What it actually costs
Cleaning up is usually the cheap part, provided backups exist. The expensive part is everything else: the days offline, the domain on email blacklists — meaning your quotes stop arriving — the rankings that fall and take months to return, and the uncomfortable conversation if somebody left personal details in a form.
Put in hours, preventing all of this is a couple of hours a month. It is not a budget problem: it is that those hours are not assigned to anyone.
Maintenance: what it actually means
When somebody sells "maintenance" without spelling it out, ask for this list. It is short, and it is very nearly everything that needs doing:
- Update core, theme and plugins once a month, with a backup beforehand and a quick look over the site afterwards.
- Keep the PHP version on the hosting current: an unsupported version stops receiving patches no matter how up to date WordPress is.
- Automatic backups stored off the server itself, and one restore tested at least once a year. A backup never restored is not a backup: it is an assumption.
- Delete what is not in use: plugins, old themes and accounts belonging to people who no longer work with you.
- One account per person, no shared "admin" login, different passwords, and two-step verification to get into the dashboard.
Updating breaks things, which is why it has to be frequent
Here is the trap that explains why so many sites end up old. Somebody updates, something breaks, and the conclusion drawn is "better not to touch anything". The site then drifts further and further from the current version, and the further it drifts, the bigger the jump and the likelier the next update is to break something. The fear of updating feeds itself.
The way out is not updating less: it is updating often, with a backup first and — if the site matters — a copy where the change can be seen before it is applied to the real one. Small frequent jumps rarely fail; two-year jumps almost always do.
Fewer parts, less surface
The question before installing anything is whether something you already have solves it. Every new plugin is a dependency somebody will have to maintain for years, and that cost does not show up at the moment of installing, which is when it looks free.
It is the underlying reason we build in code, with Next.js, and publish the site as pages that are already assembled: there is no admin dashboard exposed to the internet and no database to inject anything into. Updates still exist — third-party code is everywhere — but the surface left facing the public is of a different order. It is not magic: it is fewer parts.
If it has already happened
The order matters: put the site into maintenance, change every password — hosting, dashboard, database and FTP, not just the WordPress one — restore the backup from before the incident, update everything before publishing again, and only then request the review in Search Console. Restoring without updating leaves the door exactly as it was, and the same program finds you again within days.
If you do not know when your site was last updated, you already have the answer about what state it is in. Write to us and we will look it over: which plugins are surplus, what is unpatched, and how much real work is in there. It is a short conversation and it costs nothing.
Want us to review your site or build a new one?
