Run the WP-CLI plugin list command with the fields option set to name, wporg_status and wporg_last_updated. It checks each installed plugin against WordPress.org and reports whether it is still active there and when it last changed. Do this across your client sites to find plugins that were closed or have gone quiet.
The command
The WP-CLI handbook includes this exact use, headed as checking whether plugins are still active on WordPress.org.
wp plugin list --fields=name,wporg_status,wporg_last_updated
The output has a row per plugin. The wporg_status field tells you the directory status, and wporg_last_updated gives the date of the most recent update there. The command also supports JSON and CSV output, so you can merge many sites into one sheet.
How to read it
| Signal | What it suggests | Next step |
|---|---|---|
| Status not active | Plugin may be closed or removed | Read why, then plan a replacement |
| Last updated long ago | Maintenance may have stopped | Check the plugin page and support forum |
| Plugin missing from the directory entirely | Premium, custom, or removed | Confirm its origin and update path |
A long gap since the last update is a prompt to look, not proof of risk. Some small plugins are finished and stable. Our post on last commit two years ago explains how to judge that.
What happens when a plugin is closed
A closed plugin is no longer available for download, and the reason is often a security issue or a guideline violation. Our post on what happens when a plugin is closed for security covers the site owner's options. The point here is to learn about it from your own check rather than from a client.
A weekly routine
- Run the command on every site, or on one site per distinct plugin set.
- Save the output to a dated folder.
- Diff against last week. New non-active statuses are your alert list.
- For each, decide: replace, fork under review, accept the risk with an expiry date, or remove.
- Tell the client in plain language, with a date.
Limits
The check relies on a directory lookup, so a plugin installed from elsewhere will not have a meaningful status. Premium plugins need a separate source of truth, such as the vendor's changelog. The handbook example shows the fields only for plugins WordPress.org knows.
Try it yourself
Click through it at your own pace, or open it full screen. See how a recurring check catches a change that a one-time review misses.
Recording decisions
For every flagged plugin, write down the decision and a review date. If you choose to accept the risk, set an expiry so the exception returns to the list. If you choose to replace, name the replacement and the owner. This turns a weekly command into evidence that you track plugin health, which is exactly what a client or auditor will ask to see.
Quick check
Does a missing status mean the plugin is dangerous?
No. It may be a premium or custom plugin. It means you need another way to track it.
How often should I run it?
Weekly is practical, plus after any advisory affecting a plugin you run.
Sources
Last reviewed: 19 October 2026.
