Hand over WordPress maintenance and client reporting

Where

xCloud team and site views or connected MCP resource reads

Permissions

Authorized owner or administrator for the named team, site and application.

Inputs

Client name, team, production domain, site UUID, server, application owner and support contacts.

Action

Confirm the exact production site and assigned team. Record who owns DNS, WordPress admin, backups, updates, payment or form integration, and incident response.

Expected result

A single site identity and responsibility matrix for the reporting period.

Verify

Have the client confirm the domain and escalation contact; compare site URL and returned dashboard_url.

If it fails

If team access is missing, ask the authorized owner to grant it; do not infer a missing site from an empty list.

Sources: xCloud agent capability boundaries · xCloud hosting for agencies

Where

Site → Site Backup; Updates Manager; Site → WordPress → Vulnerability Scan

Permissions

Authorized owner or administrator for the named team, site and application.

Inputs

Last completed backup, destination/retention, update history, open findings and previous maintenance date.

Action

Inspect backup completion and retention. Capture selected updates and vulnerability findings with dates, severity and owner. Mark each item as completed, open or blocked.

Expected result

Traceable maintenance evidence tied to the named site and period.

Verify

Check each report claim against the underlying status or history; record the backup identifier and restoration rehearsal date.

If it fails

If backup is missing, failed or inaccessible, escalate before a planned production change and record the gap.

Sources: Site backups in xCloud · Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud

Where

Production WordPress and business application interfaces

Permissions

Authorized owner or administrator for the named team, site and application.

Inputs

Safe test account, form destination, payment sandbox or approved live verification method.

Action

Verify the public landing page, contact form delivery, login and the client’s revenue path. For a store, confirm cart, checkout and order email in a safe environment. Record actual observations.

Expected result

Pass/fail results for the journeys the client relies on.

Verify

Compare receipt or destination evidence, not only a successful page load. Retain test identifiers without exposing customer data.

If it fails

If a journey fails, open an incident with symptom, time, owner and next action; do not mark it healthy from host status alone.

Sources: WordPress website maintenance reports for clients · WooCommerce testing orders

Where

Site → Client Reports; agency review

Permissions

Authorized owner or administrator for the named team, site and application.

Inputs

Reporting period, confirmed site, source evidence, work log, owners and recipients.

Action

Use the dashboard report workflow, then reconcile its entries with backup, update and business-test notes. Add clear unresolved items and next dates through the client’s reporting process.

Expected result

A client-ready report that distinguishes completed work, observations and planned action.

Verify

Have a second owner check site identity, dates, recipient list, sensitive data and every claimed result.

If it fails

If the generated report omits a known failure or counts a pending job as complete, correct the handover before distribution.

Sources: WordPress website maintenance reports for clients

Where

xCloud team dashboard, WordPress admin, DNS/storage provider and client meeting

Permissions

Client-owned administrators sign in; each provider owner controls its own permissions.

Inputs

Client-owned named accounts, exact team/site, WordPress role, DNS/storage account, latest completed backup and safe test task.

Action

Have the client sign in through its own xCloud and WordPress accounts, locate the intended site and latest completed backup, then complete a harmless content correction or draft review. Ask the DNS and storage owners to demonstrate where their respective controls live without sharing secrets.

Expected result

The client can administer routine content and identify recovery and domain controls without agency credentials.

Verify

Observe the client account reach the correct team/site, complete the test action and identify backup point and separate provider owners.

If it fails

If an invitation is pending or the client cannot find its own backup or DNS owner, defer agency revocation and assign a transfer date.

Sources: xCloud team roles and permissions · WordPress roles and capabilities · Site backups in xCloud

Where

Agency/client handover meeting and secure document store

Permissions

Authorized owner or administrator for the named team, site and application.

Inputs

Approved report, access matrix, escalation contacts, restore owner and next review date.

Action

Give the client the checked report and a runbook for who to call, how to authorize changes and where backup decisions are recorded. Obtain acknowledgement of open items, client-owned access rehearsal and the agency revocation sequence.

Expected result

The agency and client agree on the next maintenance window and incident path.

Verify

Ask the receiving owner to locate the latest recovery point and explain the escalation route without reading a credential from the report.

If it fails

If ownership or recovery access is disputed, leave the issue open and schedule a specific resolution owner and date.

Sources: WordPress website maintenance reports for clients · xCloud hosting for agencies

Where

xCloud team dashboard, WordPress and provider account consoles

Permissions

Client xCloud owner, WordPress administrator and each DNS/storage/provider owner revoke only their own accounts.

Inputs

Signed client acceptance, agency user list, access dependencies and exception dates.

Action

After the client accepts the access rehearsal and report, have the xCloud team owner remove agency membership; the WordPress administrator and each DNS, storage or paid-provider owner separately remove agency accounts. Verify no shared credential remains and record any licensed item still awaiting transfer.

Expected result

The client retains control while agency access ends on every agreed surface.

Verify

Test a client-owned login after revocation and ask each owner to confirm the agency account is gone from that system.

If it fails

If a resource still depends on an agency-owned account, leave only that item open with a named transfer owner and date; do not remove the last administrator.

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