Software you install for free still costs something: the obligation to notice when it stops being looked after. A WordPress plugin is a piece of third-party code running inside your website with the same privileges as everything else, and nothing in the platform tells you when its author stops answering. Plugins do not announce their abandonment. They simply go quiet, and the site keeps working — until a WordPress or PHP update arrives that the plugin was never tested against.
This is an evaluation problem, and it deserves the same treatment as any other software decision: know the criteria before you commit, and re-check them periodically on what you have already committed to. Below are the signals that actually distinguish maintained from abandoned, how to run the audit, and what to do when something you rely on fails it.
The signals, in order of usefulness
1. Last updated, read as a trend
The plugin directory shows a "Last updated" date. On its own it is weak evidence — a small, stable utility may genuinely need no changes for a long stretch. What is strong evidence is the changelog: open it and look at the spacing between releases. A plugin that shipped four releases a year for five years and then nothing for eighteen months has changed state. A plugin that has always shipped once a year has not.
2. The compatibility notice
WordPress.org displays a warning on plugin pages that have not been tested with recent major WordPress releases. That notice is generated from metadata the author sets, which means it measures one very specific thing: whether the author has looked at this plugin recently enough to claim compatibility. It is one of the few maintenance signals the directory computes for you, and it is worth taking literally.
3. The support forum
Every directory plugin has a support forum with a visible resolved-versus-open ratio and, more importantly, visible dates. Read the last ten threads. Are recent questions answered by the author, answered by other users, or not answered at all? A forum where the newest developer reply is a year old tells you more than any download count.
4. Where the code actually lives
Many serious plugins develop in public. If there is a linked repository, look at the commit history, the number of people with commits in the last year (a single-maintainer project is a single point of failure), and whether issues get triaged or accumulate. A repository with hundreds of untouched open issues is not necessarily abandoned, but it is definitely under-resourced.
5. Ownership changes
Plugins get sold. When a popular free plugin changes hands, the outcome varies: sometimes it gets more investment, sometimes it gets monetised in ways you did not sign up for, occasionally it is left to rot as an acquisition byproduct. The changelog and the author's own announcements are where this surfaces. It is not automatically bad news — it is a reason to re-run your evaluation.
6. Active installs, read carefully
A large install count means many people would notice a problem, which has real value. It does not mean the plugin is maintained — install counts are lagging indicators and stay high for a long time after a plugin goes quiet. Treat it as a tiebreaker between two otherwise-equal candidates, never as a primary signal.
One thing that is not a signal: whether the plugin costs money. Paid plugins can be abandoned too, and free plugins backed by a healthy company can be maintained for a decade. Evaluate the maintenance behaviour, not the price tag.
Auditing what you already run
New installs are the easy case. The harder case is the twenty-plus plugins already on a site, most installed by someone who has since left. Run this once, then twice a year:
- Export the list. Plugins → Installed Plugins gives you names and versions;
wp plugin listgives you the same as a machine-readable table if you have CLI access. - Score each one on the signals above — last release cadence, compatibility notice, forum activity, repository health.
- Note what each one actually does. In almost every audit, some plugins are doing nothing: installed for a campaign that ended, superseded by a theme feature, or duplicating another plugin's job. Deactivating and deleting those is the cheapest risk reduction available, because code that isn't installed cannot break.
- Mark the load-bearing ones. Which plugins would stop the business if they failed — the forms, the payments, the booking, the membership? Those deserve a named replacement candidate written down now, while nothing is on fire.
This is stack hygiene, and it follows the same logic as any consolidation exercise: fewer moving parts, each one chosen deliberately. Our guide to building and pruning a software stack covers the wider version of that reasoning.
If nobody in your business is going to run this audit, it is reasonable to make it someone's contracted job. A WordPress maintenance provider such as WPCare does exactly this kind of routine inventory work as part of an ongoing plan — the value is not that the task is difficult, it is that it is recurring and easy to skip when everything looks fine.
What to do when a plugin you depend on goes quiet
You have four options, in rough order of preference:
Replace it. Best done deliberately, while the plugin still works, so you can run both and compare. The real cost is rarely the new licence — it is the data. Ask first: does this plugin store content in its own custom tables, and does the replacement offer an importer? Forms, custom post types, and page builders are the ones that hurt.
Freeze it. If the plugin is small, isolated, and does something you can inspect, staying on the last release while you plan is a legitimate short-term position — but only with a date attached. "We'll deal with it later" is not a plan; "we replace this before the next major PHP upgrade" is.
Adopt it. For an open-source plugin doing something genuinely specific to your business, forking it and paying a developer to keep it current can be cheaper than migrating. You now own it. Budget accordingly.
Absorb the function elsewhere. Sometimes the honest answer is that the plugin's job can be done by the theme, by core, or by not doing it at all. Every plugin you remove this way is a permanent reduction in surface area.
FAQ
How many plugins is too many?
There is no correct number, and count is the wrong metric anyway — ten well-maintained plugins are safer than four abandoned ones. What matters is that every installed plugin has a purpose someone can state and a maintenance status someone has checked. If you cannot say what a plugin does, that is the finding.
Is it safe to keep using an abandoned plugin?
It can be, for a while, and pretending otherwise is scaremongering. The honest risk is compounding rather than immediate: the plugin stops being tested against new WordPress and PHP releases, so it becomes the thing blocking updates you want elsewhere, and if a fault is found nobody upstream will fix it. The practical rule is to treat abandonment as a deadline, not an emergency — plan the replacement on your schedule rather than on the schedule of whatever finally forces it.
Does a plugin being free make it more likely to be abandoned?
Not reliably. Plenty of free plugins are maintained by companies who use them as a funnel for a paid tier, and plenty of paid plugins have been left to drift after their author moved on. Judge by release cadence, support responsiveness, and the number of people maintaining it — those hold regardless of price.
Who should own this check in a small business?
Whoever owns the website's uptime. In a company with no technical staff, that usually means it is written into a maintenance retainer with a stated frequency, because an audit that isn't scheduled doesn't happen. Ask for the plugin inventory as a report deliverable, not as a conversation.
Next step
Pull your installed plugin list this week and score the top five by importance against the signals above — release cadence, compatibility notice, support activity, and who is actually maintaining the code. That produces a short list of things to replace on your own timeline instead of someone else's. If you would rather have the audit arrive as a scheduled report, WPCare runs plugin and update oversight as part of its WordPress maintenance plans; whoever does it, insist that the output is a written inventory with a status per plugin — that document, not the tidy dashboard, is the thing you are buying.
