How to Evaluate a WordPress Plugin Before You Install It

Knowing how to choose WordPress plugins is one of the most underrated skills a site owner can have, because every plugin you activate is code your business now depends on – code you did not write, from a developer you have never met, running with full access to your database. Most WordPress disasters I get called in to fix trace back to a plugin: a hacked site running an abandoned gallery plugin, a shop that takes eight seconds to load because of three overlapping “optimisation” tools, a white screen after an update nobody tested. None of these needed to happen. Ten minutes of vetting before clicking Install would have prevented almost all of them.

After twelve years and more than 500 WordPress projects, I have installed, audited, removed and replaced thousands of plugins, and I have a routine I run on every single one before it goes near a client site. This guide is that routine written out: what a plugin actually adds to your site, the checks I run on the plugin page, how to read reviews so they tell you the truth, what licence models mean in practice, how to test on staging with Query Monitor, how to spot a plugin that is quietly dying, how to remove one safely, and when you should skip the plugin entirely and write twenty lines of code instead.

Table of contents

• What you really install when you install a plugin
• The 10-minute vetting checklist
• Reading reviews properly (start with the 1-star ones)
• Free vs pro vs bundled licences
• Testing on staging with Query Monitor
• The plugin overlap audit: one job, one plugin
• Abandonment risk: how plugins die quietly
• Safe removal: what uninstall leaves behind
• When custom code beats a plugin
• My keep-list philosophy: fewer, boring, maintained
• Frequently asked questions

What you really install when you install a plugin

The Install button makes it feel like adding an app to a phone, but a WordPress plugin is nothing like a sandboxed app. It is PHP code that runs inside your site with the same permissions WordPress itself has. It can read and write every table in your database, create admin users, send email as your domain, call external servers and modify every page before it reaches a visitor. That is why plugins are so powerful – and why the decision to install one deserves more than four seconds of thought.

Every plugin you activate adds three permanent costs, whether you notice them or not:

• Attack surface. The overwhelming majority of hacked WordPress sites I clean up were breached through a plugin vulnerability, not through WordPress core. Core is maintained by hundreds of developers and audited constantly; a plugin might be maintained by one person in their spare time. Each plugin is another door into your site, and you are trusting its author to keep that door locked. I cover the wider picture in common WordPress security mistakes, but the short version is: plugin count and hack risk rise together.
• Load. Plugins add database queries, PHP execution time, and very often CSS and JavaScript files to your front end – sometimes on every page, even pages where the plugin does nothing. A contact form plugin that loads its scripts on your entire site is a classic example. Individually these costs are small; ten plugins later, your site is a second slower and you cannot say why.
• Update duty. A plugin is not a one-time purchase, it is a subscription of attention. Every plugin needs updating for as long as it is installed, every update is a small risk of breakage, and every plugin that stops receiving updates becomes a slowly ripening security problem. Install twenty plugins and you have signed up to shepherd twenty codebases for the life of the site.

None of this means plugins are bad. WordPress without plugins would not be worth using, and a well-chosen plugin is often the fastest, safest way to add a feature. It means the decision should be made the way you would choose a supplier for your business: deliberately, with a few minutes of due diligence, and with a bias towards fewer, better dependencies.

The 10-minute vetting checklist

Here is the routine I run on the WordPress.org plugin page (or the vendor’s site for commercial plugins) before anything gets installed. It takes about ten minutes and filters out the vast majority of future problems.

• Last updated: within six months. The plugin page shows the last update date near the top. Within the last few months is healthy. Six to twelve months is a caution flag – fine for a tiny, stable utility, worrying for anything complex. Over twelve months, I treat the plugin as unmaintained and look for an alternative, whatever its star rating says.
• Tested up to: the current WordPress version. “Tested up to” one or two versions behind is common and usually harmless, but combined with an old update date it confirms the author has stopped paying attention. Also check the required PHP version: a plugin that only promises compatibility with PHP versions that reached end of life years ago has not been touched in a long time, whatever the changelog claims.
• Active installs: enough to matter. I like 10,000+ active installs for anything important. Popularity is not quality, but it means bugs get found fast, security researchers pay attention, and the author has a reason to keep maintaining it. A plugin with 200 installs can be excellent, but you are one of very few testers, so it needs a closer look at everything else on this list.
• Support threads: answered, recently. Open the Support tab and look at the last two months. You are not looking for zero problems – every real plugin has support threads – you are looking at whether the author responds, how quickly, and in what tone. A wall of unanswered threads is the single most reliable early sign of abandonment. An author who replies within a few days, even to say “this is a known issue, fix coming”, is worth more than a five-star average.
• Changelog: tells a story. Open the Development tab and read the changelog. A healthy one has dated entries with specific fixes and features: “Fixed: date field validation on multi-step forms”. A lazy one says “bug fixes and improvements” every time, which tells you nothing and often hides the fact that releases are just compatibility bumps. Security fixes mentioned openly in the changelog are a good sign, not a bad one – it means the author takes reports seriously and discloses them.
• The author’s other work. Click the author name. A developer with several maintained plugins and a company behind them is more likely to still be here in three years than an anonymous account with one plugin and no website. For commercial plugins, look for a public roadmap or blog – silence everywhere is a bad sign at any price.

Here is the same checklist as a quick reference table – what healthy looks like against what should make you close the tab:

If a plugin passes all of this, it has earned a staging test – which is the second half of the vetting and the part almost everybody skips. More on that below.

Reading reviews properly (start with the 1-star ones)

The star average on a plugin page is close to useless. Almost every plugin with real usage sits between 4.2 and 4.8, happy users rarely review anything, and some vendors actively campaign for five-star ratings inside the plugin interface. The information is in the distribution and in the text, and the fastest way to get it is to read the one-star reviews first.

One-star reviews come in patterns, and the patterns matter more than the count:

• “Broke my site after the update” – appearing repeatedly across different dates suggests weak release testing. One occurrence means little; a cluster around each release is a habit.
• “Support never replied” – cross-check against the support forum. If the threads confirm it, believe it. Paid plugin with this pattern: run.
• “It is all upsells now” – common with plugins that were acquired by a larger company. Check whether recent versions stuffed the admin with ads and locked previously free features behind a pro tier. This pattern also predicts your future with the plugin.
• “Suddenly asks for strange permissions / phones home” – rare but serious. A handful of reviews mentioning unexpected external requests or bundled tracking deserves real weight.
• Angry user error – plenty of one-star reviews are people who did not read the description. These are actually reassuring: if the worst anyone can say is that they misunderstood the product, the product is probably fine.

Then read a few recent four-star reviews – in my experience they are the most honest ones, written by people who use the plugin daily and know exactly what its weaknesses are. Finally, check the dates: a plugin whose glowing reviews are all four years old while the recent ones complain about neglect is showing you its trajectory, and trajectory beats average every time.

One more habit: search the support forum for the words “vulnerability” and “security”. Finding a thread where the author responded quickly and shipped a fix within days is one of the strongest positive signals a plugin can have. Finding a report with no response is disqualifying.

Free vs pro vs bundled licences

How a plugin makes money tells you a lot about how long it will live and how it will treat you. There are four models worth understanding before you depend on one:

• Genuinely free. Maintained as a service to the community, a portfolio piece, or a lead generator for the author’s services. Perfectly fine for small utilities, but for anything critical, ask what happens when the author gets a full-time job. No income usually means no long-term guarantee.
• Freemium (free core + pro version). The healthiest model in the WordPress ecosystem, and the one behind most plugins I trust. The free version gets wide testing and fast bug discovery; the pro revenue pays for maintenance. Check where the feature line sits – if the free version is a crippled demo, you are really evaluating the pro price, so evaluate it honestly, renewal cost included.
• Pro only (annual licence). Standard for serious commercial plugins. The annual fee is not a rip-off, it is the maintenance funding – a plugin with recurring revenue is far more likely to still be updated in five years. Budget for renewal from day one: an expired licence usually means no updates, and an un-updated commercial plugin is exactly as dangerous as an abandoned free one. Whether the plugin keeps working after expiry varies by vendor, so check before you buy, not after.
• Bundled with a theme. The problem child. Page builders, slider plugins and premium add-ons bundled inside a theme purchase have no licence of their own – you get updates only when the theme author repackages them, which is always later than the official release and sometimes never. I have cleaned up multiple hacked sites where the entry point was a bundled slider plugin sitting months behind its patched version. If a bundled plugin matters to your site, buy your own licence for it; if that feels like paying twice, that is the true cost of the “free” bundle showing itself.

