Why Fewer Plugins Means Fewer Hacks: Maintenance That Actually Protects

The WordPress security industry sells complexity: firewalls, scanners, “360° protection suites”. The vulnerability data tells a simpler story. Patchstack’s State of WordPress Security counted nearly 8,000 new vulnerabilities in a single year — 96% of them in plugins, 4% in themes, and just 7 in WordPress core, none critical. A third of the disclosed flaws had no patch available at disclosure, and over 1,600 plugins were removed from the official repository for exactly that reason.

Read that again: the platform is fine. The risk is the stuff you install. Which means real security isn’t a product you add — it’s surface you remove plus a boring routine you keep.

Principle 1: The best-patched plugin is the one you deleted

Every plugin is code that can develop a hole, written by someone who may stop maintaining it. You can’t patch what the developer never fixes — but you can not run it.

• Delete (don’t deactivate — deactivated code still sits on disk, still exploitable) everything that isn’t earning its place. The 30-minute plugin audit is the method.
• Replace snippet-grade plugins with code you own — ten examples with copy-paste snippets. A 10-line function has a very different risk profile than a 100,000-line suite with an update server.
• Check the pulse before installing anything new: last update within months, active support threads, a developer with a track record. “Popular” isn’t “safe” — over a thousand vulnerabilities per year hit plugins with 100k+ installs.

This is the honest security argument for refactoring: a site rebuilt with clean code and 5 plugins instead of 30 hasn’t just gotten faster — it has 6× fewer doors.

Principle 2: Updates are a schedule, not an event

Most compromises exploit known, already-patched vulnerabilities on sites that simply hadn’t updated. The fix is cadence:

Weekly (15 minutes):

• Review and apply plugin/theme updates. Read the one-line changelogs — “security fix” means now.
• Click through the site’s money paths afterward: home, a form, checkout if you have one.

Monthly (30 minutes):

• WordPress core minor versions should be auto-applied already; confirm.
• Prune: any plugin unused for a month goes. Any plugin whose developer went silent gets a replacement plan.
• Check PHP version — staying on a supported branch (8.2+) is a security matter, not just a speed one.

Quarterly (an hour):

• Restore a backup to staging. A backup you’ve never restored is a rumor.
• Re-run the outside-in checks: security headers, HTTPS/mixed content, exposed version — our free analyzer covers them in one scan.
• Review admin accounts and passwords; remove ex-contractors. Two admins is plenty.

Principle 3: Assume failure — make it cheap

Hardening (we’ve got a 12-step afternoon checklist) lowers the odds. Backups define the cost when odds lose:

• Automated, daily, off-server. A backup stored on the same hosting dies with the hosting.
• Retention of at least 30 days — compromises are often discovered weeks late; you need a copy from before.
• Tested restores (see quarterly, above). Recovery time is the metric: an hour-long restore turns a hack from a catastrophe into an annoyance.

What about security plugins?

A lean firewall/rate-limiter has a place, especially on hosts that provide nothing. But watch the irony meter: a 15-plugin site adding a heavyweight security suite has increased its codebase, its queries and its TTFB to monitor a surface it could have simply shrunk. Host-level WAFs and server rules do the network-layer job without taxing every page load.

The uncomfortable summary

Nobody sells “fewer plugins and a calendar reminder,” which is why you rarely hear it pitched. But that’s what the data supports: small surface, current software, tested backups, verified headers. Everything else is decoration.

Start with the scan — analyzer, two minutes, and you’ll know your exposed version, header gaps and plugin footprint. Then delete something. It’s the most underrated security move in WordPress.