When we take over a WordPress site, the first thing we do isn't design work. It's an audit of the Plugins page.
That page tells us more about a site's history than the client usually can. The average WordPress install runs 20 to 30 plugins, and Patchstack's 2026 State of WordPress Security report logged 11,334 new vulnerabilities across the WordPress ecosystem in 2025 alone - a 42% jump year over year, with 91% of them found in plugins rather than WordPress core. Core had six disclosed vulnerabilities all year. Plugins had the other 11,000-plus.
That gap is the whole story. WordPress core is maintained by one team with a security process built over two decades. A plugin might be maintained by one developer, or by nobody at all, or - as a lot of site owners learned the hard way in April 2026 - by whoever just bought it.
This isn't a "these plugins are evil" list. Every plugin below solves a real problem for somebody. What they have in common is that on the client sites we inherit, they're almost never solving a problem anymore - they're sitting there as dead weight, a security liability, or actively fighting with something else already running on the site. Here are the seven we remove by default, and what we install instead.
The Quick-Answer List
What we remove | Why | What we install instead |
|---|---|---|
A second SEO plugin | Duplicate schema, conflicting sitemaps, slower admin | One SEO plugin, fully configured |
Legacy caching plugin on managed hosting | Redundant with or conflicting with host-level cache | Nothing, or a host-approved plugin for the non-caching features |
Broken Link Checker | High CPU/DB load; banned outright by some hosts | A one-time external scan (e.g., Screaming Frog) run quarterly |
Full Jetpack suite for one feature | Loads a large multi-module framework for a single toggle | A dedicated single-purpose plugin |
Page-builder addon packs, all widgets on | Loads the full widget library's CSS/JS on every page | Custom widgets |
Duplicate XML sitemap plugin | Conflicting sitemaps confuse Google Search Console | The sitemap built into your SEO plugin |
1. A Second SEO Plugin Running Alongside the First
The most common thing we find, and almost never intentional: someone installed Yoast years ago; a later freelancer or in-house marketer installed Rank Math or AIOSEO on top, without checking. Both are still active.
Why it's a real problem, not just clutter:
Both plugins write meta titles, meta descriptions, canonical tags, and schema markup
They don't coordinate — you can end up with two different JSON-LD blocks describing the same page
Google can't merge conflicting structured data, so rich results can silently disappear
This is the standard troubleshooting answer in Rank Math's own support docs, and the first thing we check when a client's rich results vanish for no obvious reason
Agency observation: this is rarely a developer's mistake — it's almost always a site changing hands. Every "second SEO plugin" we've found was installed to solve a problem the first plugin already solved; whoever added it just didn't know that yet.
What we do:
Pick one plugin (usually whichever has more configuration already invested)
Verify redirects, focus keywords, and custom schema are preserved
Fully deactivate and delete the other — a deactivated plugin is still code an attacker can reactivate or exploit directly
2. A Full Caching Plugin Stacked on Host-Level Caching
If a client is on Kinsta, WP Engine, Flywheel, or Pressable, server-level page caching is very likely already running before WordPress even loads. Installing W3 Total Cache or WP Super Cache on top doesn't add speed — it adds a second cache that can serve stale pages, fight the host for control of response headers, or cause the white-screen errors we most often get called in to fix.
Hosting type | Host-level caching? | Legacy full-stack caching plugin needed? |
|---|---|---|
Kinsta, WP Engine, Flywheel, Pressable | Yes (Varnish/NGINX/proprietary edge) | No — often actively conflicts |
Shared/unmanaged hosting | No | Yes — doing real, necessary work |
How managed hosts actually handle this: several, including Kinsta and WP Engine, explicitly allow WP Rocket because it auto-disables its own page-caching layer on those platforms and only runs file optimization (minification, lazy loading) that doesn't fight the host's cache. A full-stack plugin like W3 Total Cache has no such detection built in.
What we do:
Managed hosting → remove the legacy caching plugin entirely; add a lightweight optimization plugin only for features the host doesn't already cover
Unmanaged/shared hosting → keep one well-configured caching plugin, and confirm nothing else on the site duplicates its job
3. Broken Link Checker
A well-earned reputation, and not a new complaint — WP Engine and GoDaddy have both been reported to automatically disable this plugin on sites where it's installed, because of the resource load it generates.
What it actually costs a site:
Crawls every link on every post/page on a recurring schedule
Elevated CPU usage during each crawl
Database tables that can bloat into the megabytes even on modest sites
Enough documented cases of sites crashing shortly after activation on shared hosting to be a known, recurring pattern
The problem it solves is real — dead links do hurt UX and crawl budget. Running it as an always-on background process inside the CMS is the wrong way to solve it.
What we do instead: run a link audit as a one-time task with an external crawler (Screaming Frog is our default), on a quarterly or post-migration cadence — same outcome, without a permanent crawler competing with the site for resources every day.
4. The Full Jetpack Suite, Installed for One Feature
Jetpack isn't a bad plugin. It's a coordinated toolkit — stats, backups, security scanning, image CDN, social sharing — built and maintained by Automattic, and the "bloated" criticism is a little dated now that its modular system lets you disable unused pieces.
Where it earns removal on our client sites:
We regularly find it installed for one feature only (usually Stats, occasionally the CDN), with the rest of the suite dormant
Independent plugin-performance testing has measured real, non-trivial memory overhead versus smaller single-purpose plugins
Even a disabled module still ties the site to a WordPress.com account connection it doesn't need
Trade-off, stated plainly:
Situation | Our call |
|---|---|
Client wants the coordinated bundle — backups, security, stats, CDN, one vendor | Keep Jetpack |
Client uses one module, rest sits dormant | Remove, replace with a dedicated single-purpose plugin |
What we do: swap a single-feature Jetpack install for the lightweight equivalent — e.g., a privacy-focused analytics plugin instead of Jetpack Stats — and keep security/backup/CDN as separate tools the client actually configures.
5. Page-Builder Addon Packs With Every Widget On
Elementor addon packs — Essential Addons, JetElements, PowerPack, and similar — are genuinely useful, and we install them on plenty of builds. The problem isn't the plugin. It's that almost nobody configures it.
What's actually happening:
These packs ship with a widget manager for disabling anything you're not using
A disabled widget's CSS/JS shouldn't load — but that setting is opt-in, and on most client sites we inherit, it was never touched
Result: a page built with a single flip-box widget still ships the CSS overhead of the entire library — sometimes 90+ widgets' worth — on every load
Original observation: the marketing pitch is "install once, get everything." The performance reality is the opposite — these packs are only lightweight if you immediately disable most of what you just installed, which undercuts the convenience they were sold on. We now check the widget manager on every audit instead of assuming a well-regarded plugin is configured correctly.
What we do:
Identify every widget actually placed on a live page (theme builder + site-wide content search)
Disable everything else in the widget manager
If the pack was installed for only two or three widgets, replace it entirely with a single lightweight, purpose-built plugin
6. Plugins From Vendors Who've Quietly Changed Hands
The newest item on this list, and the one we've gotten the strictest about since April 2026.
What happened, briefly:
A portfolio of 30+ established WordPress plugins was sold via Flippa to a new owner months earlier
A dormant backdoor sat in "routine" updates, undetected, until it was activated in April 2026
An estimated 400,000+ live sites were affected before the WordPress.org Plugins Team pulled the plugins and forced a security update
The backdoor was used to plant hidden admin accounts and inject SEO spam — on plugins many owners had trusted for years, precisely because they'd been trustworthy for years
This is exactly the failure mode a security plugin can't catch: the code wasn't malicious when it was audited. It became malicious under a name you already trusted, after ownership changed.
What we do — this can't be fully solved with an audit, so it's a standing practice:
Keep plugin count on every client site as small as realistically possible
Favor plugins with large, actively engaged dev teams over solo maintainers or anything gone quiet for a year-plus
Review, quarterly, what's installed, who maintains it, and whether it's still being actively updated
Treat "install and forget" as an outdated way to run a production site — this threat model doesn't show up as a CVE you can patch
7. A Second XML Sitemap Plugin
Every major SEO plugin — Yoast, Rank Math, AIOSEO — generates its own XML sitemap as a built-in feature. We still regularly find a standalone sitemap plugin installed on top, usually a holdover from before the current SEO plugin was added.
The result:
Two competing sitemaps, sometimes both submitted to Search Console at different points in the site's history
Occasionally listing different sets of URLs as the site's structure changed over time
Not usually a dramatic failure, but exactly the kind of ambiguity that doubles the time to troubleshoot an indexing issue — you have to figure out which sitemap Google treats as authoritative before you can fix anything
What we do:
Confirm the primary SEO plugin's native sitemap is enabled and correctly configured
Submit that single sitemap URL in Search Console
Remove the redundant plugin
Retire (or 301) the old sitemap URL so nothing still points search engines at stale data
Before You Start Deleting Things
"Just delete the extra plugins" is more dangerous advice than it sounds. Check these first:
Shortcodes in content — if a page builder, slider, or form plugin has shortcodes embedded directly in posts, deleting it without replacing them first leaves visible broken code on the live page. Search the database for the shortcode prefix before deactivating.
Staging, not production — every removal in this article should happen on a staging copy first, with a full visual and functional check.
A full backup, immediately before any change — even on staging. This is the one place we don't cut corners.
Confirm the replacement works before removing the old one — get the new SEO plugin, cache setup, or single-purpose tool fully configured and verified first.
How We Actually Audit a Client Site
Within the first week of taking over a WordPress site:
List every active plugin and note last-updated date and active install count
Flag anything unmaintained for 12+ months, or with a recent "acquired by" note in the changelog
Check for duplicate functionality — two SEO plugins, two sitemap generators, two caching layers, two popup tools
Confirm what the host already provides (caching, CDN, backups) before judging whether a plugin doing the same job is redundant
Run a page-speed audit with each plugin temporarily disabled, one at a time, on staging, to isolate the real cost of each
Document what gets removed and why, so the client — and whoever touches the site next — isn't starting from zero
FAQs
How many plugins is too many for a WordPress site? No fixed number, but 20–30 is the average, and most sites we audit could run the same functionality on meaningfully fewer. The real question is whether each one is still solving a live problem.
Do more plugins actually make a WordPress site less secure? Generally yes — 91% of vulnerabilities disclosed in 2025 were in plugins, not core. Each additional plugin is another codebase, another maintainer, and another point of failure, including the ownership-change risk above.
Is Jetpack bad for WordPress performance? Not inherently. It's reasonable if you're using several of its modules. It's a poor fit specifically when a site installs the whole suite for one feature and never touches the rest.
Can I just delete a plugin I'm not using? Usually — but check for shortcodes embedded in content first, take a backup, and test on staging before touching a live site.
Should I run a security plugin in addition to keeping plugins updated? Helpful for known-vulnerability scanning and hardening, but it won't catch a supply-chain compromise where the plugin itself is the trusted, unmodified-looking delivery mechanism. Keeping plugin count low and reviewing ownership/maintenance regularly is the better defense against that specific risk.
Key Takeaways
Plugins, not core, are where almost all real risk lives — 91% of disclosed vulnerabilities in 2025 were plugin-based
Redundant plugins (two SEO tools, two caching layers, two sitemap generators) are rarely intentional — they're leftovers from a site changing hands without a proper handoff
Check what your host already provides before adding a plugin that duplicates it, especially caching on managed hosting
A "feature-rich" plugin is only lightweight if its optional settings are actually configured — most aren't, on the sites we inherit
Plugin ownership can change without your knowledge; keep plugin count as lean as the site can reasonably run on
Never delete a plugin from a live site without checking for embedded shortcodes, backing up, and testing on staging first
Conclusion
None of these seven plugins are on this list because they're badly built. Most solve a real problem for somebody. They end up here because on the client sites we actually inherit, they're almost always solving a problem that's already been solved twice, fighting with something else already running, or quietly carrying more risk than the feature is worth. A leaner stack, audited on a real schedule, beats a feature-complete one nobody's checked in over a year — every time.
If you're planning a Shopify or WordPress project and want a development partner focused on performance, scalability, and long-term maintainability — not just attractive designs - Growthx Media can help.