WordPress Plugin Audit: Find Unused Plugins Without Breaking the Site (2026 Agency Guide)

You open Plugins on an inherited client site. 47 active plugins. Three SEO tools. Two caches. A form plugin replaced two years ago but still activated. The client — a US federal contractor — asks: "Can we clean this up before the CMMC assessment?" You hesitate — because deleting the wrong plugin breaks checkout, transactional emails, or a shortcode buried in a 2019 page.

You're not alone. Every week US agencies, federal contractors, and WordPress maintenance firms write to us after bulk deactivating "to lighten the site" — then discovering an admin-only plugin handled WooCommerce webhooks, or that an SEO "duplicate" was the only one with migrated 301 redirects. Manual audit (Excel + DB grep) takes hours and stays incomplete.

This guide exists because we see two extremes: let bloat accumulate (slowness, attack surface, hosting bills, FedRAMP violations), or delete blindly without usage signals. The right answer is in the middle: multi-signal audit, trust score, staging before removal, and a clear list of when not to touch.

Why read this article? You'll understand what Plugin Usage Detector (PUD) does, how to read the 7 statuses and trust score 0–100, how to run a 7-step agency audit, which plugins to never delete without validation, and how PUD honestly compares to WP Usage Analyzer, Unplug, Query Monitor, Orpharion, and manual audit. Comparison tables, error playbook, checklist for this week, FAQ from real support tickets.

What you'll learn: content/cron/options/widget signals · infrastructure vs zombie bloat statuses · Full audit / WooCommerce / Security presets · synergy with PHP Compatibility Checker and Heartbeat Control Manager · client JSON export · WP-CLI wp pud scan · FedRAMP and CMMC plugin audit alignment.

Let's start with the fundamentals — then move to action.

Why US agencies must audit plugins in 2026

Plugin bloat isn't just a performance problem — it's a compliance liability for US federal contractors, state agencies, healthcare organizations, and any organization that reports to a security framework. Unlike the European focus on GDPR cookie consent plugins, US agencies face a different set of pressures.

The compliance pressure points

Why US agencies accumulate more plugins

WordPress site inventories in US government-adjacent environments tend to bloat faster than commercial sites:

• Compliance-driven installation: security plugins installed for audits, never removed post-assessment
• Grant-funded development: features added during grant cycles, plugins left active after grant ends
• Multiple stakeholder requirements: each department installs their preferred tool without central governance
• Contractor turnover: agencies inherit plugins from past contractors who didn't document usage
• .gov and .mil migration: agencies moving from legacy CMS to WordPress carry over redundant plugins

A 2025 analysis of 200+ US government WordPress sites found the average active plugin count was 34, with 22% of plugins having zero usage signals in content, cron, or widgets — classic likely_unused candidates.

Field feedback — US agencies (anonymized)

"

We needed a plugin inventory for our CMMC Level 2 assessment. Our assessor required evidence that every installed plugin served a documented function. PUD gave us a classified inventory — we removed 14 plugins per site on average, and the JSON export became part of our POA&M evidence package. The assessor accepted it.

— Federal contractor — DC metro area (47 sites under CMMC assessment, February 2026)

"

Our security audit flagged 9 "high-risk" plugins with known CVEs. Three were inactive zombie plugins still on disk — they showed up on our vulnerability scanner but weren't actually running. PUD's zombie_bloat status helped us prove they were inactive, and we removed them to close the finding.

— State university — California (3 multisite networks, April 2026)

"

A plugin audit was part of our annual HIPAA security evaluation. We had 6 form plugins, 3 of which were likely_unused. But one admin_only plugin with trust score 42 was actually handling HL7 message routing via cron — PUD caught it. Without that cron signal, we would have deleted our patient data pipeline.

— US healthcare provider — Texas (HIPAA compliance, May 2026)

What Plugin Usage Detector does — and why multi-signal

Before changing anything, name the mechanism. PUD is not an "automatic cleaner" deactivating extensions in the background. It's an audit engine: it cross-checks multiple usage signals and produces a classified report — you decide next, with staging and backup.

How the multi-signal scan works

1. You run a scan from Tools → Plugin Usage (or a one-click preset).
2. PUD analyzes content (shortcodes, Gutenberg blocks), widgets, cron hooks, options footprint (autoload included).
3. Each plugin gets a status (e.g. active_used, likely_unused, zombie_bloat) and a trust score.
4. Overlaps (two caches, two SEO, two backups) are flagged when the preset requests it.
5. You export JSON for the client folder — then plan removals one at a time on staging.

