Book a demo
Book a demo
Login

Operations WordPress

Prepare a WordPress security review report

Separate scan findings, protection status, updates, and items requiring manual investigation. 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

A client asks for a WordPress security review after a plugin advisory. The agency must report observed controls, open issues and evidence limits without claiming the site is completely safe.

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 report scope

Where
Client request and xCloud inventory
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Site ID, domain, reporting date, recipients
Action
Confirm exact WordPress site and period, who commissioned the report and whether incident investigation is in scope.
Expected result
A bounded review statement.
Verify
Compare domain and team with client record.
If it fails
If compromise is suspected, route to incident response rather than routine report.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 2 of 5

Gather software evidence

Where
WordPress and xCloud Updates Manager
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Core/plugin/theme versions, update history
Action
List installed critical components and pending updates. Note unsupported or abandoned plugins and their owners.
Expected result
A dated software posture section.
Verify
Spot-check versions against WordPress admin.
If it fails
If versions differ across systems, disclose discrepancy and investigate.

Sources: Manage WordPress plugins

Step 3 of 5

Gather control evidence

Where
xCloud Vulnerability Scan, Site Backup, users
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Finding IDs, scan time, completed backup, admins
Action
Record findings and remediation status, last completed files/database backup, and administrator access review status.
Expected result
A control table tied to source timestamps.
Verify
Check every claimed completed backup and resolved finding.
If it fails
If a control cannot be observed, state unverified rather than passing it.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Site backups in xCloud

Step 4 of 5

Write risk decisions

Where
Agency report draft
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Open finding, business exposure, mitigation owner
Action
For each open issue, state affected version, evidence, chosen response, owner and due date. Separate vendor advisory from observed site behavior.
Expected result
Actionable risk narrative.
Verify
Have security and site owners review wording.
If it fails
If evidence suggests active compromise, stop routine publication and escalate privately.

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

Step 5 of 5

Share and follow up

Where
Approved client channel and ticket queue
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Reviewed report, recipient, next scan date
Action
Send only to approved contact and create follow-up tasks for unresolved items. Preserve a dated copy with source references.
Expected result
A review the client can act on.
Verify
Confirm recipient and owner for each exception.
If it fails
If report contains secrets or wrong-client data, correct distribution before sending.

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

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