Run the WP-CLI plugin list command on each site with JSON output, then merge the results into one table keyed by site. The output includes plugin name, status, version, pending update version and auto-update setting. That single file answers the question every agency gets during an incident: which of our sites run this plugin?
Why a per-site dashboard is not enough
When a plugin advisory lands, you need the answer in minutes, not after logging in to fifty admin screens. The wp-admin Plugins page shows one site at a time. A shared export gives you a fleet view that you can search, diff week to week, and hand to a client.
The WP-CLI handbook describes the command as displaying the plugins installed on a site with activation status and whether an update is available. By default it prints name, status, update, version, update_version and auto_update. Optional fields include title, author, tested_up_to, requires, requires_php, wporg_status and wporg_last_updated.
Steps
- Make sure you can reach each site with WP-CLI, either on the server or through the SSH global parameter that the handbook documents.
- Run the list command with JSON output for one site and confirm the shape.
- Loop over your site paths or SSH targets and write one JSON file per site.
- Merge the files into one table with a site column.
- Keep the export in a dated folder so you can compare it next week.
wp plugin list --format=json --path=/var/www/client-a > client-a.json
wp plugin list --format=json --path=/var/www/client-b > client-b.json
On a Multisite network the handbook shows looping over each site URL, so each subsite gets its own listing.
Which fields to keep
| Field | Why it matters |
|---|---|
| name | The slug you match against advisories |
| version | Which release is installed |
| status | Active, inactive, must-use, or network active |
| update_version | Whether a newer release is waiting |
| auto_update | Whether the site updates this plugin itself |
| wporg_status | Whether the plugin is still listed on WordPress.org |
Ask for the status filter set to must-use as well. Must-use plugins do not appear in the normal list on the Plugins screen, so they are easy to miss in a manual audit.
What the export does not cover
The list shows what is installed in the plugins folders. It does not show libraries that a plugin bundles inside its own vendor folder, and it does not show themes. Add a second export for themes, and if a site is built with Composer, keep the lock file with your inventory.
Also remember that an installed but inactive plugin is still code on disk. Record it, then decide whether to delete it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one inventory answers which projects contain a given package.
Where Safeguard fits
If your sites use Composer, Safeguard can scan the dependency manifests and produce an SBOM, and you can try the free scan at gold.safeguard.sh/scan. The WP-CLI export is still the quickest way to see plugins that live outside a manifest.
Quick check
Do I need admin logins to run this?
You need shell access to the server or an SSH route that WP-CLI can use, not wp-admin credentials.
How often should I refresh the export?
Weekly is a sensible start, and again whenever an advisory affects a plugin you run.
Sources
Last reviewed: 19 October 2026.
