Every WordPress site I inherit arrives with the same archaeological layers: a plugin someone installed for a one-off task in 2021, a "performance" tool that fights the host, a security plugin doing what the firewall already does. Over years of cleaning up these stacks, five plugins keep ending up in my deactivate-and-delete pile. None of them are bad software in the abstract. They're just the wrong tool for most of the sites that run them, and the cost they impose — in page weight, database load, or simply duplicated effort — almost never earns its keep.

Here are the five I pull most often, why, and what I put in their place.

1. Jetpack — too many modules for one decision

Jetpack is really a dozen plugins wearing a trench coat: stats, related posts, social sharing, a CDN, downtime monitoring, brute-force protection, and more. The pitch is convenience. The reality on a typical site is that you use two of those modules and pay the overhead for all of them — extra HTTP requests, a connection to WordPress.com that has to stay authenticated, and a settings surface large enough to hide misconfigurations.

The specific thing that bothers me is that Jetpack's value scales with how much of it you adopt, and most site owners adopt almost none of it. If all you want is stats and image-CDN offloading, you are loading a coordination layer designed for people running the whole suite.

What I use instead: pick the single-purpose replacement for the one module you actually rely on. Independent Analytics or a privacy-friendly script like Plausible for stats; the host's CDN or a dedicated image plugin for offloading; native social-share blocks or a 5KB sharing plugin instead of Jetpack's sharing module. You end up with less code and a clearer mental model of what each piece does.

2. Slider Revolution — a heavy answer to a question most sites stopped asking

Slider Revolution shipped on an enormous number of premium themes, which is the only reason it is still everywhere. It is a capable animation engine, but it carries the weight to match: its core JavaScript and CSS, plus the libraries it pulls in, routinely add a couple hundred kilobytes of render-blocking assets to pages that often display a single static hero image.

It also has a long security history — the 2014–2015 "RevSlider" local file inclusion and arbitrary file upload vulnerabilities were among the most widely exploited WordPress flaws of their era, precisely because so many bundled copies were never updated. The plugin is patched today, but bundled-and-forgotten installs are still a real risk vector.

The deeper issue is that hero carousels are a weak design pattern. Visitors rarely interact past the first slide, and rotating banners can hurt rather than help conversions.

What I use instead: for a static hero, a plain block with a properly sized, modern-format image (more on that below). When motion genuinely earns its place, the native Cover block plus a few lines of CSS, or a lightweight library like GSAP loaded only on the page that needs it — not site-wide on every request.

3. Broken Link Checker (on-server version) — it audits your site by punishing your server

The classic, self-hosted Broken Link Checker runs its scanning inside your WordPress install. To do its job it parses your content, stores every link in your database, and fires off HTTP requests on a schedule to test them. On a small site you might not notice. On a content-heavy site it becomes a quiet drain — extra database tables, recurring cron load, and outbound request bursts that shared hosts genuinely dislike. I have seen it flagged by hosting providers as the reason a site was throttled.

The task it performs is real and worth doing. It just shouldn't be done by a resident process living on the same server that has to stay fast for visitors.

What I use instead: run link checking from outside. A periodic crawl with Screaming Frog (free up to 500 URLs) catches broken internal and external links without touching production load. For sites already on Ahrefs or Semrush, the site-audit feature does the same. If you want it inside WordPress, the cloud-based version of Broken Link Checker offloads the scanning to its own infrastructure, which solves the core objection.

4. Really Simple SSL — a redirect that doesn't need to be a plugin

Really Simple SSL solved a real problem in the era when moving a site to HTTPS meant chasing down mixed-content warnings. It detects your certificate, forces HTTPS, and rewrites insecure resource URLs. The catch is that it does this work on every page load, and for most sites the underlying fixes are one-time configuration changes you can make permanent.

Once your siteurl and home values use https, a server-level redirect is in place, and your content no longer references http:// assets, the plugin has nothing left to do but sit in the request path. Keeping a plugin resident to enforce something your server already enforces is the kind of redundancy that adds up across a stack.

What I use instead: configure HTTPS properly once. Set the HTTP-to-HTTPS redirect at the server level (an .htaccess rule on Apache, a return 301 block in Nginx, or the one-click setting your host almost certainly provides), update the two site-URL fields, and run a search-replace on the database to fix any hardcoded http:// references. Then you can delete the plugin and the redirect still holds.

5. W3 Total Cache — when the host already caches, two cooks spoil the page

W3 Total Cache is powerful, and that is exactly the problem on managed hosting. Hosts like Kinsta, WP Engine, SiteGround, and Cloudways already run full-page caching at the server or CDN edge — the fast layer that actually matters for time-to-first-byte. Stacking a complex application-level cache on top doesn't add speed; it adds conflicting cache layers, stale-content headaches, and a settings panel with enough toggles to break a site if you guess wrong on minification.

I reach for a plugin cache only when the host provides none. In that case I'd rather use something simpler and better-behaved than W3TC's sprawling configuration.

What I use instead: on a managed host, lean on the host's caching and turn off any plugin-level page cache entirely. Where I do need a plugin, WP Super Cache or the free Cache Enabler covers static page caching with a fraction of the configuration surface. For minification and asset optimization specifically, a dedicated tool keeps that concern separate from caching, so a bad combine-and-minify setting doesn't take your whole cache down with it.

The principle underneath all five

Notice the pattern. None of these removals is about a plugin being broken. Each is about responsibility living in the wrong layer: a security redirect that belongs on the server, a link audit that belongs on an external crawler, a page cache that belongs at the host's edge, a slider that belongs in a single line of CSS. WordPress makes it trivially easy to solve every problem with a plugin, and that ease is precisely what produces bloated, fragile stacks.

The most expensive plugin on any site is rarely the one you think about. It's the one running quietly in the request path, duplicating work that's already handled elsewhere, that nobody has questioned since the day it was installed.

A practical rule: before adding a plugin, ask whether the host, the server config, the theme, or core WordPress already does the job. And every few months, open your active-plugins list and treat every entry as guilty until proven useful. On most sites I audit, a quarter to a third of what's installed can leave without anyone noticing — except your Largest Contentful Paint, which will thank you.

Why I Removed These 5 Popular WordPress Plugins