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 busy WordPress site has slow public pages and a dynamic account area.
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: Caching a cart, account or booking page can expose stale personal state.
Illustrative situation
Illustrative scenario, not a customer case study: A busy WordPress site has slow public pages and a dynamic account area. Public latency improves while two logged-in sessions remain isolated.
Choose the approach
Choose a cache change only after measuring the slow transaction and excluding personalized paths. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud WordPress caching overview · xCloud agent capability boundaries
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
Measure the slow user journey
- Where
- WordPress public pages, administrator and relevant external provider
- Permissions
- Named WordPress or selected app administrator; business owner approves results.
- Inputs
- Owner, hostname, approved requirements, sample record and decision date. Measure the slow user journey.
- Action
- Choose representative public, form and logged-in URLs, one test device and a repeatable traffic window. Record the actual complaint and baseline readings.
- Expected result
- The performance problem is measurable.
- Verify
- Repeat each measurement and keep URL, user state, timing and date together.
- If it fails
- If samples disagree widely, investigate variability before choosing a cache setting.
Sources: WordPress roles and capabilities
Step 2 of 5
Inspect resources and cache layers
- Where
- xCloud selected team/site resource view and owner planning sheet
- 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. Inspect resources and cache layers.
- Action
- Read server CPU, RAM, disk and PHP version in xCloud and document existing page, object and CDN cache layers. Identify dynamic URLs before touching configuration.
- Expected result
- The team knows which layer may affect the slow path.
- Verify
- Compare a cached public page with an authenticated or personalized page and record their behavior.
- If it fails
- If the bottleneck is an external script or large media, do not change unrelated server cache layers.
Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles
Step 3 of 5
Apply one documented change
- Where
- xCloud caching dashboard or selected cache plugin
- Permissions
- Named xCloud team/site administrator; confirm the exact production or staging target.
- Inputs
- Approved change scope, backup state, selected version and maintenance window. Apply one documented change.
- Action
- Select one change, such as a documented cache-layer setting or image optimization, based on the measured bottleneck. Make a backup and apply settings in the xCloud dashboard or relevant plugin.
- Expected result
- Only the approved variable changes.
- Verify
- Capture the previous setting and the exact new value, then purge only where required.
- If it fails
- If the interface differs from documentation, stop and obtain current instructions rather than guessing.
Sources: xCloud WordPress caching overview · xCloud agent capability boundaries
Step 4 of 5
Repeat speed and session tests
- Where
- WordPress public pages, administrator and relevant external provider
- Permissions
- Named WordPress or selected app administrator; business owner approves results.
- Inputs
- Test accounts, sample content or transaction, expected result and provider access. Repeat speed and session tests.
- Action
- Repeat the baseline measurements and run two separate logged-in sessions through cart, account or booking paths as relevant.
- Expected result
- Public performance improves without leaking personalized state.
- Verify
- Compare median results and inspect each user's own data in the dynamic path.
- If it fails
- If dynamic content crosses sessions or becomes stale, revert the setting immediately.
Sources: WordPress roles and capabilities
Step 5 of 5
Record rollback and regression checks
- Where
- WordPress administrator or the selected plugin/application
- Permissions
- Named WordPress or selected app administrator; business owner approves results.
- Inputs
- Observed results, unresolved failures, backup point and owner contacts. Record rollback and regression checks.
- Action
- Record before/after evidence, the cache owner, purge procedure and post-update regression list.
- Expected result
- The optimization is maintainable.
- Verify
- Have another maintainer reproduce one measurement and explain the rollback setting.
- If it fails
- If the gain disappears or harms a business journey, roll back and investigate the original bottleneck.
Sources: WordPress roles and capabilities · WordPress plugin 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: Public latency improves while two logged-in sessions remain isolated. 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
If the changed cache setting breaks a dynamic path, the authorized cache administrator should revert the recorded setting, purge only the affected cache and repeat separate-session cart/account tests. Preserve application records; a WordPress database restore is not a first response to a cache rule.
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.
- Configure WordPress caching dashboard · manual
Cache settings reads and purges do not allow changing cache layers or exclusions. OpenLiteSpeed page exclusions live in the LiteSpeed Cache plugin.
Checkpoint: Use Site → WordPress → Caching or the relevant plugin. Test dynamic booking, checkout and account pages in separate sessions.
- 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
Copyable agent brief
Manual checkpoints
- The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Select one change, such as a documented cache-layer setting or image optimization, based on the measured bottleneck. Make a backup and apply settings in the xCloud dashboard or relevant plugin.
- The business owner compares the controlled sample with this observable result: Public performance improves without leaking personalized state.
- 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): Public latency improves while two logged-in sessions remain isolated. Repeat speed and session tests
- recovery (covered): Caching a cart, account or booking page can expose stale personal state. Record rollback and regression checks
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- xCloud WordPress caching overview
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- xCloud MCP documentation and connection profiles