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: A small firm needs its first public WordPress site, with one person approving copy and another handling hosting.
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 DNS change or missing mail delivery can make a polished site unusable.
Illustrative situation
Illustrative scenario, not a customer case study: A small firm needs its first public WordPress site, with one person approving copy and another handling hosting. A visitor reaches the intended HTTPS home page, submits the contact form and the owner receives it.
Choose the approach
Choose a launch date only after the domain owner and content owner sign off. 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
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
Approve the page and contact plan
- Where
- WordPress administrator or the selected plugin/application
- Permissions
- Named WordPress or selected app administrator; business owner approves results.
- Inputs
- Owner, hostname, approved requirements, sample record and decision date. Approve the page and contact plan.
- Action
- Ask the owner to approve a page inventory with homepage, service, about, contact and policy pages, then mark the editor for each. Record the exact address and whether inquiries use a form, telephone or both.
- Expected result
- The approved page list and response owner are named.
- Verify
- Have the owner find each required page in the inventory and identify who answers a sample inquiry.
- If it fails
- If the contact owner or policy copy is undecided, publish a working phone route and keep unapproved pages private.
Sources: WordPress roles and capabilities · WordPress plugin administration
Step 2 of 5
Create the native WordPress site
- Where
- xCloud Add site and site overview
- Permissions
- Named xCloud team/site administrator; confirm the exact production or staging target.
- Inputs
- Target team/site, server or plugin version, license and documented prerequisites. Create the native WordPress site.
- Action
- In xCloud select the intended team and a compatible Nginx or OpenLiteSpeed server for a native WordPress site. Confirm domain control with the DNS owner, expected capacity and administrator identity before creating it.
- Expected result
- The site is provisioned under the correct team and hostname.
- Verify
- Compare the new site's returned identity and server with the signed launch sheet; wait for provisioning to finish.
- If it fails
- If the stack or domain is wrong, stop before changing DNS and correct the plan rather than creating a duplicate site.
Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles
Step 3 of 5
Build pages and verify inquiry delivery
- Where
- WordPress administrator or the selected plugin/application
- Permissions
- Named WordPress or selected app administrator; business owner approves results.
- Inputs
- Approved change scope, backup state, selected version and maintenance window. Build pages and verify inquiry delivery.
- Action
- In WordPress create the approved page structure, navigation and contact form with a documented form plugin if needed. Set only the named staff roles, and connect mail delivery through its chosen provider.
- Expected result
- Visitors can navigate approved content and submit a test inquiry.
- Verify
- As an anonymous visitor open every navigation item; submit a distinct test message and compare the saved entry where the selected plugin provides one with the recipient inbox.
- If it fails
- If the form succeeds on screen but mail does not arrive, retain a visible phone or email contact and troubleshoot the provider before launch.
Sources: WordPress roles and capabilities · WordPress plugin administration
Step 4 of 5
Switch DNS, then verify HTTPS
- Where
- Authorized DNS provider, xCloud SSL dashboard and public browser
- Permissions
- Domain DNS owner changes only approved records; xCloud site administrator verifies SSL; business owner approves cutover.
- Inputs
- Test accounts, sample content or transaction, expected result and provider access. Point DNS and test HTTPS.
- Action
- Point the agreed DNS records to the site when the content owner approves. Inspect the HTTPS certificate, primary host redirect, canonical page URL and administrator login from a fresh browser session.
- Expected result
- The intended address reaches the intended content securely.
- Verify
- Test both agreed host variants from a separate network or DNS resolver, then repeat the inquiry journey.
- If it fails
- If DNS or certificate validation fails, keep the previous service available and follow the documented SSL troubleshooting path.
Sources: Enable HTTPS and configure SSL certificates in xCloud · xCloud SSL certificate operations · xCloud WordPress migration guide
Step 5 of 5
Confirm backup and ownership
- Where
- xCloud Site Backup dashboard
- Permissions
- Named xCloud team/site administrator; confirm the exact production or staging target.
- Inputs
- Observed results, unresolved failures, backup point and owner contacts. Confirm backup and ownership.
- Action
- Open Site Backup and confirm a completed files-and-database point, destination and restore contact. Give the owner a short schedule for selected updates, form tests and content review.
- Expected result
- The owner has a usable recovery point and maintenance responsibilities.
- Verify
- Record the backup identifier and have the owner explain how to request a safe-target restore and retest the form.
- If it fails
- If backup completion or access is unproven, keep the launch checklist open and arrange a restore rehearsal.
Sources: Site backups in xCloud · xCloud agent capability boundaries
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 visitor reaches the intended HTTPS home page, submits the contact form and the owner receives it. 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
Before restoring, compare the chosen recovery point with newer business records. A DNS change or missing mail delivery can make a polished site unusable. Use the xCloud dashboard for native restore only after the owner approves target and scope; reconcile or preserve newer data first.
Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident.
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
- Configure WordPress content, users and selected plugins app · manual
Requires a named WordPress administrator or suitable editor. Plugin behavior, commercial license, payment, email and external integration are verified in the chosen vendor documentation and application; xCloud hosting or MCP reads do not configure them.
Checkpoint: Open the actual WordPress or selected plugin interface, record the version and role, and have the business owner accept a real user journey.
WordPress roles and capabilities · WordPress plugin administration
- Create a WordPress site mcp · write
Requires a compatible Nginx or OpenLiteSpeed server; Docker and single-site agentic servers cannot host a new WordPress site.
Checkpoint: Approve the exact server, domain, capacity, cost and creation inputs before provisioning. Verify completion and HTTPS.
Operation identifiers and scopes to discover
servers.sites.wordpress.create
Scopes: write:sites
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles
- Change domain DNS and verify routing app · manual
DNS changes belong to the domain provider or authorized DNS integration; reading an xCloud site does not establish public propagation or certificate validity.
Checkpoint: Approve exact hostname and record values; check authoritative DNS and live HTTPS from an independent session.
xCloud WordPress migration guide · Enable HTTPS and configure SSL certificates in xCloud
- Configure native WordPress backup and restore dashboard · manual
Native schedule, retention and destination changes and all restores are dashboard-only.
Checkpoint: Use Site → Site Backup. Before restoring, confirm backup, target, scope and treatment of newer records.
Copyable agent brief
Manual checkpoints
- The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: In WordPress create the approved page structure, navigation and contact form with a documented form plugin if needed. Set only the named staff roles, and connect mail delivery through its chosen provider.
- The business owner compares the controlled sample with this observable result: The intended address reaches the intended content securely.
- 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
- business-acceptance (covered): A visitor reaches the intended HTTPS home page, submits the contact form and the owner receives it. Switch DNS, then verify HTTPS
- recovery (covered): A DNS change or missing mail delivery can make a polished site unusable. Confirm backup and ownership
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
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- Enable HTTPS and configure SSL certificates in xCloud
- xCloud SSL certificate operations
- xCloud WordPress migration guide