---
title: 7 Plugins on Your WooCommerce Store You Could Delete Today
canonical_url: https://lolacore.com/7-plugins-on-your-woocommerce-store-you-could-delete-today/
last_updated: 2026-05-09T22:24:41+00:00
plugin_version: 1.2.1
---

Open your WordPress plugins page right now. Count them. If you're running a typical WooCommerce store, you've got somewhere between 25 and 40 active plugins. You're paying annual renewals on at least a dozen of them.

A good chunk of those plugins do things that take 5 to 10 lines of PHP to accomplish. You're paying $49 to $89 a year for functionality that a snippet of code could handle permanently, with zero performance cost and no update dependency.

This isn't about being a developer. This is about knowing which plugins are earning their keep and which ones are dead weight on your store's speed, security, and your credit card.

## 1. The "Hide Admin Bar" plugin

This is the most absurd plugin category in the WordPress ecosystem. There are plugins with 100,000+ installs whose entire job is to hide the admin bar for non-admin users. That's one line of PHP:

```
add_filter('show_admin_bar', '__return_false');
```

You're loading an entire plugin with its own update cycle, compatibility checks, and database queries for something that WordPress already has a filter for. If your "hide admin bar" plugin has a settings page, that's even worse. There's nothing to configure. It's a yes or no.

## 2. The "Maintenance Mode" plugin

Maintenance mode plugins range from simple (show a "coming soon" page) to bloated (drag-and-drop landing page builder for your maintenance screen). For most store owners, you need this feature twice a year at most — during a migration or a major redesign.

A maintenance mode snippet is about 8 lines of PHP. It checks if the visitor is logged in. If not, it shows a message. That's it. You don't need a plugin sitting active for 363 days a year waiting for the 2 days you actually use it.

## 3. The "Custom Login Page" plugin

Custom login page styling is cosmetic. It makes your wp-login.php match your brand colors. It's nice. It is also not worth $59/year.

WordPress has a `login_enqueue_scripts` action hook. A snippet of 15 lines of CSS injected through that hook does the same thing. Your logo, your colors, your background. No plugin, no settings page, no annual renewal email in January.

## 4. The "Disable Comments" plugin

If you don't want comments on your WooCommerce product pages, you don't need a plugin to turn them off. Most store owners use reviews instead. WordPress has had this built into Settings → Discussion since version 1.0. For more granular control, a snippet with `add_filter('comments_open', '__return_false')` kills comments globally in one line.

The "Disable Comments" plugin category exists because WordPress's native settings are buried in a non-obvious place. That's a UX problem, not a functionality gap. Don't pay a plugin to solve a menu navigation issue.

## 5. The "Insert Headers and Footers" plugin

Google Analytics tracking code. Facebook Pixel. A custom font from Google Fonts. A chat widget script. These all need to go in your site's `<head>` or before `</body>`.

There are plugins with millions of installs that do nothing except give you a textarea to paste code into. The functionality is identical to adding a `wp_head` or `wp_footer` action in a snippet. If you're already using a snippet manager like WPCode or Code Snippets, you already have this capability and the plugin is fully redundant.

## 6. The "Redirect" plugin

Simple redirect plugins map one URL to another. Old product page moved? Redirect /old-product to /new-product. This is useful, but paying for a plugin to manage a handful of redirects is overkill.

For stores with fewer than 20 redirects, a PHP snippet with a simple array lookup does the job. For stores with hundreds of redirects, a plugin with a database-backed UI makes sense. But most WooCommerce stores have 5 to 15 redirects, and half of those were set up once during a migration and never touched again.

## 7. The "Quick CSS" or "Simple Custom CSS" plugin

You want to change the font size on your product titles. Or adjust the spacing on your cart page. Or hide an element you don't need. A "Custom CSS" plugin gives you a textarea to paste CSS.

WordPress has had a built-in Custom CSS editor in the Customizer since version 4.7 (2016). It's under Appearance → Customize → Additional CSS. The plugin is duplicating a feature that's already in your WordPress core. Unless you need CSS that loads conditionally on specific pages (which most of these plugins don't support anyway), the built-in option is better because it stores your CSS in the theme's changeset, not in a plugin's database table.

## Add up the cost

Let's be conservative. Say you have 5 of these plugins and they average $59/year each. That's $295/year in subscriptions. Some stores have all 7 plus a couple more in the same category like "Disable REST API," "Remove Query Strings," or "Disable Gutenberg." That pushes you past $400/year easily.

But the subscription cost isn't the real damage. Each active plugin:

- Adds database queries on every page load
- Loads its own CSS and JavaScript files (even on pages where it's not needed)
- Creates potential security vulnerabilities (every plugin is an attack surface)
- Generates compatibility risks with every WordPress and WooCommerce update

A store running 35 plugins will always be slower than the same store running 25 plugins with the other 10 replaced by lightweight snippets. PageSpeed doesn't care about your plugin's branding or settings page. It cares about how many HTTP requests and database queries happen before your customer sees the product page.

## The catch

You're reading this and thinking: "Great, but I'm not a PHP developer. I can't write these snippets."

That's fair. And that's exactly the gap that keeps these plugins installed. The store owner knows they're overpaying for simple functionality, but the alternative (writing and maintaining code) feels risky. What if the snippet breaks something? What if a WordPress update changes the hook? Who maintains it?

The plugin tax exists because writing code feels dangerous and installing a plugin feels safe. Even when the plugin is doing almost nothing.

Does that tradeoff still make sense in 2026? There is a better way to get those snippets written, tested, and managed without touching a code editor.

---

*Previous in this series: [Your Discount Coupons Are Destroying Your Margins (And You Don't Know It)](/blog/your-coupons-are-destroying-your-margins). Next: why your best customers have gone quiet, and what to do about it.*