Why your site shouldn't be a pile of plugins

Nobody sits down and decides to run thirty-four plugins. It happens one reasonable decision at a time. You needed a contact form. Then a slider. Then a cookie banner, a booking widget, an SEO helper, a caching layer to fix the slowness the other six caused, and a security plugin to feel better about all of it.

Five years later the site works, mostly, and no single person has ever read the whole thing. That's the position I'd argue is worth avoiding — not because plugins are bad, but because a pile of them is a different kind of object than the site you thought you bought.

Your risk is the union of everyone else's

Core platforms get audited. The mass compromises overwhelmingly arrive through extensions — and specifically through the ones with modest install counts whose author moved on years ago and whose repository page still says "last updated" in a year you'd rather not see.

Every plugin runs with the same privileges as the site itself. Full database access, filesystem write, the ability to send mail as you. There is no sandbox. So your security posture is not the strength of your platform; it's the weakest of thirty-four codebases, maintained by thirty-four people you have never met, any one of whom can sell their project to someone with different intentions.

Update deadlock

The second cost shows up quietly, and it's the one that ends sites.

A plugin update breaks your layout. So you turn off automatic updates. Now you're accumulating known-vulnerable versions on purpose, and every month makes the eventual catch-up worse. Or the other direction: your language runtime goes end-of-life, and one plugin — usually an unglamorous one nobody wants to touch — doesn't run on the supported version. So the whole site stays on an unsupported runtime, which means it stops getting security patches at the layer underneath everything.

Either way you arrive at the same place: a site that can't move, where the correct next action is known and blocked by something you don't control.

The part that's worse than either

Here's what actually breaks people, and it isn't security or updates. It's that nobody can tell you what your site does anymore.

The behavior of a plugin-stacked site is emergent. Thirty-four authors register callbacks into the same request lifecycle, they fire in an order determined by load priority and installation history, and each one can modify what the previous one produced. There is no file you can open that describes what happens when a customer submits the form. There is only the running system.

So when the contact form stops emailing — and it will, and nobody will notice for two weeks — you cannot debug it by reading. You debug by bisection: disable half the plugins, see if the symptom moves, put them back. On a live site. In front of customers. An engineer who knows the platform cold still spends two hours on a question that should take five minutes, because the answer isn't written down anywhere. That's the real bill, and it arrives every single time something misbehaves.

When a plugin is the right answer

The honest counter-argument, because there is one. Some things you should absolutely not write yourself, and reaching for a maintained extension is correct.

Payments, above all. Authentication and session handling. Spam filtering. Anything cryptographic. These are problems where the failure mode is severe, the correct implementation is unobvious, and the standards keep moving — you want a well-resourced project maintaining that code with more attention than you can give it, forever.

The test I use is two questions. If I write this myself, am I taking on a security-critical thing I'll have to keep watching? Then use the plugin. Would this be twenty lines of my own HTML and a form handler? Then write the twenty lines and own them, because a dependency you added to avoid twenty lines will outlive your patience for maintaining it.

Most of what accumulates on a small business site is the second kind. Sliders, banners, layout helpers, social icons, contact forms.

What to do

List what's installed and mark each one: security-critical, load-bearing, or convenience. Convenience items are candidates for deletion today.
For everything that stays, check when it was last updated and whether it supports your current runtime. One abandoned dependency is a migration you haven't scheduled yet.
Deactivating is not removing. Dormant plugin code still sits on disk and is still reachable by anyone who knows the path. Delete it.
When the list can't be cut below something you'd be willing to read, that's the signal to rebuild rather than keep patching.

A site should be a small amount of code you or someone you trust could read in an afternoon, with the few dependencies you actually chose. That version is faster, it's cheaper to keep alive, and when something misbehaves, the explanation is somewhere a person can find it.

If patching the pile now costs more than replacing it, here's what a rebuild and hosting cost.