A plugin is abandoned when nobody is left to fix it. That is not the same as old, and your dashboard will not tell you which one you have. The answer sits on the plugin’s own page in the WordPress.org directory, and it takes about two minutes per plugin to check.
First, write down what is actually installed
In your dashboard, open Plugins. That screen lists every plugin on the site, active or not.
For a fuller view, open Tools, then Site Health, then the Info tab. The WordPress.org documentation for the Site Health screen describes two sections there, Active Plugins and Inactive Plugins. Each one shows the version of the plugin, the creator of the plugin, and whether auto-updates are switched on for it. That article was first published June 18, 2021 and last updated July 12, 2026.
Copy the names into a note, exact spelling. Include the inactive ones. Switching a plugin off leaves its code sitting on your server.
What the plugin page on WordPress.org tells you
Search the exact name at wordpress.org/plugins/. Three fields sit next to the description: Last updated, Tested up to, and Active installations.
“Tested up to” is typed in by the developer. The WordPress plugin developer FAQ, on developer.wordpress.org, tells developers to put in “whatever version you tested up to” and to “never go above the current release candidate”. The same FAQ says the compatibility warning turns up on a plugin page when the developer has “neglected to use a proper ‘Tested Up To’ value in your headers in your readme”. That page was last updated June 30, 2026.
So the field measures one thing, and it happens to be the thing you want to know. Did anybody show up.
If the plugin has been pulled from the directory, a notice sits at the top of its page with a date on it. The podPress page reads “This plugin has been closed as of November 28, 2017 and is not available for download. Reason: Unknown.” The Sociable page reads “This plugin has been closed as of August 9, 2021 and is not available for download. Reason: Security Issue.” Both listings still carry a Last updated field below the notice, and on the day this was written each of those read 9 years ago.
Closing a plugin stops copies going out. The same FAQ says: “When a plugin is closed, the page shows as closed and the zips are no longer generated. No one will be able to download the plugin via the website, nor will they be able to install it via the WordPress admin.” None of that reaches the copy already on your site. It keeps running as before, and the notice never leaves that page. You have to go and read it.
Two plugins that look healthy and are not
WP Logo Showcase Responsive Slider and Carousel shows 30,000 or more active installations, Tested up to 6.9.7, and a last update five months old. It also carries this line at the top: “This plugin has been closed as of April 7, 2026 and is not available for download. This closure is permanent. Reason: Security Issue.” Every number a normal person would check looks fine.
Database Backup for WordPress is not closed. Its page shows version 2.5.3, Tested up to 6.9.7, 60,000 or more active installations, and a last update four months old. Then the description says plainly: “Database Backups for WordPress is no longer actively maintained.” And a line later: “No additional releases, including security releases, will be made available.”
That is an honest developer doing you a favor, in the one place most owners never scroll to. Read the description, not only the dates. Both pages read that way on the day this was written. Go and look at them yourself before you act on any of it.
Why an abandoned plugin is different from an old one
Patchstack’s State of WordPress Security in 2026 report is marked “Data updated 25.02.2026”, which is February 25, 2026. It gives no separate publication date. The report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42 percent rise on 2024. 91 percent of them were found in plugins and 9 percent in themes. There were 6 in WordPress core itself, and the report calls those low priority issues.
The number that matters here is a different one. 46 percent of those vulnerabilities had no patch at the time they were made public. On a maintained plugin, a missing patch is a delay. On an abandoned one, there is nobody left to write it. The same report weights its figures by how much attack activity it actually observed, and on that basis puts the median time to a first exploit at five hours.
That evidence has a limit worth saying out loud. Those are counts of reported flaws, and a flaw gets counted after somebody goes looking. A quiet plugin with no reports against it has not been proven safe. It may just be one nobody has examined.
If a closure notice says Security Issue and your site is already sending mail you did not write, or bouncing visitors somewhere strange, stop sorting plugins. What to do when a WordPress site is hacked sets out that order of work instead.
When you should leave it alone
Not every abandoned plugin is a risk, and nobody should charge you to strip out all of them.
A plugin that prints a shortcode, adds a menu link, or renames a label touches very little. On a site that is otherwise patched, it may sit there for years and do nothing at all. The ones worth acting on first are the ones that handle logins, payments, file uploads, forms, or anything typed in by a stranger.
Two more limits, said straight:
- Pulling a plugin out can take a feature with it. A gallery, a form, a slider, or a price table can vanish from a live page, and switching off a page builder takes the whole layout with it.
- One dead plugin is not a reason to replace a website. If the pile grows every time you check, that is a fair question to ask, and repair against rebuild is where it belongs.
What to do next
- List every plugin, active and inactive, from the Plugins screen or from Site Health.
- Look each one up at wordpress.org/plugins/. Read the notice at the top, the last update date, and the description.
- Sort them into three piles: closed or declared unmaintained, quiet and low risk, and fine.
- Take a full backup before you touch anything, and make sure you can actually put it back.
- Start with the first pile. Look for a maintained plugin that does the same job, or ask whether the page still needs that feature at all. Clearing out the ones you simply stopped using is a separate pass, and an easier one.
- Switch one off, load the pages that used it on a phone, and look at them. If nothing broke, delete it rather than leaving it parked.
- Put a date in the calendar six months out and walk the list again.
None of this costs anything except your evening. If you would rather not repeat it twice a year for the life of the site, the other road is a site with no plugins to audit, which is how these builds are put together and comes with its own short list of what it cannot do. Either way, the list comes first.