Tools → Plugin Usage  →  Full audit preset  →  read statuses  →  staging  →  deactivate in batches

The 7 statuses — quick definition

What PUD protects (don't break this)

• Infrastructure catalog: WooCommerce, cache, security, backup marked always_on — not naively classified "likely unused".
• Transparent trust score: breakdown content / widgets / cron / options / autoload — not a black box.
• Overlap warnings: two SEO plugins, two caches — you choose which to keep.
• Ignore list: exclude a plugin from the report (MU-plugins, client custom).

What PUD does not do

• No automatic deletion — deliberately, for agency traceability.
• No Query Monitor replacement for live request debugging — PUD is fleet audit, not a profiler.
• No "100% safe to delete" guarantee — a shortcode in an unscanned custom CPT may escape deep content (500 posts by default).

Concrete example

An agency takes over a WooCommerce store with 52 plugins. PUD scan with WooCommerce cleanup preset: 4 payment gateways including 2 likely_unused, 3 cache plugins including 2 inactive zombie_bloat, 1 form plugin admin_only with 12 cron hooks (ERP webhooks). Result: -8 plugins after staging, DB autoload -340 KB, checkout tested — without touching the ERP plugin thanks to admin_only status + trust score 68.

"Am I concerned?" — 5 signs

1. You inherit a site with 30+ plugins and no documentation.
2. The client asks for a "cleanup" before contract renewal.
3. You're preparing a PHP upgrade and want to remove dead weight before the compatibility scan.
4. You suspect two SEO or two cache plugins in silent conflict.
5. You bill WordPress maintenance and want a reproducible audit deliverable.

If at least two apply: read the 7-step guide — after staging backup.

Trust score — how to read it without mistakes

The trust score (0–100) measures PUD's confidence in its classification — not plugin "quality" or business importance.

Score composition

Practical interpretation

Trust score vs status — which to listen to?

Status drives the decision; score refines confidence. Example: admin_only + score 72 = very likely a legitimate back-office tool. likely_unused + score 8 = deactivate on staging without hesitation.

When not to delete — even if PUD says "likely unused"

Classification is guidance, not an order. Here are cases where we recommend not touching without human validation.

Red list — don't delete without deep audit

Statuses to treat carefully

• infrastructure: never delete "to clean up" — migrate first (e.g. one cache only).
• admin_only: often CRM, stock sync, webhooks — deactivation = lost orders.
• uncertain: worst case for direct prod deletion — always staging 48 h.

PCC and HCM synergy

Before or after the usage audit, two Volade tools complement PUD:

Typical agency workflow: PUD audit → staging purge → PCC PHP scan → HCM WooCommerce preset → prod.

Plugin audit methodology — US agency standard

Before walking through the 7-step workflow, it's worth understanding why PUD's approach maps directly to US agency audit methodology. The multi-signal scan isn't arbitrary — it aligns with established frameworks for configuration management and software inventory.

NIST 800-53 CM-8 mapping

NIST SP 800-53 control CM-8 requires organizations to develop, document, and maintain an inventory of components. For WordPress, each plugin is a component. PUD directly addresses CM-8 requirements:

CMMC CM.2.061 alignment

CMMC Level 2 control CM.2.061 requires organizations to "establish and maintain baseline configurations." A plugin audit is explicitly part of this:

1. Baseline capture: PUD Full audit preset establishes the current plugin baseline
2. Configuration items: Each plugin is a configurable item with status and trust score
3. Unauthorized software detection: Plugins without usage signals are candidates for removal
4. Documentation: JSON export serves as configuration evidence for assessors

Repeatable audit process for US agencies

The methodology we recommend for US government and contractor sites follows a documented, repeatable pattern:

This methodology has been accepted by three accredited CMMC assessors and two FedRAMP 3PAO firms as sufficient plugin component inventory evidence — provided the JSON export is retained as an evidence artifact.

Tool-agnostic audit principles

Even if you're not using PUD, the methodology stands. A proper WordPress plugin audit for US compliance must:

1. Identify every installed plugin — active and inactive (inactive zombie plugins still count as components)
2. Measure actual usage — not assumptions. Content, cron, options, widgets, autoload
3. Classify with nuance — binary "used/unused" is insufficient for compliance documentation
4. Document the decision — for each plugin, record why it was kept or removed
5. Timestamp every action — assessors want dates, not just states

PUD was designed around these principles. The 7 statuses replace binary classification. The trust score quantifies confidence. The JSON export creates an immutable audit trail.

Step-by-step — agency audit (7 phases)

This section is the central tutorial. Block 2–4 h for a 40–60 plugin site. Don't skip staging.

1Initial inventory (20 min)

1. List active plugins: Plugins → Installed Plugins (export screenshot or host CSV).
2. Note WooCommerce, builder, SEO, cache, backup — critical plugins.
3. Install Plugin Usage Detector by Volade on staging first.
4. Document WordPress version, PHP, active theme in client folder.

2Run Full audit scan (15 min)

1. Tools → Plugin Usage → Full audit preset (🔍).
2. Wait for scan completion — content depth + cron + options + widgets + overlaps.
3. Sort by status: zombie_bloat → likely_unused → uncertain.
4. Export JSON: Export button → /client-audits/[date]-pud.json.

❝Without a Volade account, active scan, 7 statuses, trust score, 3 presets, JSON export work. Free account: extended inactive plugin scan. V+ Premium: history, scheduling, CSV, multisite rollup.

3Analyze overlaps and duplicates (30 min)

PUD flags duplicate categories:

4Classify removal candidates (45 min)

For each likely_unused or zombie_bloat plugin:

1. Read trust breakdown — cron > 0? → reclassify as uncertain.
2. Search slug in content (WP admin search) if in doubt.
3. Check ignore list for client custom.
4. Mark OK staging or KEEP in your spreadsheet.

5Progressive staging deactivation (1–2 h)

Recommended order — never more than 3 plugins at once:

1. Inactive zombie_bloat — delete files (no runtime risk).
2. Active likely_unused — deactivate, test front + checkout + forms.
3. Wait 24–48 h or run cron manually (wp cron event run --due-now).
4. If OK: delete. If KO: reactivate, status → KEEP, note in JSON.

6Post-purge PCC scan (20 min)

1. Install PHP Compatibility Checker if missing.
2. Scan remaining plugins + theme — archive report for next PHP upgrade.
3. Optional: Heartbeat Control Manager WooCommerce preset if admin-ajax still heavy.

7Client deliverable and watch (30 min)

• PDF or email report: removed plugins, kept, overlaps resolved.
• Archived PUD JSON + final plugin count.
• 7-day watch: PHP errors, support tickets, Site Health.
• Bill as maintenance audit flat fee — reproducible deliverable.

"

Audits that go wrong in 90% of cases share one cause: production deletion of an admin_only plugin with webhooks. Trust score was 55 — cron should have alerted. Always staging, always breakdown.

— Volade support team

PUD presets — Full audit, WooCommerce, Security

PUD offers three dynamic presets for the most requested agency workflows.

Full audit preset — "Complete inventory"

For whom: site takeover, due diligence, fleet documentation.

Workflow: export JSON → client spreadsheet → 2-week removal plan.

WooCommerce cleanup preset — "Store stack"

For whom: stores with stacked gateways, cache, and marketing.

Security minimal preset — "One of each"

For whom: sites with 2 firewalls, 3 backups, 2 caches — silent conflicts.

Bonus: agency JSON preset export

Import the JSON preset from this article's resources to align the whole team on the same scan flags.

Security & compliance for US agencies

Plugin audits in US government, healthcare, and defense contractor environments serve a different purpose than commercial site cleanups. The deliverable isn't just a faster site — it's a compliance artifact that demonstrates control effectiveness.

FedRAMP plugin considerations

For agencies operating in FedRAMP-authorized cloud environments, every plugin introduces a potential compliance gap:

• System boundary definition: each plugin extends the WordPress attack surface. Plugins with direct database access, file system write permissions, or external API calls must be evaluated under the FedRAMP system boundary
• Vulnerability scanning: FedRAMP requires continuous monitoring. Zombie plugins that are inactive but still on disk can trigger false positives in vulnerability scanners — wasting the 3PAO's review time
• Contingency planning (CP-10): unnecessary plugins increase the complexity of system recovery. A FedRAMP contingent plan must account for every software component

PUD helps FedRAMP teams by:

• Classifying inactive plugins as zombie_bloat so they can be removed before the next assessment
• Providing JSON export evidence that plugins were evaluated and either retained (with justification) or removed
• Flagging overlap categories (two caches, two security plugins) that may indicate configuration drift

CISA BOD 25-01 — known exploited vulnerabilities

CISA Binding Operational Directive 25-01 requires federal agencies to remediate known exploited vulnerabilities within 72 hours. For WordPress plugin audits, this means:

1. Your plugin inventory must be accurate enough to determine if a CVE applies
2. You must be able to locate every instance of a vulnerable plugin across your fleet
3. You need a rollup view for reporting to CISA

PUD's multisite capabilities and V+ rollup reports address BOD 25-01 requirements. When a plugin CVE is published, agencies running PUD can:

• Identify every site with the vulnerable plugin (active or inactive)
• Check if the plugin has usage signals (if zombie_bloat, removal is straightforward)
• Export a JSON report as evidence of the response

NIST SP 800-53 controls relevant to plugin audits

Beyond CM-8 (component inventory), several other NIST controls intersect with plugin hygiene:

CMMC Level 2 — defense contractor plugin audit

Defense contractors under CMMC Level 2 face specific plugin audit requirements that go beyond standard WordPress maintenance:

Evidence package required for CM.2.061:

• Screenshot or export of installed plugins list (PUD JSON export)
• Documentation of plugin purpose for each installed component (PUD status + trust breakdown)
• Removal records for plugins deemed unnecessary (staging batch history)
• Quarterly review cadence evidence (V+ scheduling)

Common CMMC plugin pitfalls we've seen:

• Inactive staging plugins left in production — flagged as unauthorized software
• Development plugins (WP Debug, query monitor clones) active on production — configuration management finding
• Multiple security plugins conflicting — assessors flag this as incomplete configuration management
• Unused page builder plugins still on disk — component inventory discrepancy

HIPAA — healthcare plugin audit

For healthcare organizations subject to HIPAA, plugin audits protect ePHI (electronic protected health information):

• Access control (§ 164.312(a)(1)): unused plugins with database access are unauthorized access points to ePHI
• Integrity controls (§ 164.312(c)(1)): form plugins that process patient data must be verified as active and necessary
• Transmission security (§ 164.312(e)(1)): SMTP plugins handling ePHI must be documented and secured

PUD's admin_only status is particularly valuable for HIPAA audits — CRM and patient communication plugins often show no front-end usage but are critical for ePHI workflows. The cron signal reveals whether a plugin is actively processing data even when it has no visible shortcodes.

Building an SBOM from your plugin audit

The US Executive Order on Cybersecurity (EO 14028) and subsequent NTIA guidance have made Software Bill of Materials (SBOM) a requirement for federal software suppliers. While WordPress itself isn't typically a delivered software product, agencies maintaining WordPress sites can use plugin audits to build a lightweight SBOM:

For agencies that need to produce an SBOM for their WordPress instances, PUD's JSON export provides the component inventory layer. Combine it with PHP Compatibility Checker for dependency depth.

US agency compliance — recommended scan frequency

Your options in 2026

Every site doesn't need the same tool. Here are honest approaches.

Option 1 — Manual audit (Excel + DB + grep)

For whom: senior team, very small fleet, direct SQL access.

Option 2 — WP Usage Analyzer

For whom: simple sites, basic "used / not used" need.

Option 3 — Unplug / Orpharion

For whom: focus on quick deactivation of unused plugins.

Option 4 — Query Monitor

For whom: runtime debug — requests, hooks, per-page perf.

Option 5 — Plugin Usage Detector by Volade (recommended for agencies)

For whom: agencies, fleet takeover, client JSON deliverable — 7 statuses + trust score + presets.

We built Plugin Usage Detector because agencies deserve an honest audit — not a simplistic red/green box that breaks webhooks on a Friday night.

Which tool for which US agency scenario?

Not every organization needs the same tool. Here's a quick decision matrix for US agency contexts:

Tool cost analysis for US agencies

When budgeting for plugin audit tools, consider the full cost of ownership:

For US agencies billing $300–800 per audit to clients, the tool cost is negligible — the labor savings from PUD's automated classification vs manual Excel/SQL is the real ROI.

Full comparison table

Common mistakes and how to avoid them

Even with a good preset, these problems return in most plugin audits.

"I deleted a plugin and checkout died"

Why: admin_only or uncertain gateway removed without order test.

How to avoid:

• Test checkout after each staging batch
• Read cron_detail in PUD breakdown
• Keep a documented fallback gateway

"PUD says likely unused but the shortcode is in a theme template"

Why: content outside scanned posts/pages (Elementor library, CPT).

How to avoid:

• Global WP search + theme files if in doubt
• pud_scan_post_types filter for custom CPTs
• Manual KEEP status in ignore list

"Two SEO — I deleted the wrong one"

Why: overlap flagged but redirects not exported.

How to avoid:

• Export 301 rules before deactivation
• Test 5 key URLs after SEO switch
• Security minimal preset + client validation

"DB autoload still heavy after purge"

Why: inactive zombie_bloat plugins not deleted — orphan options.

How to avoid:

• Delete inactive zombie plugin files
• Clean orphan options (host tool or careful WP-CLI)
• Rescan PUD to measure gain

"Client reinstalled 10 'free' plugins the next week"

Why: no plugin governance policy.

How to avoid:

• Audit deliverable + charter: agency validation before install
• Quarterly scheduled PUD review (V+)
• Bill fleet governance as recurring

Performance impact — real data from US sites

How much difference does a plugin audit actually make? We analyzed performance data from 120 US-based WordPress sites before and after PUD audits conducted between January and June 2026. The results are based on real agency scans, not synthetic benchmarks.

Autoload reduction

The most immediate and measurable impact of removing zombie plugins is autoload size in the wp_options table. Autoloaded options are loaded on every WordPress page load, whether the plugin is active or not — if the files are still on disk and the options table still has entries.

Real result: A US federal contractor site with 48 plugins had 4.2 MB of autoload before audit. After removing 14 zombie_bloat plugins (all inactive but still on disk), autoload dropped to 1.8 MB — a 57% reduction. The site's TTFB (Time to First Byte) dropped from 1.4s to 0.6s on Pantheon hosting.

Page speed impact (Core Web Vitals)

Plugin bloat affects Core Web Vitals differently depending on where the plugin loads:

Case example: A US university's WordPress multisite (3 networks, 12 sites) had 6 identical plugins installed across all sites — 3 of which were inactive on every site. Removing the inactive plugin files across the network freed 2.7 MB of autoload network-wide. The median LCP across all sites dropped from 3.2s to 2.1s — crossing the "good" threshold for the first time.

Database bloat from orphaned options

One of the most overlooked performance impacts is the wp_options table size. When plugins are deactivated but not removed, their options entries remain:

Hosting cost connection

Fewer plugins means lower hosting costs — especially on tiered hosting plans common with US providers:

• Pantheon, WP Engine, Flywheel: plugin count limits on entry plans (typically 30–40 plugins). Exceeding the limit triggers warnings or forced plan upgrades ($50–200/month extra)
• AWS / cloud VMs: lower autoload = smaller PHP memory footprint = potential for smaller instance type. A 1.5 MB autoload reduction can save $30–80/month on EC2
• Managed WordPress (Nexcess, Pressable): plugin count is a pricing factor for high-tier plans

Cost per plugin calculation

For US agencies building a business case for plugin audits, use this formula:

Annual cost per plugin = (hosting cost + maintenance time + security monitoring) / total plugins

Example:

• Hosting: $200/month ($2,400/year)
• Maintenance: 4 hours/month at $150/h = $7,200/year
• Security monitoring (WAF, scanning): $1,200/year
• Total: $10,800/year for 40 plugins = $270/year per plugin

Removing 10 zombie plugins = $2,700/year savings — without any performance or security benefits factored in.

Performance measurement methodology

The data above was collected using a standardized measurement approach across all 120 sites:

1. Baseline measurement: autoload size (query SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'), LCP (Chrome UX Report), TTFB (server response time header)
2. Post-audit measurement: same metrics measured 7 days after final staging batch was promoted to production
3. Control for variables: no other major changes (theme updates, hosting migrations) within the 7-day window
4. Plugin count: active plugins per Plugins screen + inactive plugins still on disk (files + options table entries)

Limitations: these are observational data, not controlled experiments. Individual results vary based on hosting infrastructure, theme complexity, and server configuration. The 120-site sample skews toward US-based hosting (Pantheon, WP Engine, AWS) and may not generalize to shared hosting environments.

Autoload breakdown by plugin category

Understanding which plugin categories contribute most to autoload bloat helps prioritize audit targets:

For US agency sites in the study, page builders + form builders + security scanners consistently accounted for 60%+ of total autoload — and were also the categories with the highest proportion of zombie_bloat or likely_unused plugins.

Real US case studies

These anonymized case studies come from actual PUD deployments in US agency and commercial environments. Names and identifying details have been removed.

Case study 1 — Federal contractor preparing for CMMC Level 2

Background: A DC-area defense contractor managing 12 WordPress sites for sub-contractors needed to pass a CMMC Level 2 assessment. Plugin inventory was a required evidence artifact under CM.2.061 and CM.2.062.

Initial state:

• 12 sites, average 38 plugins per site
• No centralized plugin documentation
• 3 sites had development plugins active (debug bar, query monitor)
• Multiple SEO and cache plugins across the fleet — no standard

PUD audit process:

1. Full audit preset on all 12 sites (2 hours per site = 24 hours total, but ran in parallel)
2. JSON exports consolidated into a fleet-wide spreadsheet
3. Overlap analysis revealed 47 plugins categorized as zombie_bloat across the fleet
4. Staging removal in batches of 3 per site over 6 weeks

Results:

• 47 zombie plugins removed fleet-wide
• Average autoload reduction: 1.6 MB per site
• Development plugins removed from production (CM.2.062 compliance)
• JSON exports submitted as evidence — accepted by CMMC assessor without follow-up questions
• Fleet-wide page load improvement: 28% average

Key lesson: The assessor valued the trust score breakdown more than the status labels. The fact that each plugin had a documented confidence score — with cron, content, and options signals individually listed — satisfied the CMMC requirement for "documented basis of configuration decisions."

---

Case study 2 — State government agency (.gov migration)

Background: A state environmental agency migrating from a legacy .NET CMS to WordPress. The migration consultant inherited a staging WordPress instance with 63 plugins — a mix of evaluation plugins, developer tools, and production-intended extensions.

Initial state:

• 63 plugins, 28 never activated (installed for evaluation, then abandoned)
• 12 plugins active but with zero content signals
• 4 caching plugins active simultaneously (page cache, object cache, CDN plugin, browser cache)
• Agency security team required a plugin whitelist before go-live

PUD audit process:

1. Full audit preset on staging instance
2. Overlap detection flagged the 4-cache conflict (preset: Security minimal)
3. Trust score analysis revealed 6 plugins with cron activity despite no content usage
4. Two-week staged removal following the 7-phase workflow

Results:

• 63 → 31 plugins (51% reduction)
• Caching stack consolidated to 2 plugins (page cache + object cache) — site speed improved 35%
• Security whitelist approved in 1 review cycle vs typical 3–4 cycles
• $12,000/year saved on hosting (moved from higher-tier plan to standard)

Key lesson: The security team was initially skeptical of WordPress plugin security. The PUD JSON export gave them a per-plugin risk assessment — trust score, status, and usage signals — that they could map to their existing risk acceptance framework.

---

Case study 3 — Healthcare provider HIPAA audit remediation

Background: A Texas-based healthcare network with 8 WordPress sites was cited during a HIPAA security evaluation for "insufficient software asset management." Their plugin inventory was a manually maintained Google Sheet with 6-month-old data.

Initial state:

• 8 sites, average 44 plugins per site
• No automated plugin tracking
• 3 sites had wp-config.php debugging enabled from a development phase
• 4 form plugins on one site (2 processing patient intake data, 2 abandoned)
• WordPress admin accounts still using default credentials on a dev plugin (ticket system)

PUD audit process:

1. Full audit preset on 8 sites
2. Focus on admin_only and uncertain plugins — healthcare sites often have CRM/scheduling plugins with no front-end visibility
3. Cross-referenced PUD results with HIPAA access control requirements

Results:

• 11 plugins removed across the fleet (all zombie_bloat or likely_unused)
• 4 form plugins reduced to 2 — both verified as processing patient data
• Debug plugin removed from production (direct HIPAA violation if discovered by auditor)
• PUD JSON export added to annual HIPAA evidence package
• Cost savings: $450/month on security scanning (reduced scope after removing plugins with known CVEs)

Key lesson: The admin_only status was critical for healthcare. A patient portal plugin had zero front-end shortcodes but was actively routing appointment data via cron. Without the cron signal in PUD, the agency would have marked it as unused and removed it — breaking patient scheduling.

---

Case study 4 — US e-commerce brand acquisition

Background: A private equity firm acquired a US D2C brand with a WooCommerce store running on WordPress. The due diligence phase included a technical audit of the site's plugin footprint.

Initial state:

• 67 plugins on a single WooCommerce site
• 8 payment gateways (only 2 in use: Stripe + PayPal)
• 5 marketing automation plugins (3 abandoned after previous agency contract ended)
• 3 CRM plugins (Salesforce, HubSpot, Zoho — only Salesforce still active)
• $850/month hosting on a premium WooCommerce plan

PUD audit process:

1. WooCommerce cleanup preset (focused on payment, cache, marketing overlaps)
2. Overlap analysis identified the 8-gateway and 3-CRM redundancies
3. Trust score breakdown confirmed 5 marketing plugins had zero cron activity — truly abandoned
4. Staged removal over 4 weeks with checkout testing after each batch

Results:

• 67 → 41 plugins (39% reduction)
• 6 payment gateways removed (kept Stripe + PayPal)
• 2 CRMs removed (kept Salesforce — active sync confirmed via cron signal)
• Autoload reduced from 5.8 MB to 2.9 MB
• Hosting plan downgraded from Premium ($850/mo) to Business ($350/mo) — $6,000/year saved
• Checkout conversion improved 4.2% (fewer plugin conflicts in checkout flow)

Key lesson: The cron signal in PUD's trust breakdown was the deciding factor for the CRM decision. Salesforce showed active cron hooks (order sync, inventory updates). HubSpot and Zoho showed zero cron activity — confirmed as abandoned despite being "active" in the plugins list.

---

Case study 5 — US media publisher security incident response

Background: A digital media publisher with a distributed WordPress architecture (14 sites across 3 data centers) suffered a security incident traced to an abandoned plugin with a known CVE.

Initial state:

• 14 sites, average 55 plugins per site
• No centralized plugin management
• Post-incident forensic analysis: an abandoned newsletter plugin (not updated in 3 years) was the vector
• The plugin was active on 8 of 14 sites despite being replaced by a newer tool 18 months prior

PUD audit process:

1. Emergency Full audit scan on all 14 sites within 48 hours
2. PUD identified the compromised plugin class on 8 sites — also flagged 3 additional plugins with no usage signals and known CVEs
3. Trust score for the compromised plugin: 12 (zombie_bloat — inactive but on disk, with residual autoload)
4. Staging removal prioritized by CVE severity

Results:

• Compromised plugin removed from all 8 sites within 24 hours
• 17 additional zombie plugins removed fleet-wide
• Implemented quarterly PUD scans as a preventive control
• Insurance requirement: publisher's cyber insurance now requires semi-annual plugin audit as a policy condition
• Average plugin count reduced from 55 to 39 across the fleet

Key lesson: The incident triggered a complete revision of the publisher's plugin governance policy. PUD's overlap detection became the standard onboarding check for any new plugin — if a new plugin overlaps with an existing category, it requires documented justification and a removal date for the replaced plugin.

---

Your action plan this week

Use this checklist as an execution layer — print it, share internally.

WordPress plugin audit checklist

• Active/inactive plugin inventory documented
• Full backup + mirror staging
• Plugin Usage Detector installed on staging
• Full audit preset scan + JSON export
• SEO/cache/backup overlaps analyzed
• Removal candidates validated (trust breakdown read)
• Staging batch deactivation (max 3 at a time)
• Front + checkout + forms tests after each batch
• PHP Compatibility Checker post-purge scan
• Heartbeat Control Manager if admin-ajax heavy (optional)
• Client deliverable: JSON + removed/kept plugin list
• 7-day watch — PHP logs, Site Health
• Plugin governance charter proposed to client

US compliance checklist additions

For US agency, federal contractor, and regulated environments, add these items:

• Map PUD JSON export to NIST 800-53 CM-8 or CMMC CM.2.061 control evidence
• Check for development/staging plugins active in production (debug tools, test plugins)
• Document plugin retention rationale in compliance folder (trust score + status for each)
• Export SBOM from PUD scan if federal software supplier
• Verify no known CVE plugins remain active (zombie_bloat with recent CVE = remove immediately)
• Save JSON export in compliance evidence repository with timestamp
• Schedule quarterly rescan (V+ or calendar reminder)
• Include plugin audit in annual HIPAA security evaluation (if healthcare)
• Verify FedRAMP system boundary — no plugin outside authorized scope
• Update cyber insurance documentation with post-audit plugin count

Recommended tools

• Plugin Usage Detector by Volade
• PHP Compatibility Checker by Volade
• Heartbeat Control Manager by Volade
• Query Monitor — runtime debug complement
• Volade V+ pricing — scan history, CSV, multisite rollup

Resources & PDF guide

Download public checklists from this article's resource panel. Members unlock the 14-page complete guide with decision matrices, annotated JSON preset, and unused plugin decision tree.

The premium guide includes:

• US compliance mapping matrix: NIST/CMMC/FedRAMP/HIPAA control references for each plugin status
• Pre-formatted POA&M input: template for assessor evidence submission
• SBOM template: generate a Software Bill of Materials from your PUD export
• Quarterly audit schedule: calendar template with pre-defined scan cadences

FAQ — questions we get most

Does PUD delete plugins automatically?

No. PUD classifies and flags — you decide, staging first. Deliberate for agencies billing traceable audits.

Does trust score guarantee a plugin is unused?

No. It's a confidence indicator based on observable signals. An uncertain plugin with active cron may be critical — read the breakdown.

How does PUD compare to Query Monitor?

Complementary. Query Monitor = live request debug page by page. PUD = fleet audit cron/options/content/overlaps. Use both: PUD for purge plan, QM to investigate a slow page post-purge.

PUD vs WP Usage Analyzer?

WP Usage Analyzer focuses mostly on shortcodes. PUD adds cron, autoload options, widgets, overlaps, 7 statuses, trust score — suited for 30+ plugin agency fleets.

Should I run PCC before or after PUD?

Both make sense. PUD first to remove dead weight, then PCC on remaining stack before PHP upgrade. If urgent PHP upgrade: PCC first, PUD after.

Does Plugin Usage Detector require a Volade account?

No. Active scan, 7 statuses, trust score, 3 presets, JSON export, WP-CLI work without an account. Free account: extended inactive scan. V+: history, scheduling, CSV, multisite rollup.

Can I audit multisite?

Yes. Per-site scan; V+ for network rollup and centralized reports. Network-aware infrastructure.

For agencies — billing?

Document a 48 h runbook per client (checklist + JSON + audit email). Bill as WordPress maintenance — $300–800 depending on fleet size. V+ Pro (5 sites) or V+ Agency (unlimited) for history and scheduling across the Volade catalog.

Can PUD export be submitted to FedRAMP or CMMC assessors?

Yes — with caveats. PUD's JSON export has been accepted by CMMC assessors as evidence for CM.2.061 (baseline configuration) and CM.2.062 (unauthorized software). For FedRAMP, the export supports CM-8 (component inventory). However, PUD is not a certified compliance tool — it produces evidence that your assessor may accept as part of a broader evidence package. We recommend checking with your 3PAO before relying solely on PUD for compliance evidence.

Does PUD detect plugins with known CVEs?

Indirectly. PUD classifies plugin status and trust score but does not scan against the NVD (National Vulnerability Database). Combine PUD with a vulnerability scanner (e.g., WPScan, Wordfence) for complete CVE coverage. PUD's value is in identifying which plugins to scan — removing zombie plugins reduces the vulnerability scanner's scope.

How does PUD handle HIPAA compliance?

PUD helps with HIPAA's software inventory requirements (§ 164.312) by documenting every installed plugin, its usage status, and its trust score. For healthcare agencies, the admin_only status is especially important — plugins managing ePHI (patient portals, form builders, CRM) often show zero front-end usage but are critical for compliance. PUD's cron signal reveals whether a plugin is actively processing data. PUD does not handle HIPAA BAAs, encryption, or audit logging — it's one layer of a broader HIPAA compliance program.

What's the difference between a US compliance plugin audit and a standard maintenance audit?

Conclusion — audit before you delete

Plugins accumulate because WordPress makes installation easy — not governance. When a client asks to "clean up," you're not condemned to Excel or production roulette.

It's not inevitable. Multi-signal scan, trust score, staging batches, overlaps, JSON deliverable — and you regain control of the fleet without breaking webhooks on a Friday night.

For US agencies, federal contractors, and regulated organizations, the stakes are higher. A plugin audit isn't just about site speed — it's about compliance evidence, CVE remediation, and configuration management. A zombie_bloat plugin isn't just dead weight — it's an unauthorized software finding in a CMMC assessment, an ePHI exposure risk under HIPAA, and a false positive generator in FedRAMP vulnerability scanning.

Our final recommendation: this week, run a Full audit preset on a pilot staging site, export JSON, identify 3 risk-free inactive zombie_bloat plugins, and share the overlap comparison with the client. If you're in a US regulated environment, also map the results to your compliance framework — NIST control numbers, CMMC practices, or HIPAA safeguards.

Go slowly. Staging first. Document. Your assessor will thank you.

If you choose Volade: welcome. We built this tool because agencies deserve an honest, maintained audit with guardrails that federal contractors, healthcare providers, and WooCommerce stores can all use — without a terminal.

Happy maintenance. Your plugin fleet — and your compliance posture — will thank you.

---

Article updated July 13, 2026. Sources: Volade field tests across 120+ US sites, WP Usage Analyzer / Query Monitor / Unplug comparison, PUD 1.0 documentation, NIST SP 800-53 Rev. 5, CMMC 2.0 Level 2, FedRAMP Rev. 5 baseline, HIPAA Security Rule, CISA BOD 25-01.