# Review WordPress plugin updates site by site

Rank plugin updates across client sites by affected version, business dependency, backup readiness and owner, then hand off separate approved changes.

Canonical: https://xcloud.host/use-cases/solutions/review-wordpress-plugin-updates-site-by-site/
Published: 2026-09-30 · Updated: 2026-09-30 · Technical review: 2026-09-30
Evidence: Source reviewed; no production deployment test claimed
Editorial owner: xCloud editorial

Intent: Review and prioritize WordPress plugin updates across an agency portfolio without applying them.
For: agency, site-operator

## Requirements and responsibilities

- Obtain named read access to each client team and exact production site, and record who can approve changes for that client. An agency-wide empty or partial MCP result is not proof that a client has no WordPress site. Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- Use installed plugin versions, enabled state, vendor release notes and xCloud vulnerability findings as distinct evidence. A scanner finding shows affected software, not proven compromise or completed remediation. Sources: [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/); [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/)
- This is a review-only procedure. Do not update a plugin, create staging, change policy, rescan, restore or alter any production setting. Later operations need exact site, version, backup, test and client approval. Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

## Illustrative situation

Illustrative scenario: an agency maintains several client WordPress sites. One runs checkout, another captures leads, and a third publishes articles. The same plugin update does not have the same business impact on all three, so the agency needs a site-specific decision queue before any production change.

## Choose the approach

- Rank per site and plugin, not by a global version count. Consider exposure, whether the plugin is active, compatible target release, commerce/form dependency, client change window and verified backup point. Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/); [Manage WordPress core, themes and plugins](https://xcloud.host/docs/manage-and-update-wordpress-core-themes-in-xcloud/)
- Distinguish routine updates from emergency triage. If an affected component has no safe fixed version, propose a separately approved mitigation or vendor decision rather than treating a dashboard update badge as a repair. Sources: [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/)

## Dashboard and application procedure

### 1. Select the client-site portfolio

**Where:** xCloud team and site resource views

**Permissions:** Named agency reviewer has permitted read access; client owns change decisions.

**Inputs:** Client register, exact domains, site UUIDs, team IDs, critical business journey and maintenance window.

**Action:** List each intended client team and production WordPress site, then compare the returned site identity with the agency register. Record whether the site takes orders, leads or only editorial content and who can approve a change for that client.

**Expected result:** The review covers a finite, named site set with an approver and business path for each.

**Verify:** Check one hostname and team ID per client against the register; mark inaccessible sites as unknown rather than up to date.

**If it fails:** If a team grant is missing or a staging site is mistaken for production, stop that row and ask the authorized client owner to clarify access.

Capability: Confirm requirements and inspect resources
Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

### 2. Capture plugin and finding evidence

**Where:** xCloud WordPress update and vulnerability views; WordPress plugin list

**Permissions:** Reviewer reads; WordPress administrator supplies any version not visible to MCP.

**Inputs:** Per-site installed and proposed plugin versions, active status, finding identifier, scan time and update history.

**Action:** For each site record the exact plugin slug, installed version, active state, available version and last update history. Read xCloud vulnerability findings separately and attach finding IDs and observation time; do not infer a plugin is fixed merely because an update is offered.

**Expected result:** The queue separates actual installed state, available update and vulnerability evidence for every reviewed site.

**Verify:** Compare at least one plugin row with the WordPress administrator and note mismatches, missing rows and stale scan timestamps.

**If it fails:** If version or scan freshness is uncertain, label that row blocked for research instead of assigning a misleading priority.

Capability: Inspect WordPress vulnerability findings
Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/)

### 3. Assess compatibility and client impact

**Where:** Vendor release notes and client application evidence

**Permissions:** Named reviewer, vendor-documentation reader and client business owner.

**Inputs:** Vendor changelog, required PHP/WordPress versions, payment/form integrations and client acceptance path.

