Will My Website Get Hacked?

The most common thing we hear after a site gets compromised is a version of: “why would anyone target us?”

Nobody did. That’s the whole point, and it’s worth understanding, because the wrong mental model here leads directly to the wrong precautions.

How it actually happens

Picture a program that walks the entire internet, knocking on every door, checking whether that door has a lock model with a published flaw. It isn’t reading your sermon archive or evaluating whether you’re worth the effort. It’s checking a list.

When a security researcher discovers a flaw in a piece of website software, it gets disclosed publicly so people can patch it. Attackers read those disclosures too. Within hours, automated scanners are sweeping for sites that haven’t updated yet.

Your church is not a target. Your out-of-date contact form plugin is.

The numbers, and where they come from

Patchstack publishes an annual report on the WordPress ecosystem. They’re a security company, so they have a commercial interest in this being alarming, and you should read their figures with that in mind. That said, the vulnerability counts are drawn from public disclosures, which makes them checkable.

Their 2026 report counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, a 42% increase over the year before.

The distribution is the useful part. 91% were in plugins. 9% in themes. WordPress core itself had six, all rated low risk.

That single fact should shape how you think about your site. The core software is maintained by a large project with a serious security process. The seventeen plugins someone added over eight years are maintained by seventeen different parties of wildly varying diligence, and some of them have quietly stopped.

Two more figures from the same report, both about time. Roughly half of high-impact vulnerabilities are exploited within 24 hours of disclosure. And 46% of vulnerabilities had no fix available from the developer at the moment they became public.

That second number is the one that changes behavior. It means “just keep everything updated” is necessary but not sufficient, because sometimes there is no update to apply. Sometimes the correct move is removing the plugin.

What a compromise actually looks like

Rarely a defaced homepage with a skull on it. That’s the movie version. What we usually find:

• Spam pages quietly added under your domain, selling counterfeit goods to search traffic you never see. You find out when Google flags your site.
• A redirect that only fires on mobile, or only for visitors arriving from search, so staff on desktop never notice.
• Your domain sending phishing email. Your domain had a good reputation, which is exactly what made it worth stealing. Then your legitimate email starts bouncing.
• A quiet foothold, doing nothing visible, waiting.

The reputational damage is the part that stings. A visitor who gets a red browser warning trying to find your service times has learned something about you that isn’t true and isn’t easily corrected. It also puts your Google listing at odds with your actual site, and Google’s guidelines expect your presence to represent you accurately.

The list that prevents most of it

Not exhaustive. Ordered by how much protection you get per unit of effort.

1. Update promptly. Core, plugins, themes. Weekly at minimum, and same-day for anything flagged critical. Given how fast disclosed flaws get exploited, “we do it quarterly” is a decision to be exposed most of the time.
2. Delete plugins you don’t use. Deactivated is not removed. Deactivated plugin code still sits on the server and can still be reachable. Every one you delete is one fewer thing to maintain forever.
3. Check whether your plugins are still maintained. If the last update was three years ago, it isn’t stable. It’s abandoned, and there will be no patch when a flaw is found.
4. Real passwords, and two-factor on every admin account. Shared logins are the other common entry point, and churches are unusually prone to them because so many people cycle through.
5. Remove old accounts. The intern from 2021 does not need an administrator account. Neither does the vendor you stopped working with.
6. Backups you have actually restored. Keep several restore points, not just last night’s. Test one. A backup nobody has ever restored is a hope.
7. Keep hosting current too. The PHP version and server software underneath your site age the same way your plugins do.

Who is doing this

That’s the real question, and it’s the one most churches and small businesses can’t answer.

Every item above is straightforward. None of it is technically difficult. All of it has to happen indefinitely, forever, including the weeks when your office manager is on vacation and the month everyone is consumed by VBS.

Software maintenance is the least urgent item on any list until the day it becomes the only item. That’s precisely why it gets skipped, and why the sites we’re called in to clean up are almost never sites where someone was negligent. They’re sites where it was nobody’s job.

So: who on your team owns this, and what happens when they leave? If the answer is uncomfortable, that’s worth resolving before it resolves itself.

Our hosting and support plans exist because this is the part nearly every church and small business underestimates. But the list above works regardless of who runs it. If you do it yourself, do it on a calendar, not on good intentions.