# Launch a WordPress business site Plan a first production WordPress site from requirements through launch. A visitor reaches the intended HTTPS home page, submits the contact form and the owner receives it. Canonical: https://xcloud.host/use-cases/playbooks/launch-a-wordpress-business-site/ Published: 2026-09-30 · Updated: 2026-09-30 · Technical review: 2026-09-30 Evidence: Source reviewed; no production deployment test claimed Editorial owner: xCloud editorial Intent: Plan a first production WordPress site from requirements through launch. For: business-owner, operator ## 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. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WordPress roles and capabilities](https://wordpress.org/documentation/article/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. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) - 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. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [WordPress hardening handbook](https://developer.wordpress.org/advanced-administration/security/hardening/) ## 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. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs); [WordPress roles and capabilities](https://wordpress.org/documentation/article/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. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) ## Dashboard and application procedure ### 1. 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. Capability: Configure WordPress content, users and selected plugins Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) ### 2. 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. Capability: Create a WordPress site Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) ### 3. 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. Capability: Configure WordPress content, users and selected plugins Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) ### 4. 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. Capability: Change domain DNS and verify routing Sources: [Enable HTTPS and configure SSL certificates in xCloud](https://xcloud.host/docs/enable-https-in-xcloud-configure-ssl-certificates/); [xCloud SSL certificate operations](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/skills/ssl/SKILL.md); [xCloud WordPress migration guide](https://xcloud.host/docs/guide-to-wordpress-site-migration-on-xcloud/) ### 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. Capability: Configure native WordPress backup and restore Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ## 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. Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/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. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ## 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. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) - Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [WordPress hardening handbook](https://developer.wordpress.org/advanced-administration/security/hardening/) ## 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 to discover: teams.index, servers.show, sites.show. Scopes: read:servers, read:sites. Sources: [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) - **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. Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) - **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 to discover: servers.sites.wordpress.create. Scopes: write:sites. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) - **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. Sources: [xCloud WordPress migration guide](https://xcloud.host/docs/guide-to-wordpress-site-migration-on-xcloud/); [Enable HTTPS and configure SSL certificates in xCloud](https://xcloud.host/docs/enable-https-in-xcloud-configure-ssl-certificates/) - **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. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ### Copyable agent brief ```text Help with launch a wordpress business site for the exact xCloud team and site I name. First inspect only resources the connection permits and confirm returned identity, stack and relevant versions. Prepare the following authored workflow: Approve the page and contact plan; Create the native WordPress site; Build pages and verify inquiry delivery; Switch DNS, then verify HTTPS; Confirm backup and ownership. Ask the named dashboard, domain, WordPress and application owners to perform operations outside connected capabilities. WordPress staging push/pull, native backup schedules, restore and cache settings remain manual dashboard tasks; the packaged REST wrapper is GET-only. Use the guide’s checks to report observed application evidence, unresolved questions and recovery implications; do not claim completion from a hosting resource read. Acceptance: The intended address reaches the intended content securely. ``` ### 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. Steps: phase-4 - **recovery** (covered): A DNS change or missing mail delivery can make a polished site unusable. Steps: phase-5 ## Sources - [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) — reviewed 2026-09-30; v4.4.2 package; xCloud v2.8.8 capability review - [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/) — reviewed 2026-09-30 - [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) — reviewed 2026-09-30 - [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/) — reviewed 2026-09-30 - [WordPress hardening handbook](https://developer.wordpress.org/advanced-administration/security/hardening/) — reviewed 2026-09-30 - [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) — reviewed 2026-09-30 - [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/) — reviewed 2026-09-30 - [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/) — reviewed 2026-09-30 - [Enable HTTPS and configure SSL certificates in xCloud](https://xcloud.host/docs/enable-https-in-xcloud-configure-ssl-certificates/) — reviewed 2026-09-30 - [xCloud SSL certificate operations](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/skills/ssl/SKILL.md) — reviewed 2026-09-30; v4.4.2 - [xCloud WordPress migration guide](https://xcloud.host/docs/guide-to-wordpress-site-migration-on-xcloud/) — reviewed 2026-09-30 ## Continue [Explore the next WordPress workflow](https://xcloud.host/use-cases/playbooks/move-an-existing-wordpress-site-to-xcloud/) - [Create a WordPress site and verify its first page](https://xcloud.host/use-cases/workflows/create-a-wordpress-site-and-verify-its-first-page/) - [Configure a domain for a WordPress site](https://xcloud.host/use-cases/workflows/configure-a-domain-for-a-wordpress-site/) - [Check WordPress mail delivery after launch](https://xcloud.host/use-cases/solutions/check-wordpress-mail-delivery-after-launch/)