Requirements and responsibilities
Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: An organization considers WordPress multisite for related publications.
xCloud agent capability boundaries · WordPress roles and capabilities
Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.
xCloud agent capability boundaries · WordPress plugin administration
Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: A shared network can broaden update and recovery impact.
Illustrative situation
Illustrative scenario: an organization is choosing between subdomain multisite and separate WordPress sites. The decision records ownership, plugin and recovery tradeoffs, plus a future pilot matrix.
Choose the approach
Choose multisite only after reviewing shared administration and plugin constraints. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · WordPress roles and capabilities · WordPress multisite administration
Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end.
xCloud agent capability boundaries · WordPress plugin administration
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
List shared versus independent sites and administrators
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- List shared versus independent sites and administrators; exact site identity, named approver and controlled sample data.
- Action
- List proposed sites, domains, editors, plugins and whether content/data should be independent.
- Expected result
- The decision has shared-versus-separate criteria.
- Verify
- The decision has shared-versus-separate criteria. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If legal ownership differs, treat shared network administration as a risk.
Sources: WordPress roles and capabilities · WordPress multisite administration
Step 2 of 5
Review WordPress multisite and xcloud support docs
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Review wordpress multisite and xcloud support docs; exact site identity, named approver and controlled sample data.
- Action
- Read WordPress multisite and xCloud support docs for domain, plugin and network-administrator constraints.
- Expected result
- The option reflects documented behavior.
- Verify
- The option reflects documented behavior. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If a required plugin lacks network support, do not assume it works.
Sources: WordPress roles and capabilities · WordPress multisite administration · xCloud WordPress multisite with subdomains
Step 3 of 5
Compare network setup with separate-site option
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Compare network setup with separate-site option; exact site identity, named approver and controlled sample data.
- Action
- Compare one multisite network with separate WordPress sites for update scope, access and restore isolation.
- Expected result
- The owner sees the blast radius of each choice.
- Verify
- The owner sees the blast radius of each choice. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If a client needs independent recovery, weigh separate sites heavily.
Sources: WordPress roles and capabilities · WordPress multisite administration · xCloud WordPress multisite with subdomains
Step 4 of 5
Design a subdomain pilot
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Pilot roles, domain and plugin behavior on test environment; exact site identity, named approver and controlled sample data.
- Action
- Write a future pilot matrix for one subdomain, network administrator, site editor and required plugin. Note that xCloud’s current documented multisite setup is subdomain-based and verify eligibility before any build.
- Expected result
- The proposed pilot has expected domain, role and plugin checks; no pilot is claimed complete.
- Verify
- The proposed pilot has expected domain, role and plugin checks; no pilot is claimed complete. Record the exact account or record tested, result, and time with the responsible owner.
- If it fails
- If no test owner exists, record the assumption as unresolved.
Sources: WordPress roles and capabilities · WordPress multisite administration · xCloud WordPress multisite with subdomains
Step 5 of 5
Decide backup and incident blast radius before launch
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Decide backup and incident blast radius before launch; exact site identity, named approver and controlled sample data.
- Action
- Recommend one path with required proof, backup granularity and client approval. Include an explicit test owner and unresolved domain assumptions.
- Expected result
- The decision can guide a separate implementation.
- Verify
- The decision can guide a separate implementation. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- Do not present multisite as a default cost or maintenance saving without evidence.
Sources: WordPress roles and capabilities · WordPress multisite administration
Maintenance
Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: A pilot site has correct domain, editors and network ownership. A chat prompt is not a scheduled task.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone.
Recovery decisions
This comparison makes no access or network change. If a required domain, plugin or isolation need is unsupported, revise the recommendation toward separate sites and seek a documented test before setup.
xCloud WordPress multisite with subdomains · WordPress multisite administration
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
- 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.
Copyable agent brief
Manual checkpoints
- The named site, business or provider owner supplies application evidence the connected hosting reads cannot observe.
- A separately approved operator performs any later configuration, staging, update, restore or publication described in the decision sheet.
- The owner accepts the review finding and proposed checks without treating the unexecuted change as completed.
Feature coverage
- business-acceptance (covered): A pilot site has correct domain, editors and network ownership. Design a subdomain pilot
- recovery (covered): A shared network can broaden update and recovery impact. Decide backup and incident blast radius before launch
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- xCloud MCP documentation and connection profiles
- WordPress multisite administration
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- xCloud WordPress multisite with subdomains