How we vet a WordPress plugin before it goes on a client site

Most WordPress sites we inherit have between 30 and 60 active plugins. When we audit them, a handful are essential, a larger group duplicates functionality, and a few are abandoned, insecure or quietly slowing down every page. Plugins are the biggest source of both value and risk in the WordPress ecosystem, and the decision to install one deserves more thought than a star rating. This is the checklist we run before any third-party plugin goes onto a client site.

Start with whether you need it at all

The cheapest plugin is the one you never install. Before evaluating candidates, we ask three questions:

• Does core already do this? Many older plugins exist to add features that WordPress now includes, such as lazy loading, basic SEO meta handling through the theme, or block-based layouts.
• Is it a few lines of code? A plugin to add a custom post type, disable comments or add a tracking snippet is overhead. A small, site-specific plugin we maintain is simpler and safer.
• Is it a long-term need? Plugins installed for a one-off campaign tend to stay installed forever. We agree a removal date up front.

On a typical audit, these questions alone remove a third of the installed plugins.

Maintenance and ownership signals

For plugins that are genuinely needed, we look first at who maintains them and how. Code quality matters, but an actively maintained plugin with average code is usually a safer bet than a beautifully written one that was last updated two years ago.

1. Update history. Regular releases over the last 12 months, and compatibility with the current WordPress and PHP versions.
2. Security track record. We check public vulnerability databases. A past vulnerability is not disqualifying; how fast it was fixed and disclosed is what we look at.
3. Support responsiveness. Recent support threads with maintainer replies, and whether serious bug reports are acknowledged.
4. Business model. A plugin with a sustainable paid tier or clear sponsorship is more likely to be maintained in three years than a hobby project.
5. Ownership changes. Plugins sold to new owners sometimes change behavior, add upsells or, in rare cases, introduce malicious code. Recent acquisitions get extra scrutiny.

A plugin is not a feature you buy once. It is a dependency you agree to maintain for as long as the site exists.

Code, security and performance checks

We install every candidate on a staging copy of the site and review it before it gets anywhere near production. The review is proportionate: a simple utility gets an hour, a plugin handling payments or user data gets a proper code review.

What we look for in the code:

• Input sanitized and output escaped, nonces and capability checks on every admin action and AJAX endpoint.
• Database queries prepared rather than concatenated from user input.
• REST routes with sensible permission callbacks, not open to everyone by default.
• No remote code loading, obfuscated code or unexpected calls home.
• Clean uninstall behavior that removes its options and tables when asked.

Then performance. We profile a representative page with and without the plugin active, measuring added queries, autoloaded options, front-end scripts and styles, and server response time. Our rule of thumb is that a plugin adding more than 50 milliseconds of server time or loading assets on pages where it is not used needs a very good reason to stay. Many plugins enqueue their scripts site-wide; we either conditionally dequeue them or choose an alternative.

A small example of the kind of fix we routinely apply:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_script( 'example-forms' );
        wp_dequeue_style( 'example-forms' );
    }
}, 100 );

Licensing is the last practical check. Premium plugins with annual licenses need an owner who renews them, a record of which account holds the license, and a plan for what happens if the license lapses. We store license details in the client's password manager, not in a developer's personal account, so the site does not quietly stop receiving security updates after a staff change.

Exit cost: the check most teams skip

Before installing, we ask what it would take to remove the plugin in two years. Some plugins are easy to leave: disable them and the site works. Others embed shortcodes in thousands of posts, store content in proprietary formats, or become the foundation of every page layout. Page builders are the classic example, and many of the migrations we run are really page builder exits.

High exit cost is not automatically a reason to reject a plugin, but it raises the bar. For anything that will shape content storage, we prefer plugins that use standard post meta, blocks or custom tables with a documented schema, and we record the decision in the project's architecture notes so future developers understand the trade-off.

When we write our own

We build a custom plugin instead of installing one when the need is specific to the business, the available options are bloated for the small part we would use, or the functionality touches sensitive data where we want full control. Typical examples include CRM integrations, custom booking logic and bespoke content types with their own admin screens. Each lives in a well-structured, tested plugin that the client owns outright.

After launch, plugin hygiene is ongoing work. Updates are tested on staging before production, the plugin list is reviewed quarterly, and anything unused is removed. This is a core part of our monthly care plans, and it pairs naturally with WordPress security hardening. When the right plugin does not exist, our plugin development team builds it.

Get your plugin list reviewed

Export your active plugin list and send it over along with your biggest performance or stability concern. We will reply within a day with a fixed-price quote for an audit and cleanup plan.