**Action:** Read the selected vendor’s fixed or target release notes and check stated WordPress/PHP compatibility. For each site, identify whether the plugin touches checkout, forms, membership, content or a noncritical feature; ask the client owner which path would prove it still works.

**Expected result:** Each proposed update has a documented target and a client-specific reason for its urgency and test scope.

**Verify:** Write an affected URL or transaction and expected result beside each version pair; mark unsupported compatibility as unknown.

**If it fails:** If the vendor does not document compatibility or a required extension lags, keep production change pending and propose a safe test first.

Capability: Review a WordPress business journey
Sources: [Manage WordPress core, themes and plugins](https://xcloud.host/docs/manage-and-update-wordpress-core-themes-in-xcloud/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/)

### 4. Check backup and staging eligibility

**Where:** xCloud Site Backup and staging overview

**Permissions:** Reviewer inspects status; dashboard owner later performs any backup or staging write.

**Inputs:** Last completed files/database point, retention/destination, restore owner, staging eligibility and live-data sensitivity.

**Action:** For each site inspect the latest completed backup and its files/database scope, then note whether eligible staging and a safe test account exist. A configured schedule or remote-storage label is not proof of a restorable point; record any site with live orders or leads that a restore could overwrite.

**Expected result:** The update queue shows which sites are ready to test and which lack a recovery or staging prerequisite.

**Verify:** Record backup identifier and timestamp with site ID, and compare it with the latest order, lead or post supplied by the application owner.

**If it fails:** If backup or test eligibility is missing, mark the update blocked and request a separate authorized dashboard task before scheduling it.

Capability: Confirm requirements and inspect resources
Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

### 5. Order changes and write tests

**Where:** Agency per-site decision ledger

**Permissions:** Agency maintainer proposes; client owner accepts priority and window.

**Inputs:** Evidence rows, severity context, target versions, dependencies, business paths, backup status and client windows.

**Action:** Rank the individual site/plugin rows by affected version, exposure and business impact, then group only compatible changes for a maintenance window. For each row write a specific staging test, expected application/provider record and rollback decision that preserves post-backup data.

**Expected result:** The owner has a prioritized per-site change sheet, not an undifferentiated update-all instruction.

**Verify:** Ask a second maintainer to explain why the top row precedes the next and identify each unresolved dependency and test owner.

**If it fails:** If priorities rest only on a badge or severity label, recheck plugin use and vendor evidence before recommending an order.

Capability: Business owner review and acceptance
Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/); [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/)

### 6. Request separate per-site approval

**Where:** Client approval sheet and selected future procedure

**Permissions:** Client owner authorizes any later update; this review does not perform it.

**Inputs:** Exact site, plugin slug, current/target versions, backup point, planned window, tester and unresolved risks.

**Action:** Send each client owner a separate proposed update sheet and acceptance criteria, including any blocked row and required backup or staging work. Hand approved rows to the site-specific WordPress update procedure; record that no plugin was changed by this review.

**Expected result:** Each client can approve or defer an exact update without mistaking the review for completed maintenance.

**Verify:** Verify the owner can name the chosen site, target version, test path and rollback authority; retain the decision timestamp.

**If it fails:** If approval is absent or a critical test owner is unavailable, leave the row pending and keep its finding visible in the next review.

Capability: Business owner review and acceptance
Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

## Maintenance

