Multilingual site launch checklist

Use this checklist after the site’s required languages and translation surfaces have been configured. It is an approval review, not a substitute for translating unfinished content.

Run it on the release candidate that will become production. Record failures by locale, URL, object, user role, and exact action.

Freeze the language plan

• The Main language matches Settings → General → Site Language.
• Every required locale appears once under Additional languages.
• Locale order and custom selector labels are approved.
• The default-language prefix decision is final.
• Browser-language detection and its fallback are either deliberately configured or deliberately disabled.
• A redirect owner exists for any URL changed during migration.

Do not change locale codes or the main-language prefix during final verification.

Confirm access and licensing

• Settings → POM Translate → License shows a valid POM Translate product, domain, plan, and expiry.
• Dashboard → Updates or the network update screen completes a private update check.
• Administrators can manage settings, translations, and slugs.
• Editors who own translation work can open Translations without receiving settings or software-catalog permissions they should not have.
• Optional POM AI authorization has been tested separately from the POM Translate license.

On multisite, repeat the configuration review for every participating site and confirm the main/network update license.

Review the content inventory

For every enabled post type:

• title, content, excerpt, and meta choices match the editorial plan;
• representative short, long, empty, formatted, and shortcode-heavy records have been checked;
• changed source content has had a target-language review;
• incomplete translations use an accepted source fallback;
• protected formatting markers are intact;
• generated translations have received human review where required.

For every enabled taxonomy, review names, descriptions, slugs, archives, parents, and assigned content.

Verify public routes

• Source and localized home URLs resolve.
• Representative posts, pages, custom post types, terms, archives, pagination, search, and 404 responses use the correct locale.
• Hierarchical pages and terms preserve their parent paths.
• Localized slugs are unique within their route context.
• Main-language routes follow the chosen prefix policy.
• Old public URLs have deliberate redirects where needed.
• Excluded content does not remain linked from a visible selector or menu.

Test the origin before relying on a cached or CDN response.

Check navigation and selectors

• Menu labels use the intended locale.
• Post, term, home, and custom menu links lead to the correct language.
• Navigation-menu, shortcode, and floating selectors show only the intended languages.
• Hiding the current language does not leave an ambiguous dropdown control.
• Selector labels, flags, focus order, keyboard operation, and mobile presentation are usable.
• Switching languages preserves the matching object when a localized route exists.

Inspect discovery and SEO

• The document language attribute matches the active locale.
• Canonical URLs are localized.
• Alternate-language links cover the intended variants and use the correct destinations.
• Rank Math or Yoast still owns one coherent sitemap system.
• Sitemap entries resolve and do not expose draft, excluded, or conflicting URLs.
• Search-engine visibility and redirect status codes match the launch decision.

Exercise dynamic and optional integrations

Where the site uses them:

• AJAX and REST output respects explicit locale input and does not translate editing responses;
• WooCommerce product, cart, checkout, account, order, and email journeys retain the customer or order locale;
• transactional email subjects, headings, bodies, placeholders, and plain-text variants are approved;
• registered defaults and software translations load in the correct context;
• page builders and custom fields retain structure and non-translatable technical values.

Do not approve an integration based only on its settings screen.

Clear and warm caches deliberately

• Translation saves invalidate the runtime entries they own.
• POM Cache progressive JSON invalidation is enabled when that cache contains translated archive data.
• Page cache and CDN objects containing old content or routes are removed.
• A cold origin request and a warm public request return the same language.
• Signed-in and signed-out states do not share private output.

A broad purge can remove stale evidence. Confirm the source and route first, then clear only the layers that hold the old response.

Approve or stop

The multilingual site is ready when every required locale has:

• an accountable content owner;
• complete or explicitly accepted fallback content;
• verified public routes and language metadata;
• tested navigation and primary visitor journeys;
• a current export and recoverable site backup;
• no unresolved placeholder, permission, license, routing, or cache failure.

After deployment, repeat the homepage, one representative content route, the language round trip, update discovery, and every revenue- or email-critical workflow against the public domain.