WordPress makes it easy to install a plugin.

Too easy, sometimes.

A weird layout. A form that needs one extra field. A redirect. A sitemap tweak. A “quick” analytics snippet. The muscle memory is the same every time: open the plugin directory, install something, hope the side effects are small.

That habit is how a site turns into a junk drawer with an admin login.

The plugin isn’t free

Every plugin is another dependency you own.

It can break on a WordPress update. It can ship its own admin UI, its own CSS, its own database tables, and its own idea of how hooks should work. It can conflict with a theme, with WooCommerce, or with the last “must-have” plugin someone installed in a hurry.

Even when it works, you still have to update it, trust its authors, and explain it to the next person who touches the site.

If the problem is a ten-line change, a whole plugin is usually the expensive answer.

Ask what the actual job is

Before you search the directory, name the job in plain English.

Do you need a redirect from an old URL? That might be a rewrite rule, a host-level redirect, or a tiny mu-plugin. Do you need a custom field on a product? That might be a few lines in the theme or a small custom plugin you control. Do you need to hide one admin menu for one role? That might already be a capability, or a filter you write once.

Plugins shine when they solve a real product surface: payments, subscriptions, complex forms, multilingual content, serious SEO tooling. They’re weaker when they’re standing in for “I don’t want to write twenty lines of PHP.”

Those twenty lines are often cheaper than five years of updates.

Prefer code you can read

A small custom plugin with a clear name beats a mystery box from the directory.

You can see the hooks. You can grep the rule. You can delete it without wondering what else it touched. You can put it in version control and review it like any other code.

That’s not anti-plugin. That’s pro-ownership.

WordPress is good at this. Themes, child themes, mu-plugins, and a one-file plugin in wp-content/plugins are all normal tools. Use them when the change is yours.

Delete is a feature

Sometimes the site already has three plugins that almost do the job.

Stacking a fourth one “just for this one thing” is how you get CSS fights, duplicate scripts, and an admin that takes eight seconds to load. The better move is often to remove the almost-solutions, pick one path, and make that path boring and explicit.

If you can’t explain why a plugin is there, it probably shouldn’t be there.

When a plugin is the right call

Use a plugin when the problem is big, shared, and actively maintained.

Don’t reinvent WooCommerce. Don’t hand-roll a security scanner because it felt pure. Don’t build your own page builder because someone on a forum said plugins are bad.

The point isn’t “never install anything.” The point is to stop treating the plugin directory as the first, only, and final debugging tool.

The habit to keep

Next time WordPress misbehaves, pause before you install.

Write down the exact behavior you want. Check whether core, the theme, or an existing plugin already covers it. If the fix is small and stable, own a little code. If the fix is a product, pick a plugin carefully and keep the rest of the stack quiet.

Most WordPress problems aren’t plugin problems.

They’re product problems wearing a plugin-shaped shortcut.