- Refresh the portfolio ledger when an installed version changes, a vendor releases a fix, a vulnerability scan changes or a client business path changes. Keep completed updates, deferred decisions and failed tests distinct. Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/)
- After a separate authorized change, attach the actual site-specific update history and business-test evidence to the row. A review recommendation by itself must never be marked as remediation. Sources: [Manage WordPress core, themes and plugins](https://xcloud.host/docs/manage-and-update-wordpress-core-themes-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

## Recovery decisions

- This review changes no production state. If evidence is wrong, correct or supersede the affected site row and notify its named approval owner; do not restore a database to repair a planning document. Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- For a later failed update, preserve the site’s current orders, leads or posts and compare them with the approved backup point before any dashboard restore. Route recovery to that client’s authorized operator. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

## AI handoff

Connect xCloud MCP for the named team and discover the granted tools, schemas and scopes. Use resource reads to confirm site identity and returned dashboard URLs. The packaged REST fallback is GET-only; staging, backup schedules, restores and cache settings require the dashboard, while WooCommerce, booking and WordPress content settings belong to their named application owners.

### Supported scope

- **Confirm requirements and inspect resources** (mcp; read): Discover the connected profile and operation schema first; only teams granted to the connection are visible. Checkpoint: Confirm exact team, server and site identity. Use dashboard\_url returned by the resource; do not invent a dashboard link. Operation identifiers to discover: teams.index, servers.show, sites.show. Scopes: read:servers, read:sites. Sources: [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- **Inspect WordPress vulnerability findings** (mcp; read): Discover the connected read schema first. Version-based findings are not proof of compromise or a complete safety assessment; rescan is a separate write. Checkpoint: Record site, component, installed version, finding and observation time. Scopes: read:sites. Sources: [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- **Review a WordPress business journey** (app; manual): Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence. Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision. Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/)
- **Business owner review and acceptance** (app; manual): Human planning, acceptance and record reconciliation cannot be inferred from xCloud resource reads. The business owner chooses the application's source of truth. Checkpoint: Record approved criteria, observed application evidence, unresolved questions and named follow-up. Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

### Copyable agent brief

```text
Review plugin updates for the exact client teams and production WordPress sites I name. Use only granted xCloud reads to list site identity, installed version and available update, vulnerability finding, update history and completed backup state. Ask me for vendor release notes and business-path evidence you cannot observe. Rank site/plugin rows with reasons, compatibility uncertainty, staging test and owner; return separate approvable change sheets. Do not update plugins, create staging, rescan, restore or alter policy. A badge is not a completed fix and the packaged REST wrapper is GET-only.
```

### Manual checkpoints

- The agency reviewer obtains vendor release notes and client business-path evidence outside connected hosting reads.
- Client owners approve exact site/plugin targets, test accounts, maintenance windows and data-recovery decisions.
- A later authorized dashboard/WordPress operator performs updates and tests; this review makes no changes.

## Feature coverage

- **portfolio-inventory** (covered): Names exact client teams, production sites, owners and critical paths. Steps: portfolio
- **per-site-version-evidence** (covered): Separates installed versions, vendor targets and vulnerability findings. Steps: queue, dependencies
- **change-readiness** (covered): Checks completed backup, staging and newer business records without writing. Steps: readiness
- **priority-and-approval** (covered): Produces a site-specific test order and separate client approvals. Steps: rank, handoff

## Sources

- [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/) — reviewed 2026-09-30
- [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) — reviewed 2026-09-30; v4.4.2 package; xCloud v2.8.8 capability review
- [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/) — reviewed 2026-09-30
- [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) — reviewed 2026-09-30
- [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/) — reviewed 2026-09-30
- [Manage WordPress core, themes and plugins](https://xcloud.host/docs/manage-and-update-wordpress-core-themes-in-xcloud/) — reviewed 2026-09-30
- [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/) — reviewed 2026-09-30
- [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/) — reviewed 2026-09-30
- [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) — reviewed 2026-09-30
- [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/) — reviewed 2026-09-30

## Continue

[Open the selected plugin update procedure](https://xcloud.host/use-cases/operations/wordpress-plugin-updates-and-security/)

- [Manage WordPress plugin updates and security checks](https://xcloud.host/use-cases/operations/wordpress-plugin-updates-and-security/)
- [Triage a WordPress vulnerability finding](https://xcloud.host/use-cases/solutions/triage-a-wordpress-vulnerability-finding/)
- [Operate an agency WordPress portfolio](https://xcloud.host/use-cases/playbooks/operate-an-agency-wordpress-portfolio/)