Check a client’s plugins before you quote the job
You do not need access to the site, or a login, or the client’s permission to look at what is already public. Paste the URL and see every plugin it loads, when each one last shipped, and whether the WordPress.org directory still lists it. Free, no signup.
Scanning a site before you quote it
Most quotes on an existing WordPress site are priced off a conversation and a look at the front end, because that is all there is until somebody hands over a login. The plugins are the part that decides how the job actually goes, and they are visible from outside before any of that.
Scan the prospect’s URL and read the table before you write the number. A site running a dozen current plugins is a different job from one running four that have not shipped a release since 2022, and the second one is where the hours go: the plugin that breaks on the next PHP bump, the one whose settings screen nobody can explain, the one with no upgrade path off it.
Then you have three honest options rather than one guess. Price the ageing plugins into the quote as work you can point at. Scope them out explicitly, so nobody is surprised later about what was not included. Or offer to take them over as a maintenance line, which is usually the easiest thing on the list to say yes to, because it is the part the client already suspects is a problem.
What this checks, and what it cannot
We read the pages of your site that any visitor can see and find plugins two ways: from the stylesheets, scripts and images they load on those pages, and from the routes they add to the site's public REST API. Then we look each one up in the WordPress.org plugin directory and report four things: when the plugin was last released, which WordPress version its author last tested it against, whether the version on your site is behind the current one, and whether the directory still lists it at all.
This scan only detects plugins that load assets on the pages we can see publicly or add a route to the site's public REST API. 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.
If you only want to know about one plugin rather than a whole site, our plugin maintenance check covers a set of widely installed plugins one at a time, with the same signals and the date each one was read from the directory.
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. Here is what our scanner requests, and how to block it.
Why we will not tell you a plugin is vulnerable
Nearly every other free scanner will. We have decided not to, and it is worth saying why rather than leaving it as a gap in the feature list.
Usable vulnerability data for WordPress plugins sits behind paid commercial APIs. A free tool that does not pay for it has two options, and both are worse than silence. It can guess from version numbers, which flags plugins that are perfectly fine and sends people to rip out working code. Or it can flag the handful of famous cases and stay quiet on everything else, which quietly implies that everything unflagged has been checked and is safe. Nothing here has been checked for vulnerabilities, so we will not imply otherwise.
What we report instead is maintenance, and every part of it is a fact the WordPress.org directory publishes about the plugin: when its author last shipped a release, which WordPress version they last tested against, what the current version is, and whether the directory still lists it. Those facts are checkable, they are the same for everyone, and they are what actually predicts whether a plugin will still work after the next core release.
If you need vulnerability data, buy it from someone whose business is maintaining it. This report is the other half of the picture, and it is the half you can verify yourself.
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. The score does not read the forum, because the directory's resolved count depends on whether authors remember to mark threads resolved, but the forum is worth a look before you rely on a plugin.
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.
- 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.
- 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.
- 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.
- 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.
- 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, and a release date cannot tell you whether an author has moved on, so the report never labels a plugin abandoned. It reports what the WordPress.org directory publishes, and scores it like this. No release for 24 months or more costs 12 points and shows as Ageing. No release for 12 to 23 months costs 6 points and shows as Ageing. No release for 6 to 11 months costs 2 points and shows as Worth a look. A tested-up-to version 3 or more WordPress releases behind the current one costs 6 points and shows as Worth a look, but only while the last release is under 12 months old. A tested-up-to version 2 WordPress releases behind the current one costs 3 points and shows as Worth a look, but only while the last release is under 12 months old. A listing the WordPress.org plugin team has closed costs 25 points and shows as Removed, with the directory's own reason quoted. A listing withdrawn at its author's request costs 12 points and shows as Withdrawn, because the author may still distribute it elsewhere. Where we have confirmed the author still releases it, it costs nothing and shows as Updated elsewhere. An installed version a major release behind the directory's current one costs 8 points and shows as Outdated. An installed version a minor release behind the directory's current one costs 3 points and shows as Outdated. Within each of those groups only the most serious rule applies, and once a plugin has gone 12 months without a release the tested-up-to rules stop counting, because the two then describe the same gap. No single plugin can cost more than 30 points. Nothing else is scored: the PHP version a plugin supports and its support forum figures are not part of the score.
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 release date, the tested-up-to version, the installed version against the current one, 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, or that publish a route in the site's REST API under a name the WordPress.org directory recognises (or when the directory could not be reached to check). 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, a plugin whose author has moved on 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. A published report is not indexed by search engines either, unless you tick the separate box asking for that, which you can untick again at any time.
Can I scan a site I do not have access to yet?
Yes, and that is what it is for. The scan reads the same pages any visitor can see, so there is nothing to log into and nothing to install. That means you can run it on a prospect's site before you have been given a login, which is usually the point at which you are being asked for a number. It also means the scan sees only what is public: a plugin that runs entirely in wp-admin, or whose files have been bundled by a caching plugin, will not appear.
How should I price an ageing plugin into a quote?
Treat the last-update date as a question rather than a cost. A plugin with no release in three years is not automatically broken, but it is the one nobody will fix when PHP or WordPress next changes underneath it, so the work is finding out what you would replace it with and how much of the site depends on it. That is scoping work, and it is fair to quote for it separately from the job itself. The one thing worth avoiding is quoting a fixed price for a site with four unmaintained plugins in it as though it were a site with none, because the difference turns up later either way.
Can I share the report with the client?
Yes. Every scan is private by default, and the share panel publishes it to a link you can send. The published page shows the same score, findings and caveats you are looking at, including the note about what the scan cannot see, so nothing on it claims more than the report does. You can make it private again from the same panel, and it stays out of search results unless you separately tick the box asking for it to be indexed.