Book a demo
Book a demo
Login

Solution WordPress

Prepare a repeatable WordPress client onboarding

Gather domain, site, access, backup, and ownership details before setup begins. The agency can log in with named access and run agreed acceptance checks.

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

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

Illustrative scenario, not a customer case study: An agency is onboarding a new WordPress client with a site to maintain. The agency can log in with named access and run agreed acceptance checks.

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

Record domain, hosting, plugin licenses and contacts

Where
Business owner acceptance sheet and selected application records
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Record domain, hosting, plugin licenses and contacts; exact site identity, named approver and controlled sample data.
Action
Record client's domain/DNS owner, existing host, site administrator, plugin licenses, paid integrations and support contact.
Expected result
The intake sheet has operational ownership.
Verify
The intake sheet has operational ownership. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a critical credential has no owner, keep onboarding incomplete.

Sources: WordPress roles and capabilities · xCloud agent capability boundaries · xCloud hosting for agencies · xCloud team roles and permissions

Step 2 of 5

Request named team access

Where
xCloud team membership dashboard
Permissions
Client-controlled xCloud team owner performs invitation; agency verifies granted scope.
Inputs
Verify team and site permissions and credential transfer; exact site identity, named approver and controlled sample data.
Action
Inspect the intended xCloud team and site permission scope, then ask the client’s authorized team owner to invite the agency’s named accounts through the dashboard. Verify effective access after acceptance; do not request shared passwords.
Expected result
The client remains owner and each agency operator has only the agreed scope.
Verify
The client remains owner and each agency operator has only the agreed scope. Record the exact account or record tested, result, and time with the responsible owner.
If it fails
If the client cannot see its own team, fix access through the authorized owner.

Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · xCloud hosting for agencies · xCloud team roles and permissions

Step 3 of 5

Inventory core, plugins, themes and vulnerabilities

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Inventory core, plugins, themes and vulnerabilities; exact site identity, named approver and controlled sample data.
Action
Inventory core, theme, plugins, vulnerability findings and last backup point on the selected site.
Expected result
Maintainers know the starting condition.
Verify
Maintainers know the starting condition. Record the observed site, account or transaction and time in the release sheet.
If it fails
If backup is unverified, arrange a rehearsal before risky updates.

Sources: WordPress roles and capabilities · xCloud hosting for agencies · xCloud team roles and permissions

Step 4 of 5

Run client-specific business journey tests

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Run client-specific business journey tests; exact site identity, named approver and controlled sample data.
Action
Run the client's actual lead, checkout, booking or editorial journey with a marked test; record failures as baseline issues.
Expected result
The service agreement starts with observed behavior.
Verify
The service agreement starts with observed behavior. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a flow already fails, do not claim it was caused by future maintenance.

Sources: WordPress roles and capabilities · xCloud hosting for agencies · xCloud team roles and permissions

Step 5 of 5

Agree backup, updates, reporting and exit responsibilities

Where
Business owner acceptance sheet and selected application records
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Agree backup, updates, reporting and exit responsibilities; exact site identity, named approver and controlled sample data.
Action
Agree update window, report cadence, restore approval and exit checklist; create those reminders in the agency's real task system.
Expected result
Both sides know recurring responsibilities.
Verify
Both sides know recurring responsibilities. Record the observed site, account or transaction and time in the release sheet.
If it fails
If no named client approver exists, defer production change authority.

Sources: WordPress roles and capabilities · xCloud agent capability boundaries · xCloud hosting for agencies · xCloud team roles and permissions

Maintenance

Recovery decisions

AI handoff

Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.

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

  • 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.

    WordPress roles and capabilities · xCloud agent capability boundaries

  • Manage xCloud team membership and roles dashboard · manual

    Team invitations and role changes require an authorized xCloud team owner in the dashboard. A read-only MCP resource view cannot modify access.

    Checkpoint: Review the exact team, account and role before saving. Sign in as the invited user to verify intended visibility.

    xCloud team roles and permissions · xCloud agent capability boundaries

  • 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.

    WordPress roles and capabilities

Copyable agent brief

Manual checkpoints

  • The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Inventory core, theme, plugins, vulnerability findings and last backup point on the selected site.
  • The business owner compares the controlled sample with this observable result: The service agreement starts with observed behavior.
  • Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage

Sources

Continue

Explore the next WordPress workflow