A rule that has served my clients well: any plugin your business genuinely depends on – forms that capture leads, the booking system, anything touching payments – should be a plugin someone is being paid to maintain, by you or by thousands of other customers. Free is fine at the edges; the core of the site deserves funded code.

Testing on staging with Query Monitor

The plugin page tells you whether the author is trustworthy. Only a test install tells you what the plugin does to your site. I never activate a new plugin on a live client site first – it goes on a staging copy, with the free Query Monitor plugin active as the measuring instrument.

The test takes fifteen minutes and answers four questions:

• What does it add to every page? With Query Monitor open, load the home page and a normal content page before activating the new plugin, and note the database query count, page generation time and the list of enqueued scripts and styles. Activate the plugin and load the same pages again. The difference is the plugin’s true cost. A well-built plugin adds little or nothing to pages where it is not used; a badly built one loads its full CSS and JavaScript everywhere and fires queries on every request. I have measured single plugins that added 40+ queries to every page load – that one plugin was most of the site’s speed problem, and the owner had no idea.
• Does it log errors? Query Monitor shows PHP notices and warnings. A plugin spraying deprecation warnings on a current PHP version is telling you its code is old and its author is behind – remember that when the next PHP upgrade comes around.
• What does it write to the database? Check the options table growth and whether the plugin autoloads big blobs of settings (Query Monitor shows autoloaded options size). Plugins that dump hundreds of kilobytes into autoloaded options slow down every single request, admin and visitor alike.
• Does it play politely? Click through your key journeys – menu, forms, checkout if you have one – and check nothing broke. Plugin conflicts usually appear immediately or not at all, and staging is the place to find out.

If a plugin fails the performance test but you need the feature, check whether an asset manager or the plugin’s own settings can restrict it to the pages that need it. Some plugins are good citizens with one checkbox ticked. Others are structurally heavy, and no setting fixes that – keep looking. This measurement habit is the same one behind my whole approach to performance; the full method is in my complete WordPress speed guide.

The plugin overlap audit: one job, one plugin

Before installing anything new, look at what is already there, because the most common plugin problem I find in audits is not one bad plugin – it is three plugins doing overlapping jobs. Two caching plugins fighting over the same pages. An SEO plugin plus two extra schema plugins. Jetpack running modules that duplicate four other installed plugins. A security plugin, a firewall plugin and a login-protection plugin all hooking the same login form.

Overlap is worse than redundancy: overlapping plugins conflict, double their performance cost and make debugging miserable, because you can never be sure which plugin caused what. The rule I enforce on every site I maintain is one job, one plugin. Run the audit like this:

• List every active plugin and write its job next to it in plain words: “contact form”, “SEO”, “caching”, “backups”, “gallery”. If you cannot say what job a plugin does, deactivate it on staging and see what changes – I regularly find plugins nobody can explain, installed by a previous developer for a reason lost to history.
• Where two plugins share a job, keep the better one – the one that passed the vetting checklist – and remove the other completely.
• Check the multi-tools. Suite plugins like Jetpack and the big optimisation bundles do many jobs at once; open their module settings and switch off everything another dedicated plugin already covers, or better, everything you do not actively use.
• Question the one-trick conveniences. Plugins that exist to add one code snippet, one redirect or one small tweak accumulate fast. Five of them equal one small custom plugin that does all five jobs with no update duty to strangers – more on that below.

Plugin count itself is a crude measure – fifteen well-built plugins beat eight bad ones – but in practice, every site I audit above about twenty plugins contains overlap, and every removal makes the site faster, safer and easier to reason about. The best plugin stack is the one where every entry has a job, does it well and has no understudy.

Abandonment risk: how plugins die quietly

Plugins rarely announce their death. They just stop. The author changes jobs, loses interest or shuts the company, and the plugin keeps sitting on your site, working normally, while its code drifts further behind WordPress, PHP and the attackers who read vulnerability disclosures for a living. An abandoned plugin can run fine for two years and then take your site down – or let someone else in – in an afternoon.

Because abandonment is gradual, you catch it by trajectory, not by any single event. These are the signs I watch for, roughly in the order they appear:

• Release rhythm slows, then stops. A plugin that shipped monthly now ships twice a year, then only compatibility bumps, then nothing. The changelog shows this at a glance.
• Support goes quiet. Reply times stretch from days to weeks; then threads simply sit unanswered. This usually precedes the last release, not follows it.
• “Tested up to” freezes. Two WordPress versions behind and not moving is the ecosystem’s clearest public signal that nobody is home.
• The author disappears. Website not renewed, blog silent, no response to direct contact. For commercial plugins: renewal emails stop, or the payment page breaks.
• Install count declines. Other users are leaving. WordPress.org shows active install growth on the plugin page – a steady downward trend means the people paying closer attention than you have already gone.
• Ownership changes hands. Not always fatal – some acquisitions revive plugins – but a sale to an unknown buyer is a risk event: several real supply-chain attacks have come through purchased plugins that shipped malicious “updates” to their inherited install base. When a plugin you use is sold, read the next two changelogs with extra care.

What to do when you spot the signs: do not panic-delete, but start the exit. Shortlist a maintained replacement with the vetting checklist above, test it on staging, plan the migration of any data, and switch on your schedule rather than during an emergency. For a working plugin, you might have months of margin; for one with a published vulnerability and no fix, you have none – replace it now. This yearly plugin health review is part of the routine on the sites in my care plans; the plugin stack gets a trajectory check just like backups and updates get their checks.

Safe removal: what uninstall leaves behind

Removing a plugin properly matters almost as much as choosing it well, because most plugins do not clean up after themselves. Deactivate and Delete removes the plugin’s files – but its database tables, options, post meta and scheduled tasks usually stay behind forever. I have audited databases where more than half the options table belonged to plugins removed years earlier, all of it loading on every request.

My removal routine:

1. Back up first. Removal is a change like any other, and some plugins do destructive things on uninstall – the backup is your undo button.
2. Check what the plugin owns. Forms, redirects, snippets, SEO data, events, orders – anything created inside the plugin may become unreachable or vanish when it goes. Export what you need before touching anything (form entries and redirect lists are the classic losses).
3. Look for a cleanup setting. Well-built plugins have an option like “remove all data on uninstall” in their settings. Switch it on before deleting, and the plugin’s own uninstall routine does the tidy work for you.
4. Deactivate, then observe. On staging first, then live: deactivate and use the site for a day or two before deleting. Deactivation is instantly reversible; deletion is not.
5. Delete, then check the residue. After deletion, a database cleanup pass: leftover tables carrying the plugin’s prefix, autoloaded options with its name, orphaned cron events. Plugins like WP-Optimize or a developer with database access can clear these. On a site with years of history this cleanup alone can noticeably shrink the database and speed up the back end.
6. Remove the licence and the account. For commercial plugins: deactivate the licence on the vendor’s site so the seat frees up, and cancel the renewal if nothing else uses it.

The residue problem is also a vetting criterion in reverse: plugins that document their uninstall behaviour and offer a clean-removal option were built by people who think about the whole lifecycle – which is exactly who you want to depend on.

When custom code beats a plugin

Sometimes the right answer to “which plugin should I install?” is “none”. A surprising share of plugin installs exist to do something twenty lines of code would do better: add a snippet to the site head, register a custom post type, tweak a WooCommerce label, hide an admin menu, add a shortcode. Each of those, done with a plugin, brings a full codebase, its update duty and its author’s business model along for the ride. Done as a small custom plugin or a few lines in a child theme, it brings nothing but the twenty lines.

My rule of thumb after 500+ projects:

• A plugin wins when the job is big, standard and actively evolving: forms, SEO, caching, backups, e-commerce, security scanning. These need constant maintenance against a moving target, and thousands of users co-fund that maintenance. Building your own forms plugin is almost always a mistake.
• Custom code wins when the job is small, specific to your site, and stable: one integration between your form and your CRM, one custom post type, one pricing rule, one automated email. The requirements will not change monthly, so the “update duty” a plugin implies buys you nothing – and generic plugins that cover such cases are usually 95% features you do not need, wrapped around the 5% you do.
• Custom also wins on plugin sprawl. When five utility plugins each do one small thing, one tiny site-specific plugin can replace them all – fewer dependencies, faster site, one place to look.

Cost is smaller than most owners expect: at my rate of EUR 15 per hour, a typical utility plugin replacement is one to three hours of work, often less than a year of a pro licence it replaces. I go through the full decision – with real examples and real numbers – in when do you need a custom WordPress plugin, and building exactly these small, boring, site-specific plugins is a big part of my WordPress plugin development work for clients and agencies.

My keep-list philosophy: fewer, boring, maintained

After all the checklists, the actual philosophy fits in three words: fewer, boring, maintained.

• Fewer. Every plugin must justify its place with a job that matters. Before installing anything I ask: does the theme already do this? Does an existing plugin already do this? Would twenty lines of code do this? “It might be useful someday” is not a reason – install it the day it is useful. Sites I build typically run eight to fifteen plugins, and every one has a one-line answer to “why are you here?”.
• Boring. I choose the plugin that has been quietly doing one job for eight years over the exciting new one with the animated landing page. Boring plugins have survived WordPress updates, PHP migrations and security research. New plugins can earn a place, but on a side project first – not on the site that pays your invoices. The same instinct applies to features: the plugin with the shortest feature list that still covers the need is usually the fastest and safest choice.
• Maintained. The vetting checklist decides entry; the yearly trajectory review decides who stays. A plugin that stops being maintained loses its place, however well it still appears to work, because you are always choosing between a planned replacement now and an emergency replacement later – and the planned one is always cheaper.

The payoff for this discipline is not abstract. Sites with small, vetted, maintained plugin stacks update without drama, load fast without heroics, and almost never appear in my emergency inbox. Sites with sixty accumulated plugins are where the hacks, the white screens and the mystery slowdowns live. The difference between the two is not budget or luck – it is ten minutes of vetting per plugin and one honest audit per year.

Want your plugin stack audited – or a plugin replaced with something better?

I audit plugin stacks, replace abandoned and overlapping plugins, and build small custom plugins that do exactly what your site needs – as part of my WordPress maintenance and security plans or as a one-off project at EUR 15 per hour. See my portfolio, or tell me what your site is running – I reply within 24 hours with an honest assessment, including the plugins you should simply keep.

Frequently asked questions

How do I choose WordPress plugins safely?

Check five things before installing: last update within six months, tested with the current WordPress and PHP versions, an active support forum with recent author replies, a specific dated changelog, and enough active installs that bugs get found. Then test on a staging site with Query Monitor before it touches your live site.

How many plugins is too many for a WordPress site?

There is no magic number – quality matters more than count – but most well-built business sites need eight to fifteen. Above about twenty, audits almost always find overlap and dead weight worth removing.

Are free WordPress plugins safe?

Free plugins from the official WordPress.org directory are reviewed on submission and safe to try if they pass the vetting checks – maintained, supported, widely used. The risk is not “free”, it is “unmaintained”, which affects paid plugins with expired licences just as much.

How can I tell if a plugin is abandoned?

No update for over a year, “tested up to” stuck several WordPress versions back, unanswered support threads and a falling install count. Any two of these together mean you should start planning a replacement.

Do deactivated plugins slow down or endanger a site?

Deactivated plugin code does not run, so the performance impact is negligible – but the files still sit on your server and can contain exploitable code. Delete plugins you are not using; reinstalling later takes one minute.

Should I test every plugin on staging first?

Every plugin that will run on a business site, yes. Fifteen minutes with Query Monitor on a staging copy shows you the queries, scripts and errors a plugin really adds – which the plugin page will never tell you.

When is custom code better than a plugin?

When the job is small, site-specific and stable – one integration, one content type, one tweak. A few hours of custom development often replaces several utility plugins and removes their update burden permanently.