Book a demo
Book a demo
Login

App workflow WordPress

Review a WordPress site’s admin users

Confirm account owners and intended access with the site owner before changing permissions. 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 former contractor may still have WordPress administrator access to a client site. The owner must audit user roles and remove stale access without locking out the client.

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

List current users

Where
WordPress Users → All Users
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Site ID, user email, role, last known owner
Action
Export or record users and roles, including service accounts and pending invitations. Mark who still has a business reason for access.
Expected result
A dated access roster.
Verify
Compare each admin with the client staff and vendor list.
If it fails
If an unfamiliar admin appears, preserve evidence and escalate before altering it.

Sources: WordPress roles and capabilities

Step 2 of 5

Inspect capabilities

Where
WordPress role settings and plugin-specific roles
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Administrator, editor, custom roles
Action
Check what each role can actually do, including plugin-created capabilities. Identify accounts that can install plugins, edit users or view sensitive submissions.
Expected result
A least-privilege target role for each person.
Verify
Test a limited account's actual view in a safe session.
If it fails
If a custom role has broad permissions, correct the role design before reassignment.

Sources: WordPress roles and capabilities

Step 3 of 5

Secure an owner account

Where
WordPress Users and secret manager
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Client owner identity, MFA method, recovery contact
Action
Confirm the current client administrator can sign in and recover access. Create or verify a second approved recovery path if policy requires.
Expected result
At least one working authorized owner after cleanup.
Verify
Have the owner complete a fresh-session login.
If it fails
If no owner can log in, resolve recovery before deleting accounts.

Sources: WordPress roles and capabilities

Step 4 of 5

Remove stale WordPress access

Where
WordPress Users
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Departed account and approved replacement
Action
Downgrade or remove the contractor's WordPress user after reassigning owned content as needed. Rotate any shared WordPress secrets.
Expected result
No stale WordPress login.
Verify
Recheck the Users list and test the removed account cannot sign in.
If it fails
If a service integration breaks, restore only its documented service credential, not contractor access.

Sources: WordPress roles and capabilities

Step 5 of 5

Record recurring review

Where
Client access register and xCloud Team Management
Permissions
xCloud team owner authorized to review or change membership; preserve another working owner.
Inputs
Review cadence, joiner/leaver owner
Action
Document decisions, residual service accounts and next review. Have the team owner separately remove any stale xCloud team membership after confirming another owner can still administer the site.
Expected result
An auditable access record in both systems.
Verify
Have another administrator confirm WordPress users and xCloud team roster.
If it fails
If the roster drifts, investigate changes and repeat the review promptly.

Sources: xCloud team roles and permissions

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