Book a demo
Book a demo
Login

App workflow WordPress

Enable WordPress vulnerability scanning

Confirm the scope and settings, then verify which sites are included. 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 discovers that one client WordPress site has never been included in its weekly vulnerability review. The goal is to establish scanning and ownership, not to promise that the site is 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

Select the site and owner

Where
Agency xCloud team and client inventory
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Client team ID, site ID, reviewer
Action
Confirm the exact production WordPress site and assign one person to receive and triage findings.
Expected result
An unambiguous scan target and accountable reviewer.
Verify
Compare domain and WordPress version with the agency inventory.
If it fails
If the site is outside the agency's granted team, request the proper access rather than using another client account.

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

Step 2 of 5

Open scanner controls

Where
xCloud WordPress → Vulnerability Scan
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Plan state and current scan status
Action
Inspect whether the vulnerability view is active, which components it covers, and whether a scan is pending or last completed.
Expected result
A documented current scanner state.
Verify
Record last scan timestamp and covered plugin/theme/core versions.
If it fails
If controls are unavailable, check plan and site eligibility before claiming coverage.

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

Step 3 of 5

Enable or request scan

Where
xCloud vulnerability panel or discovered MCP rescan
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Approved site and scan permission
Action
Enable the available scanner in the dashboard, or request an authorized rescan through a discovered supported tool. Treat triggering a scan as a write.
Expected result
A scan run tied to the selected site.
Verify
Wait for terminal status; do not count a queued scan as a result.
If it fails
If a scan fails, keep the coverage gap open and investigate tool/status errors.

Sources: Vulnerability Checker in xCloud · Vulnerability operations

Step 4 of 5

Triage first result

Where
Finding list and WordPress component inventory
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Affected slugs, versions and advisories
Action
Match each finding to installed versions and active features. Assign update, removal, mitigation or research, with a due date.
Expected result
A prioritized finding register.
Verify
Cross-check critical plugins against WordPress Plugins and vendor advisories.
If it fails
If a finding lacks context, label it unresolved rather than dismissing it.

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

Step 5 of 5

Set ongoing review

Where
Agency maintenance calendar and client report
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Weekly reviewer, escalation contact, evidence store
Action
Create a real calendar or ticket reminder for weekly review and after major updates. Put scan date, open findings and owner in the client report.
Expected result
A repeatable review rather than a one-time scan.
Verify
Have the reviewer perform the next check and log the result.
If it fails
If the assigned reviewer leaves, transfer ownership and verify access before the next scan.

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