WordPress Plugin Risk Report

What this checks, and what it cannot

We read the pages of your site that any visitor can see, find the plugins that load assets on them, and look each one up in the WordPress.org plugin directory. From there we report three things: when the plugin was last updated, which WordPress version its author last tested it against, and whether it is still listed in the directory at all.

This scan only detects plugins that load assets on the pages we can see publicly. Admin-only plugins, security plugins that hide their fingerprints, and plugins on pages we did not crawl will not appear. A high score means no problems were detected, not that no problems exist.

We do not check for security vulnerabilities, and we never claim a plugin is insecure. Staleness and support signals are facts the directory publishes. A vulnerability claim is a different thing entirely, and we are not in a position to make one honestly.

Nothing is installed and nothing is logged into. The scanner requests the same pages a visitor would, identifies itself in its user agent, and obeys robots.txt — what our scanner requests, and how to block it.

Why abandoned plugins matter

A plugin is code running inside your site with the same privileges as WordPress itself. While its author is active, that code gets fixed: when PHP raises its minimum version, when WordPress changes an API, when someone reports a bug. When the author stops, none of that happens — but the plugin keeps running, and nothing about your site announces that it has been left behind.

The failure is almost never dramatic on the day it happens. It is a host upgrading PHP, or a WordPress release changing a hook, and a plugin that has not been touched in three years quietly stopping. If that plugin is your checkout, your booking form or your member area, you find out from a customer.

The other cost is slower and easier to miss: a plugin nobody maintains is one nobody can support either. A plugin whose support forum has gone unanswered for a year is telling you something about what will happen when you have a question, which is why the score reads the support-resolution rate as well as the release history.

How to replace an abandoned plugin safely

Do not start by deactivating it. Start by finding out what it actually does on your site — which pages break without it, which data belongs to it, and whether anything else depends on it. A plugin that has been installed for five years usually owns more than the feature you remember it for.

1. Back up first, and take a copy you can restore. Database and files, not just files. Some plugins keep their data in their own tables, which a file-level backup will not bring back.
2. Check whether the replacement can import the data. The good ones document a migration path from the plugin they are replacing. If none exists, export what you can before anything is deactivated — the export screen usually disappears with the plugin.
3. Test on a staging copy, not on the live site. Most hosts create one in a click. Deactivate the old plugin there, activate the new one, and walk through every path that touched the feature.
4. Keep the old plugin installed but inactive for a while. Deleting it removes its data and its uninstall routine may drop its tables. Inactive costs you nothing but disk space; deleted is not reversible.
5. Watch the site after the switch. Errors from a swap usually show up on the paths you did not think to test — a confirmation email, a scheduled task, an admin export.

Judge the replacement by the same signals this report reads, because a plugin that is maintained today is the only one that will still be maintained after the next WordPress release: when it last shipped, which version its author tested it against, and whether anyone is answering its support forum. A narrow plugin with an active author is worth more than a broader one that has not been touched in two years — you are choosing a maintainer as much as a feature set. The WordPress and WooCommerce plugins we build are kept current against core releases on exactly that basis, if one of them covers what you need.

If nothing in the directory replaces what you have, the remaining options are to adopt the plugin yourself — the licence permits it — or to have a replacement built. Our guide to WordPress plugin development covers what maintaining one actually involves, including what “tested up to” is and why it goes stale, and custom WordPress plugin development is the work we do for the sites where adopting an abandoned plugin in-house is not realistic. And if the plugin you cannot replace is holding the whole architecture back, running WordPress as a headless CMS is sometimes the more honest answer than another plugin.

Questions

What counts as an abandoned WordPress plugin?

There is no official definition, so we use what the WordPress.org directory publishes about each plugin: how long it has been since the author released an update, how many WordPress versions have shipped since the one they last tested against, and whether the plugin is still listed at all. A plugin with no release for two years or more, or one tested only against a WordPress version several releases old, is reported as ageing. A plugin the directory has closed is the clearest case, and we quote the directory's own reason for closing it rather than paraphrasing it.

Does this tool check for security vulnerabilities?

No. We do not query any vulnerability database and we never say a plugin is insecure. Vulnerability data for WordPress plugins sits behind paid commercial APIs, and a free tool guessing at it would be wrong in the direction that does real damage — either alarming you about a plugin that is fine, or implying that everything not flagged is safe. What we report is maintenance: the last update date, the tested-up-to version, the support-resolution rate and the directory status. Those are facts the directory publishes about a plugin, not a judgement about its code.

Why can it not see all of my plugins?

We only see plugins that load a stylesheet, a script or an image on the pages a visitor can reach. Plugins that run only in wp-admin, plugins that do their work server-side with no front-end assets, and plugins whose files have been merged into one bundle by a caching or optimisation plugin will not appear. Some security plugins deliberately rename the plugin paths, which has the same effect. A short list here is not evidence of a small install — it is evidence of what is visible from outside.

Is it safe to keep a plugin that has not been updated in two years?

Sometimes, yes. A small plugin that does one narrow thing may genuinely need no changes for years, and WordPress is unusually careful about backwards compatibility. The date on its own is not the risk. The risk is what happens when something else changes: when PHP or WordPress ships a breaking change, an unmaintained plugin is the one nobody will fix, and you find out on the day your site breaks rather than in advance. Treat a long gap as a reason to know what you would replace it with, not as a reason to remove it today.

Does a plugin missing from the WordPress.org directory mean something is wrong?

No, and it is the most common false alarm. Most plugins that are not in the directory are commercial ones sold from the developer's own site, or plugins built specifically for that site. We apply no penalty at all in this case: the plugin is listed as not in the directory and deducts nothing from the score, because having no public data to judge a plugin by is not the same as finding something wrong with it.

Do you store the results of my scan?

We store the findings, and a one-way hash of the address rather than the address itself, so that scanning the same URL again within a day returns the same report instead of crawling the site a second time. Every scan is private by default. Nothing shows the domain publicly unless you press the button that publishes it — and a published report can be made private again from the same panel, and is never indexed by search engines.