# How do I migrate a multilingual WordPress site without losing rankings?

> Migrate a multilingual site by treating every language version of every page as its own URL: crawl them all, map each to its new URL with a 301, and preserve the hreflang links that tie the translations together. The common failure is redirecting the default language and forgetting the others, which drops whole locales. WPBuildAI crawls every language version, maps all the redirects, and keeps the hreflang structure, so each locale keeps its rankings.

Source: https://wpbuildai.com/how-to-migrate-multilingual-wordpress-site-wpml-safe/
By lawrence-arya · 2026-06-24

---
Migrating a multilingual WordPress site safely comes down to one shift in thinking: every language version of every page is its own URL, with its own rankings, and all of them have to move. Crawl them all, map each to its new URL with a 301, and preserve the hreflang links that tie the translations together. The failure that sinks these migrations is redirecting the default language carefully and treating the other locales as an afterthought, which drops whole languages overnight. WPBuildAI crawls every language version, maps all the redirects, and keeps the hreflang structure intact, so each locale keeps its rankings.

## Why multilingual migrations are different

The math is the problem. A site in five languages has roughly five times the URLs of a single-language site, and a hand-built redirect list almost always covers the default language well and the rest poorly, because the default is what the team thinks in and sees first. Ahrefs found in its [search traffic study](https://ahrefs.com/blog/search-traffic-study/) that a small share of pages carries most traffic, and on a multilingual site those high-value pages are spread across every locale, so the ones you miss are often the ones that mattered in a market you were not watching closely. A full crawl that captures every language version is the only reliable way to map them all, which is why the [URL mapping template](/website-url-mapping-template-excel-automated/) has to include the locale as a dimension, not just the page. A single-language migration mindset applied to a multilingual site is precisely what drops languages.

## The URL math: every language is its own page

It is worth being concrete about why the count multiplies. To a search engine, the English version of a page and its German translation are two distinct URLs with two distinct sets of rankings, backlinks, and impressions, even though they are "the same page" to you. The German version ranks in German results for German queries entirely independently. So a 200-page site in five languages is, for migration purposes, 1,000 pages, each of which can rank, each of which needs a redirect, and each of which can be lost. There is no "migrate the page and the translations follow" shortcut, because the translations are not attached to the original in any way a redirect inherits; they are siblings, each standing on its own URL. Internalising that every language version is a separate, independently-ranking page is what makes the scale of the job, and the completeness it demands, obvious.

## Hreflang is part of the cargo

Redirects move the URLs; hreflang is the second piece of cargo that ties the translations together, and it is just as losable. Hreflang tags tell search engines which URL serves which language and region, so the right version reaches the right user and the translations are not treated as duplicate content competing with each other. Google's guidance on [localized versions of your pages](https://developers.google.com/search/docs/specialty/international/localized-versions) describes how these annotations link the set, and the 2024 [Web Almanac](https://almanac.httparchive.org/en/2024/) documents how widely hreflang is deployed and how easily it breaks. A migration that drops or mangles hreflang can cause engines to show the wrong language to users or merge versions they should keep separate, costing rankings even when the redirects are perfect. So carrying the hreflang structure across, regenerating it on the new site so every translation set still points at its members, is as important as the 301s, not an optional extra.

## A worked example: a five-language site

Picture a WPML site with 200 pages in English, German, French, Spanish, and Italian, 1,000 URLs in total. The team migrates by exporting and redirecting the English pages carefully, assuming the translations are "part of" each page. At launch, English holds its rankings and the other four languages collapse: their old URLs 404, because they were never in the redirect map, and the hreflang links are gone, so the few translated pages that survive are treated as duplicates. German, French, Spanish, and Italian traffic vanishes overnight. The correct version crawls all 1,000 URLs, maps each to its new address with a 301, and regenerates the hreflang set so every translation still links to its siblings. Done that way, all five languages hold their rankings. The difference was entirely whether the migration treated the 800 non-English URLs as real, independently-ranking pages or as invisible appendages of the English ones.

## How WPML structures URLs

Knowing how WPML lays out language URLs tells you what to preserve. WPML typically uses one of three patterns: a language directory (`/de/page/`, the most common), a language subdomain (`de.example.com/page/`), or a URL parameter (`?lang=de`). Whichever your site uses, that pattern is part of every non-default URL and must be reproduced or deliberately mapped on the new site. If the new platform organises languages differently, every locale's URLs change, multiplying the redirect work, so the safest move is to keep the same pattern where possible: if you were on `/de/`, stay on `/de/`. The crawl captures the actual pattern in use, so you map from real URLs rather than assumptions. Getting the pattern right matters because a mismatch, say, moving from `/de/` to a subdomain, changes every German URL at once, turning what could have been a no-op into a thousand-redirect job with a thousand chances to miss one.

## Keep the structure, 301 the rest

The guiding principle is to keep each language's URL pattern as close to the original as possible, the language path or subdomain, the slugs, and the hreflang links, so most URLs are unchanged and only the platform differs. Every URL you keep identical across all languages is one you do not have to redirect and that needs no re-indexing, which is the safest possible outcome at multilingual scale. Where a URL must change, 301 it, following Google's [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) and the discipline in [setting up 301 redirects](/set-up-301-redirects-moving-wordpress-to-ai-website-builder/). Apply this per locale: confirm the German URLs are preserved or redirected as thoroughly as the English ones, then French, and so on. Missed locales show up as the kind of drop described in [why traffic falls after a redesign](/fix-seo-drop-after-website-redesign/), except concentrated in one language, which is easy to miss if you only monitor your home market.

## Verifying every locale after launch

Verification has to be per-language, because a check that only looks at the default locale will pass while another language quietly 404s. After launch, crawl the full multilingual URL set, all 1,000 in the example, and confirm each returns a single 301 to the correct translated destination, with no language's URLs falling through. Check that the hreflang annotations render on the new pages and point at the right siblings, since broken hreflang is invisible to a casual look but visible to search engines. In Search Console, segment by country and language where you can, and watch each market's coverage and performance, not just the aggregate, because a collapsed locale can hide inside a healthy-looking total if the default language dominates. Verifying every locale is what turns "the migration looks fine" into "every language provably kept its URLs and hreflang," which is the only check that catches a dropped language before its market notices.

## Common mistakes in multilingual migrations

The recurring errors all come from a single-language mindset. Redirecting the default language and assuming the translations follow drops every other locale, because translations are independent URLs, not appendages. Building the redirect list by hand misses the secondary languages, which a full crawl would have caught. Forgetting to regenerate hreflang leaves translations competing as duplicates. Changing the language URL pattern, from `/de/` to a subdomain, multiplies the redirect work and the risk. And verifying only the home market lets a collapsed locale go unnoticed for weeks. Each is avoided by treating every language version as a first-class, independently-ranking page: crawl all of them, map and redirect each, preserve the URL pattern and the hreflang, and verify per locale, which is the discipline that keeps a multilingual move from quietly losing whole markets. It belongs on the [migration SEO checklist](/blog/wordpress-migration-seo-checklist/) with the locale dimension made explicit.

## Key points to remember

Migrate a multilingual WordPress site by treating every language version of every page as its own URL with its own rankings, because the URL count multiplies by the number of languages and a default-language mindset drops the rest. Crawl all of them so the secondary locales are not missed, map each to its new URL with a 301, keep each language's URL pattern as close to the original as possible, and regenerate the hreflang annotations so translations stay linked rather than competing as duplicates. Verify per locale after launch, crawling the full multilingual URL set and segmenting Search Console by market, since a collapsed language hides inside a healthy total. WPBuildAI crawls every language version, maps all the per-locale redirects, and keeps the hreflang structure, so a multilingual move holds every language's rankings; send your site URL for a fixed quote.

Not affiliated with WordPress, WPML, or Lovable.