Book a demo
Book a demo
Login

Operations WordPress

Track WordPress changes across a client portfolio

Use available history/reporting evidence and keep a human-readable change record. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

An agency supports many WordPress sites and cannot explain which plugin update preceded a client complaint. It needs a site-specific change ledger across the portfolio.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Fix inventory scope

Where
Agency client roster and xCloud teams
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Client, domain, site ID, owner
Action
Map every client site to its xCloud team and named maintenance owner. Include staging as a separate environment.
Expected result
A complete portfolio key.
Verify
Spot-check domains and IDs with client records.
If it fails
If a site has no owner, flag it before changes occur.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Create a staging environment in xCloud · xCloud team roles and permissions

Step 2 of 5

Collect changes

Where
xCloud update history, backup rows, incident tickets
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Date range, actors, component versions
Action
Read completed WordPress updates and other site operations for each site. Record before/after version, operator and related backup ID.
Expected result
A chronological ledger.
Verify
Compare one recorded version with current WordPress admin.
If it fails
If history is absent, mark the gap and seek deploy/app records.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Manage WordPress updates with Updates Manager · Site backups in xCloud

Step 3 of 5

Attach business validation

Where
Client task checklists
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Form, checkout, booking, login results
Action
For every material change, link the actual post-change test and any defect or rollback decision to that site's row.
Expected result
A ledger that explains impact.
Verify
Inspect evidence for a representative high-risk change.
If it fails
If a test was skipped, record it as an exception instead of fabricating a pass.

Sources: Manage WordPress plugins

Step 4 of 5

Separate client visibility

Where
Agency report workspace
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Client permissions and report recipients
Action
Produce client-specific extracts and restrict cross-client data. Keep internal incident notes separate from a sanitized client report.
Expected result
Correct audience for each change summary.
Verify
Have a reviewer check exported rows and recipients.
If it fails
If client data appears in another extract, stop distribution and correct permissions.

Sources: WordPress website maintenance reports for clients · xCloud agent capability boundaries

Step 5 of 5

Set update workflow

Where
Agency runbook and calendar
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Next review date, ticket template
Action
Require future change tickets to include site ID, selected slugs, backup, test result and owner, then audit compliance monthly.
Expected result
A repeatable tracking process.
Verify
Check next completed change against required fields.
If it fails
If a change lacks evidence, reopen it for follow-up.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Manage WordPress updates with Updates Manager · Site backups in xCloud

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

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 and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases