Book a demo
Book a demo
Login

Solution WordPress

Plan a multilingual WordPress site

Validate translation tooling, URL behavior, publishing workflow, and compatibility. Each language has reviewed navigation, forms and correct alternate links.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

Illustrative scenario, not a customer case study: A company plans content in two languages with different editors. Each language has reviewed navigation, forms and correct alternate links.

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

List languages, content owners and fallback policy

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
List languages, content owners and fallback policy; exact site identity, named approver and controlled sample data.
Action
List languages, editor for each, fallback policy and which pages/forms must be translated before launch.
Expected result
The language plan includes ownership.
Verify
The language plan includes ownership. Record the observed site, account or transaction and time in the release sheet.
If it fails
If no reviewer can approve a language, leave that translation unpublished.

Sources: WordPress roles and capabilities · Polylang language switcher · Polylang language URL settings

Step 2 of 5

Select documented multilingual plugin and license

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Select documented multilingual plugin and license; exact site identity, named approver and controlled sample data.
Action
Compare current multilingual plugin docs, license and WordPress compatibility, including URL and alternate-link behavior.
Expected result
The chosen tool can express the required structure.
Verify
The chosen tool can express the required structure. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a must-have URL mode is unsupported, select another plugin.

Sources: WordPress roles and capabilities · Polylang language switcher · Polylang language URL settings

Step 3 of 5

Build translated navigation and representative pages

Where
WordPress or selected plugin administrator
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Build translated navigation and representative pages; exact site identity, named approver and controlled sample data.
Action
Create representative translated page and navigation in the plugin, preserving approvals for legal/product copy.
Expected result
Each language has a usable path.
Verify
Each language has a usable path. Record the observed site, account or transaction and time in the release sheet.
If it fails
If automatic translation is unreviewed, label it draft.

Sources: WordPress roles and capabilities · WordPress plugin administration · Polylang language switcher · Polylang language URL settings

Step 4 of 5

Test switcher, forms, canonical and alternate links

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Test switcher, forms, canonical and alternate links; exact site identity, named approver and controlled sample data.
Action
Test switcher, canonical and alternate links, form fields and confirmation in each language on desktop and mobile.
Expected result
Visitors remain in their intended language across the journey.
Verify
Visitors remain in their intended language across the journey. Record the observed site, account or transaction and time in the release sheet.
If it fails
If one form sends the wrong-language message, fix its app setting before launch.

Sources: WordPress roles and capabilities · Polylang language switcher · Polylang language URL settings

Step 5 of 5

Plan update workflow for changed source-language content

Where
WordPress or selected plugin administrator
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Plan update workflow for changed source-language content; exact site identity, named approver and controlled sample data.
Action
Assign translation refresh when source copy changes and check old-language URLs after updates.
Expected result
Versions stay aligned after maintenance.
Verify
Versions stay aligned after maintenance. Record the observed site, account or transaction and time in the release sheet.
If it fails
If a later restore revives stale translation, republish reviewed text.

Sources: WordPress roles and capabilities · WordPress plugin administration · Polylang language switcher · Polylang language URL settings

Maintenance

Recovery decisions

  • Before restoring, compare the chosen recovery point with newer business records. Machine translation alone may leave legal or product copy wrong. Use the xCloud dashboard for native restore only after the owner approves target and scope; reconcile or preserve newer data first.

    Site backups in xCloud · xCloud agent capability boundaries

  • Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident.

    Site backups in xCloud · WordPress hardening handbook

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.

    WordPress roles and capabilities

  • 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: Create representative translated page and navigation in the plugin, preserving approvals for legal/product copy.
  • The business owner compares the controlled sample with this observable result: Visitors remain in their intended language across the journey.
  • 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

Sources

Continue

Explore the next WordPress workflow