When we inherit a WooCommerce site, we often see things that on the horizon and inner workings that cause concern. One of the first things we do is audit the plugin stack. Certain plugins appear so consistently, causing performance problems, security exposure, or just doing their job poorly, that removing them has become a standard first step. This is our honest list. We’re naming names because vague advice about avoiding bloated plugins isn’t useful, and because these specific patterns cost clients real money.
Why plugin audits matter
Every plugin is a dependency. It adds code that runs on every page load, sometimes even on pages where it does nothing. It introduces potential conflicts with other plugins and themes, it has security implications if outdated or poorly coded, and it creates update maintenance overhead. We’ve found a plugin still running a version with a known cross-site-scripting vulnerability sitting untouched on a live site simply because nobody had looked at the plugin list in over a year.
The problem isn’t plugins per se. WooCommerce stores need plugins to function. The problem is plugins installed to solve a problem quickly and never revisited, plugins that load globally but serve a narrow purpose, and plugins whose original purpose has been superseded by better options or by built-in functionality.
1. Multiple caching plugins running simultaneously
We’ve inherited sites with WP Rocket, W3 Total Cache, WP Super Cache, and a CDN plugin all active at the same time. Each one is adding its own caching layer, potentially conflicting with the others. The site is serving inconsistent cache states on different requests.
Sometimes the problem isn’t too many plugins, it’s too few of them talking to each other. On one site we inherited, the page cache plugin and Cloudflare’s edge cache didn’t know about each other: clearing one didn’t clear the other, so visitors saw stale content depending on which cache happened to answer their request. The fix was linking the two so a cache clear actually clears both.
Caching is a one-plugin job. On most managed WordPress hosts such as WP Engine, Kinsta, and Cloudways, the host provides server-level caching that’s more effective than any plugin can be. Adding WP Rocket on top of server-level caching often causes more problems than it solves.
What we do: determine what caching the host provides, configure it correctly, and remove every other caching plugin. For sites not on managed hosting, one well-configured plugin, properly connected to any CDN in front of it, is the right approach.
2. Broken Link Checker
The Broken Link Checker plugin runs in the background, scanning every link on your site continuously. On a large WooCommerce store, this creates significant database load and can noticeably slow admin performance.
Checking for broken links matters, but it doesn’t need to run continuously from inside WordPress. External services like Screaming Frog, Ahrefs, or Google Search Console do this better without adding database load to your production environment.
3. Heavy page builders on product and checkout pages
Elementor and Divi are capable tools for marketing pages and landing pages. They’re consistently a source of performance problems on WooCommerce product catalog and checkout pages, which need to load fast and function correctly across the full range of WooCommerce states.
A checkout page built entirely in Elementor is loading the full Elementor runtime and all its JavaScript on the most conversion-critical page on the site. We’ve run this exact removal as a standalone project for a client: pulling Elementor out of the core WooCommerce templates specifically, while leaving it in place on marketing pages where it earns its keep. Use the native WooCommerce block editor or minimal custom templates for cart, checkout, and account pages. Reserve the page builder for marketing content where it adds genuine value.
4. Two SEO plugins active at once
Two SEO plugins active at the same time is one of the most common things we find on inherited sites. The previous developer installed the second one because something wasn’t working in the first, didn’t remove the original, and now both are running. Both are adding their meta tags to every page and potentially conflicting in their XML sitemap output.
One SEO plugin, fully configured, with the other removed and its settings carefully migrated. That’s the only correct state.
5. Outdated extensions licensed to a former developer’s account
Premium WooCommerce extensions from WooCommerce.com that are installed but licensed to a developer account that’s no longer involved receive no updates because the license is inactive. An outdated WooCommerce extension sitting on a live store is a security exposure.
We see this constantly on inherited sites, sometimes discovered only when a routine update run turns up a list of extensions that can’t be updated until someone re-licenses them under the client’s own account. The fix requires identifying every extension with an inactive license, either acquiring a license in the client’s name or finding an alternative, and removing anything that can’t be actively maintained.
6. Redirect plugins with hundreds of undocumented entries
Every redirect adds processing overhead. Redirect chains, where URL A redirects to URL B which redirects to URL C, compound that overhead and are invisible to site owners. We’ve audited redirect plugins with chains four and five hops long.
What we do: export the redirect list, audit for active versus historical, document the ones that matter, collapse chains to single-hop redirects, and remove the rest. The result is usually a redirect list that’s 20 percent the size of the original, with measurably faster page response times.
7. Social sharing plugins loading on every page
Social sharing plugins add JavaScript and CSS on every page load, including cart, checkout, account, and order confirmation pages where sharing buttons serve no purpose. Some load external JavaScript from social networks, adding external requests and tracking implications, and some carry their own security risk: we’ve pulled a social login and sharing plugin off a production site the same day a known vulnerability in it surfaced, rather than wait for a scheduled release.
If social sharing matters for your content, a plugin that loads conditionally only on posts and product pages is the right configuration. Loading social sharing resources, let alone an unpatched vulnerability, on your checkout page adds risk with zero benefit.
8. PDF invoice plugins configured to fire on every email
WooCommerce PDF Invoices and Packing Slips is a legitimately useful plugin. The misconfiguration we find constantly: the plugin is set to attach PDF invoices to every customer email including failed payment notifications and subscription renewals. The PDF generation runs on every outbound email and creates database load on high-volume stores.
Proper configuration: generate PDFs only for the email types where they’re needed, typically completed orders. If volume is high, configure async generation rather than synchronous.
What we replace them with
When we remove a plugin, we either replace it with a better-configured alternative or verify that the functionality was unnecessary or is available natively in WooCommerce or WordPress core. We don’t remove and leave gaps. We document what changed and why, and verify the site functions correctly after each removal.
The principle behind all of this: fewer moving parts, each one doing its job well and only its job. A WooCommerce store isn’t a place to collect plugins. It’s infrastructure for your business, and infrastructure should be as simple as it can be while meeting your actual requirements.
| WORKING WITH BRIOFORGE Not sure what’s actually running on your site anymore? Plugin stacks accumulate quietly: one added for a launch deadline, another because the first one didn’t quite work, a few nobody remembers installing. We audit what’s there, tell you honestly what’s earning its place and what isn’t, and clean it up without breaking the things that do work. If your site feels heavier than it should, or you’ve inherited a plugin list nobody can explain, that’s worth a look. Get in touch at brioforge.com/contact. |
Frequently asked questions
How many plugins is too many for WooCommerce?
The number matters less than what each plugin does and how well it does it. A store with 30 well-chosen, actively maintained plugins that each serve a specific purpose is healthier than a store with 15 plugins where three are conflicting, four are outdated, and two are doing the same thing. Regularly auditing and removing unused or redundant plugins is good maintenance practice.
How do I know if a plugin is slowing my site?
Query Monitor, a free diagnostic plugin, shows you what each plugin adds in terms of database queries and load time per page. You can also use the browser Network tab and disable plugins one at a time on a staging environment to isolate which ones are adding the most overhead.
Are there plugins that are always safe to install on WooCommerce?
No plugin is categorically safe regardless of context. Even well-maintained, popular plugins can create issues in specific combinations or configurations. Every plugin addition on a production site should be tested on staging first, particularly if it touches checkout, order processing, or any functionality customers depend on.
