The brief was familiar. The shop was slow. Checkout felt flaky. Pages took an age to load on a phone. The owner had already tried the usual suspects: a caching plugin, a CDN, a “performance” add-on someone had recommended on a Facebook group. Nothing stuck for long.
When I logged in, the plugin list told most of the story before I opened a single log file. Three SEO plugins. Two page builders fighting over the same templates. A security suite, plus a second security plugin left inactive but still loading a handful of files. Snippets in the theme’s functions file that duplicated what a plugin already did. An abandoned “speed optimiser” that rewrote asset URLs in a way WooCommerce never quite liked.
The owner expected me to add something clever. What I quoted them for, and what they paid for, was mostly taking things out.
More plugins is not more shop
On a WooCommerce site, every active plugin is another thing that runs on the requests that matter — cart and checkout especially. Overlap is worse than clutter. Two plugins that both think they own redirects, minification, or schema markup will fight quietly. You don’t always get a red error. You get a shop that feels slightly wrong: a slower first byte here, a flaky add-to-cart there, a checkout that works until it doesn’t.
Old snippets are the same problem in a different coat. Someone fixed a shipping label five years ago with ten lines in functions.php. The shipping plugin later grew a setting for the same thing. The snippet stayed. Now you’ve got two answers to one question, and nobody remembers which one is in charge.
Deleting code feels risky because it is. You’re removing something that was put there on purpose, even if that purpose was forgotten. So I don’t yank things on a live till and hope. I decide what can go, then I prove it’s safe.
How I decide what can go
I work through a short list every time. It isn’t glamorous. It does stop me deleting the one thing the shop still needs.
What still does a job
I ask the owner, plainly: which of these do you actually use? Not “which might you need one day.” Use. If they can’t name a workflow that depends on a plugin, that’s a candidate — not an automatic delete, but a candidate.
Overlap
Two tools doing the same job is my favourite find. One SEO plugin. One cache layer you understand. One security approach you can explain. I keep the one that matches how the shop actually works, and plan to retire the rest.
Abandoned and inactive
Inactive plugins still sit on disk. Some still load bits of themselves. Abandoned plugins with no updates for years are a security and compatibility problem waiting for the next WooCommerce release. Those go high on the list.
Snippets that lost their reason
Custom code in the theme, a code snippets plugin, or an old mu-plugin. I read each one, note what hook it hangs on, and check whether a current plugin setting or core WooCommerce feature now covers it. If the snippet is still the cleanest fix, it stays — documented. If it’s a fossil, it goes.
Side effects I can name
Before anything is removed, I want a one-line theory of what might break: “losing Plugin X may drop the custom thank-you redirect” or “Snippet Y changes the order email subject.” If I can’t name a risk, I don’t understand the code well enough to delete it yet.
How I prove it’s safe
Taking things out without a proof is just gambling with someone else’s orders.
Staging first, always
Deletes happen on staging. The live shop keeps selling while I experiment.
One change at a time
I don’t disable six plugins in one go and call it a test. One plugin or one snippet per pass. Then I check the paths that make money: home, product, cart, checkout, payment, order emails, and any custom flow the owner relies on — subscriptions, deposits, wholesale roles, whatever their shop actually does.
Before and after numbers
I note the obvious metrics: page weight, number of requests, a fair Time to First Byte where I can get one, and a simple mobile load on a throttled connection. I’m not chasing Perfect PageSpeed scores. I want “noticeably less junk” and “checkout still completes.”
A rollback plan written down
Deactivate first where I can. Keep a full backup from before the session. Note the exact plugin versions and snippet text I’m removing so I can put them back in ten minutes if a real customer path fails. “We can always restore the backup” is true and also too slow if you’ve just broken Friday afternoon checkout.
Owner walkthrough
Before anything goes live, the owner clicks through the paths they care about on staging. They’re not technical QA. They are the people who will notice if the wholesale login or the gift-message field vanished.
Only then do we repeat the same removals on live, still one change at a time, with a quiet window if the shop is busy.
What we took out, and what got better
On that shop, the safe list was longer than the keep list. We retired the duplicate SEO plugin, the second security tool, the abandoned optimiser, and a handful of snippets that had been superseded. We left one well-understood cache setup and the plugins that mapped to real daily work.
Checkout stopped feeling flaky. Product pages shed a chunk of weight. The owner’s phrase, not mine: “It feels like the site I thought I’d bought.”
They had paid for a performance job. What they actually bought was less code in the way — and a written note of what we removed and why, so the next person doesn’t put the same pile back.
When deleting isn’t the answer
Sometimes the slow shop is under-resourced hosting, a huge unoptimised image library, or a theme that loads the world on every page. Removing plugins won’t fix a server that’s on its knees. I’ll say that plainly rather than strip the site for theatre.
And I won’t delete something just because I don’t like it. If a plugin is ugly but it’s the only thing running their trade counter integration, it stays until there’s a replacement plan.
Paying someone to remove things
Shop owners are used to buying additions: a new feature, a new plugin, a new tweak. Paying to delete feels backwards until you’ve lived with a flaky till. Less overlap, less forgotten code, fewer mysteries on the next WooCommerce update — that’s maintenance with a point.
If your WooCommerce shop has collected years of “just in case” plugins and snippets, and you’d rather someone sort what can safely go, have a look at how I work with WooCommerce shop owners and get in touch.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece. He did not write these words. Augmented publishing by Neil Matthews.