Plugin exclusion rules

The question is not “is this plugin popular?” The better question is whether the site needs another dependency at all. Many WordPress problems are better solved with core features, the block editor, the theme, the host, or a small custom implementation.

We usually avoid…	Why	Better first move
Duplicative security plugins	They can overlap with hosting firewalls, backups, malware scanning, login protection, and monitoring. More layers are not automatically safer.	Start with the host, access controls, updates, backups, and only add a plugin for a specific gap.
Large all-in-one plugins	They often bundle features the site does not need, add settings everywhere, and make ownership harder.	Use one focused tool, core WordPress, or a small custom feature.
ACF by default	Custom fields are useful, but ACF can become a shortcut that avoids designing the right block, pattern, template, or content model.	Use core blocks and custom code when the requirement is simple and stable.
Aggressive admin upsells	Plugins that constantly advertise inside WordPress make the admin feel noisy and less professional.	Choose quieter tools or replace the feature entirely.
Plugins that duplicate the host	Caching, staging, backups, security, CDN, and optimization may already be handled better at the hosting level.	Check the host stack before installing another plugin.

Plugin types we avoid most often

These are not automatic bans. They are categories that deserve a harder look before they become part of the site.

• Extra security plugins when the host already provides firewall protection, malware scanning, backups, staging, and monitoring.
• ACF-first builds where core blocks, custom blocks, templates, patterns, or a small custom plugin would keep the site cleaner.
• All-in-one SEO and marketing suites when the site only needs basic metadata, schema, redirects, or sitemap control.
• Plugins like Yoast or MonsterInsights when the admin upsells, notifications, and feature sprawl outweigh the value for the team.

• Heavy page builders for simple layouts that the block editor can handle with less lock-in.
• Feature packs installed for one checkbox instead of a focused tool or small custom solution.
• Plugins that store important content in shortcodes, opaque blocks, or formats that make future migration painful.
• Plugins that load assets everywhere even when the feature appears on one page.

Before installing, ask what can be simpler

• Can WordPress core already do this?
• Can the block editor, a pattern, or a template solve it cleanly?
• Can the host handle this better than a plugin?
• Would a small custom plugin be clearer than a large commercial tool?
• Is this plugin being added because the process is unclear?

• Does it add dashboards, notices, nags, or upgrade prompts editors will have to ignore?
• Does it duplicate another plugin, the theme, the host, or a simple custom feature?
• Does it make content harder to export, migrate, or edit later?
• Would we still install it if we had to explain the tradeoff to the site owner?

Keep, replace, remove, or build small

Decision	Use it when	Next step
Keep	The plugin is clearly needed, quiet in the admin, maintained, and not duplicated elsewhere.	Document why it exists and who owns it.
Replace	The feature matters, but the plugin is bloated, noisy, risky, or doing too much.	Find a focused tool or move the feature into custom code.
Remove	The plugin is unused, redundant, host-duplicated, abandoned, or solving a problem the site no longer has.	Test removal on staging and clean up leftovers.
Build small	The requirement is simple, stable, and important enough to own directly.	Create the smallest maintainable custom solution instead of adding a large dependency.

Audit questions

• What exact problem does this plugin solve?
• Is that problem already solved by the host, theme, WordPress core, or another plugin?
• Does this plugin make the editor experience cleaner or noisier?
• Does it add upsells, alerts, dashboards, or settings that the team does not need?
• What breaks if we turn it off?

• Is the data portable?
• Is the plugin maintained without becoming intrusive?
• Would a custom block, template, pattern, or small plugin be easier to own?
• Would we install this again today?
• Can the business explain why this dependency belongs on the site?

Working rule

Most things can be done simply. Add a plugin only when it solves a clear problem better than WordPress core, the host, the theme, the block editor, or a small custom solution.

Related resources

• Plugin Evaluation Checklist
• Essential Plugins for Professional WordPress Sites
• Enterprise WordPress Plugin Stack
• Plugin Audit Checklist