Book a demo
Book a demo
Login

App workflow WordPress

Configure a domain for a WordPress site

Verify DNS ownership, current records, TLS status, canonical URL, and redirect behavior. 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 new WordPress site is ready on a temporary address. The owner wants its production domain to resolve to the correct server and serve the canonical HTTPS URL.

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

Inventory current records

Where
DNS provider and xCloud site domains
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
A/AAAA/CNAME records, server IP, TTL
Action
Record current answers for apex and www and any old service. Confirm the xCloud server address and whether mail DNS records must remain untouched.
Expected result
A cutover map and rollback values.
Verify
Query both public hostnames from an external resolver.
If it fails
If ownership or old target is unclear, defer DNS edits.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 2 of 5

Set the intended domain

Where
xCloud site domain settings
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Canonical host, alternate host, site ID
Action
After owner approval, add or select the production hostname in the xCloud dashboard. Confirm it associates with the correct server and site.
Expected result
A domain mapping in xCloud.
Verify
Compare displayed site ID and hostname before DNS change.
If it fails
If another site owns the host, resolve conflict rather than deleting blindly.

Sources: Enable HTTPS and configure SSL certificates in xCloud · xCloud agent capability boundaries

Step 3 of 5

Update DNS deliberately

Where
Authoritative DNS provider
Permissions
Authoritative DNS administrator with the approved record values and a retained rollback copy.
Inputs
Approved record values and cutover window
Action
The DNS administrator replaces only required web records after approval; retain MX, TXT and other mail/security records. Record prior values for reversal.
Expected result
Public DNS begins directing web traffic to xCloud.
Verify
Query A/AAAA and CNAME answers and compare to approved target.
If it fails
If answers remain stale, wait for TTL or inspect authoritative configuration.

Sources: Enable HTTPS and configure SSL certificates in xCloud

Step 4 of 5

Issue and inspect HTTPS

Where
xCloud SSL controls and external browser
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Hostname, certificate request, DNS state
Action
Request or inspect the certificate for every served hostname, wait for issuance, then open the site via HTTPS and read certificate name and expiry.
Expected result
No certificate warning on the canonical URL.
Verify
Check chain, host match, page response and admin login externally.
If it fails
If issuance fails, diagnose DNS/firewall/CAA using xCloud SSL guidance before retrying.

Sources: Enable HTTPS and configure SSL certificates in xCloud · xCloud SSL certificate operations

Step 5 of 5

Check redirects and WordPress URLs

Where
WordPress Settings → General; browser
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Preferred host and test page
Action
Verify site URL, internal links and www/apex redirects match the chosen canonical host. Load a media item and form after the transition.
Expected result
One stable public host with functional content.
Verify
Test both host variants and ensure they converge once without mixed-content warnings.
If it fails
If redirect loops occur, compare WordPress URL, xCloud domain and proxy settings before changing records again.

Sources: Manage WordPress plugins

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