WordPress multilingual migration: WPML, Polylang and URL structure

A multilingual WordPress rebuild is two migrations running in parallel — one per locale — plus a third layer of wiring that connects them. WPML and Polylang store translation relationships in post meta and custom tables, hreflang tags depend on those relationships being correct, and URL structures (/en/services/ vs /de/leistungen/) mean your redirect map is multiplied by language count. Agencies that treat multilingual as 'we'll translate after launch' routinely ship sites where German pages 404, English and French versions point at each other incorrectly, and Search Console shows hreflang errors across every market. This guide covers multilingual migration end to end for WPML and Polylang during an ACF block rebuild.

What breaks on multilingual rebuilds

• arrow_rightTranslation links — Polylang's pll_translation or WPML's translation group IDs don't survive a naive WXR import.
• arrow_rightURL prefixes — changing /en/ to /english/ without redirects loses every indexed URL in that locale.
• arrow_rightHreflang — rebuilt without translation pairs, Google sees conflicting or missing language alternates.
• arrow_rightACF fields — field groups may be set to copy or translate per WPML; wrong settings wipe translated meta.
• arrow_rightMenus — separate menus per language rarely import cleanly; footer legal links often stay monolingual.
• arrow_rightCPT archives — portfolio or case study archives per language need matching rewrite rules and redirects.
• arrow_rightString translations — theme labels, widget text, and button copy vanish if String Translation is not re-scanned.
• arrow_rightWooCommerce — product translations, currency display, and cart URLs need separate QA from marketing pages.

Choose your URL structure before you migrate

Multilingual WordPress sites typically use one of three URL patterns. Subdirectories (example.com/de/) are the most common for agency rebuilds — one SSL certificate, one Search Console property, straightforward hreflang. Subdomains (de.example.com) need DNS records per locale and cross-subdomain hreflang configuration. Separate domains (example.de, example.fr) require the most redirect and hreflang coordination but sometimes match how the client already ranks. Rebuilds are not the moment to change structure unless the client explicitly wants it and accepts the SEO risk. If the old site uses /de/, keep /de/ on the new site.

Inventory before you migrate

1. 1List active languages and the default locale.
2. 2Document URL structure — subdirectory (/de/), subdomain (de.example.com), or separate domains.
3. 3Export a URL list per language from the sitemap or a crawl — that's your per-locale redirect spine.
4. 4Note which post types and taxonomies are translated vs shared.
5. 5Screenshot WPML/Polylang settings: language switcher position, slug translation rules, media translation mode.
6. 6Identify ACF field groups marked 'translate', 'copy', or 'copy once' in WPML.
7. 7Export translation pairing data — old post ID, language, linked translation IDs — before decommissioning.
8. 8List pages that exist in only one language vs full translation sets.

WPML migration specifics

WPML stores translation groups via icl_translations — each post has a trid (translation group ID) and language_code. A page and its German and French counterparts share a trid. On rebuild, you need the new site to recreate those groups after content import. WPML's own migration documentation recommends activating WPML on the destination before import, then using WPML's import tools or WP All Import with WPML add-ons for large corpora. For sites with hundreds of translated pages, budget a developer day specifically for trid verification — not a spot-check.

WPML + ACF field translation modes

WPML Multilingual CMS integrates with ACF via field translation preferences. 'Translate' fields (headline, body copy) should differ per locale. 'Copy' fields (layout toggle, background colour) should stay identical across translations. 'Copy once' fields copy from the original on first translation creation then become independent. If you import ACF JSON to the new site without replicating these settings, editors see English copy in German pages or lose field values entirely. Document field modes in a spreadsheet during discovery — attach it to the project repo.

Polylang migration specifics

Polylang stores language assignment in term relationships and post meta (pll_lang). Translation pairs use a translations serialized array in post meta. Polylang Pro's export/import and compatibility with WordPress importer are more manual than WPML's enterprise tooling — for agency rebuilds, developers often script pair remapping: match posts by slug stem, shared post_name with lang prefix, or a maintained CSV of old ID → new ID per language. Polylang's language taxonomy (language terms) must exist on the destination before posts assign correctly.

Migrating content into ACF blocks per locale

AIRA and crawl-based migration work per URL — which maps cleanly to multilingual when you crawl each locale's rendered pages separately. A German homepage at /de/ classifies into the same ACF blocks as /en/ but with German copy in text fields. Run path filters per language prefix so block mapping rules stay consistent; only the content differs. For builder-built pages (Elementor, Divi), crawl each translation's public URL — do not assume the English crawl structure applies to German layout if the builder stored separate documents per language.

ACF field groups with WPML 'translate' fields need those fields editable per locale on the new site. 'Copy' fields (like a background colour) should sync across translations — verify WPML field settings after importing ACF JSON to the destination. For custom post types, decide whether portfolio entries are translated (separate German case study) or shared (one case study, language-neutral). Mixed strategies confuse hreflang on CPT singles.

CPTs, taxonomies, and archives per language

Translated custom post types need register_post_type and register_taxonomy on the new site before import, with WPML or Polylang configured to translate those types. Archive URLs per language (/de/referenzen/ vs /en/work/) require rewrite rules registered before flushing permalinks. If the old site filtered portfolio archives by taxonomy with AJAX, each translated term slug needs a redirect if renamed. Faceted search plugins (FacetWP, Search & Filter Pro) store language-specific query strings — test filter URLs in every locale, not just English.

Hreflang and SEO per language

• arrow_rightCarry over title and meta description per locale — not just the default language.
• arrow_rightVerify hreflang output in page source for every template: home, page, post, CPT single, archive.
• arrow_rightx-default tag should point at the intended fallback (usually English or language picker).
• arrow_rightCanonicals must be self-referencing per locale — German page canonicals to German URL, not English.
• arrow_rightRegenerate XML sitemaps per language in SEOPress, Yoast, or Rank Math and resubmit in Search Console per property if using separate GSC properties.
• arrow_rightStructured data (Organization, LocalBusiness, Article) must not mix languages in a single graph node.

Cross-reference preserve SEOPress SEO, Yoast preservation, and Rank Math preservation for plugin-specific meta migration — run those steps per language, not once on the default locale.

Redirects across languages

Each old URL needs a 301 to its new equivalent in the same language. Common failure: redirecting /de/alt-seite/ to /en/new-page/ because an English slug was copied. Language must be preserved in the redirect target. Paginated archives (/de/blog/page/2/), feed URLs, and translated CPT slugs all need entries. Query-string variants (?lang=de) from legacy setups need explicit rules if the new site drops query-based language detection.

Redirect mechanics and spreadsheet structure: redirect map guide. For large multilingual maps, split CSVs by language code and import in batches so you can QA French redirects without wading through German rows.

Menus, footers, and language switcher UX

Menus do not migrate reliably with translation links intact — see menu migration guide. Rebuild primary nav, footer, and legal menus per language on staging. The language switcher must resolve translation pairs dynamically — hardcoded /de/ links break when slugs differ between locales. Test switcher on: homepage, a long interior page, a blog post, a CPT single, and a page that exists in only one language (should hide sibling or show graceful fallback per client policy).

Forms, cookies, and legal pages

• arrow_rightGravity Forms and Contact Form 7 — duplicate forms per language or use multilingual form plugins; notification emails must match locale.
• arrow_rightCookie consent banners — separate policy URLs per language; GDPR text must not be machine-translated without legal review.
• arrow_rightImprint, privacy policy, terms — exist and are linked in footer per locale.
• arrow_rightDate and number formats — locale-appropriate formatting in PHP templates, not hardcoded US formats.

Forms migration detail: Gravity Forms and CF7 guide.

Multilingual QA checklist

1. 1Every indexed URL in every locale returns 200 (crawl old sitemaps per language).
2. 2Hreflang pairs reciprocate — DE page lists EN alternate and EN lists DE.
3. 3Language switcher lands on correct translation, not homepage fallback.
4. 4Noindex flags consistent — do not noindex entire secondary locales by mistake.
5. 5Search Console hreflang report clean in each property or subdirectory view.
6. 6PDF and file downloads linked from translated pages resolve.
7. 7WooCommerce cart and checkout URLs correct per market if applicable.

Fold into migration QA checklist and post-launch monitoring — watch non-English 404 spikes separately in week one.

When to simplify the language setup

Rebuilds are the right moment to question three-locale setups that only ever had English content updated. If French and German versions are years stale, discuss with the client: machine-translate and human-edit, retire locales with 301 to English, or pause secondary languages until post-launch. Shipping broken hreflang hurts more than temporarily dropping a neglected locale. Document the decision in writing — 'German paused until Q3' prevents the client assuming all markets launched.

Worked example: B2B manufacturer, EN + DE + PL

A manufacturing company site has 120 pages across English, German, and Polish on WPML with subdirectory URLs. Forty case studies as a translated CPT. Rebuild on ACF block theme with SEOPress. Migration plan: export WPML translation groups to CSV; build ACF blocks and register case_study CPT with WPML translation enabled; crawl /en/, /de/, and /pl/ paths separately into block drafts (360 URL credits); WXR import remaining admin-only content; run WPML trid remapping script on staging; rebuild three menus; import 840 redirect rows (280 URLs × 3 locales with pagination); verify hreflang on 30 sample URLs per locale; submit three sitemap indexes. Timeline: multilingual adds roughly 40% to content migration and 100% to redirect QA vs a single-language rebuild of the same page count.

Multilingual rebuilds need the single-site guides too

Hreflang and translation pairs are additive — you still need redirect maps per locale, CPT migration for translated post types, and menu migration per language. SEO plugins: SEOPress, Yoast, or Rank Math — run per language.