How to Preserve Language and Regional URLs During a Migration

When a multilingual or multi-regional website changes its domain, platform, or URL paths, map each old language or regional page to its new destination. A language or regional version is also called a locale. For example, if a UK English page redirects to a US English page, users and search engines lose the direct link to the UK version.

During an international SEO migration, map each old URL to its closest equivalent. Then update the ways search engines find and connect the new language and regional pages, including redirects, hreflang annotations, canonical URLs, internal links, and sitemaps. hreflang is code that identifies alternate pages for different languages or regions. A canonical URL is the address a site marks as its preferred version of a page.

Map old URLs to the right locale

Start by listing each URL, the page’s language or region, and its intended destination. Include pages from every locale, not just those in the main site sitemap. When preparing a move, Google recommends checking several sources, including sitemaps, site crawls, analytics, Search Console data, and server logs.

For each old URL, decide whether the page has a direct replacement, will be merged into another page, or has been retired. A former UK English product page should redirect to its new UK English equivalent when one exists. A general homepage or default-language page is not a suitable catch-all destination for unrelated regional pages. Google warns that redirects to irrelevant destinations can confuse visitors and may be treated as soft 404s, pages that behave like errors despite returning a successful response.

Use the map to write redirect rules that account for each old page’s path and locale. A broad rule that sends every old page to one new language directory can return a successful status but still send visitors to the wrong version.

Redirect each page to its replacement

A permanent redirect, usually an HTTP 301 or 308 sent by the server, tells browsers and search engines that a page has moved. Google recommends permanent redirects when a URL has permanently changed. Where possible, send each old URL straight to its final destination. Avoid redirect chains, where a redirect sends visitors to another URL that redirects again.

Check where each redirect sends visitors, not just its status. Make sure the old regional page reaches the intended locale, loads successfully, and does not redirect again to an unrelated URL. Keep migration redirects in place for at least a year, as described in Google’s site-move guidance. Also update the links you control, including navigation, links in page content, and sitemap entries, to point straight to the new URLs.

Google says permanent redirects do not reduce PageRank, one of its ranking signals. Rankings, clicks, and indexing can still change during a move because Google needs to recrawl and process the new URLs.

Rebuild the language and regional signals

After launch, update every new page to refer to the final URLs. Each page in a group of language or regional alternatives should include an hreflang annotation for itself and the other relevant versions. The pages should link to one another, and each annotation should use a complete URL. Google can read hreflang from page code, HTTP headers, or XML sitemaps. Using all three does not improve Search results, according to its localized-page guidance.

A language code names the language. An optional region code names a country or market. For example, en-GB means English for the United Kingdom. Add a region code only when the page is intended for that regional audience. x-default can identify a fallback page, such as a language selector for visitors who do not match any listed version.

Set each new page’s canonical URL to the address the site prefers for that page. When regional pages serve different audiences, do not automatically point every version’s canonical URL to a global page. If two pages are duplicate copies and the site intends one to represent both, choose that URL deliberately. Keep the canonical, hreflang, internal links, and sitemap entries consistent. Google treats canonical annotations as signals, but it can choose a different canonical URL. Its canonicalization guidance explains how Google weighs those signals.

Make sure each page’s visible content matches its intended language and region. Google says it identifies a page’s language from its content, not from the URL, hreflang, or the HTML lang attribute. Separate URLs also help Google find each language version. If a site serves different content only through cookies or browser settings, Google can have a harder time finding those versions. See Google’s guidance on multilingual and multi-regional sites.

Check the full URL path after launch

Test some URLs from every locale, then crawl all the old and new URLs. Check that each old URL redirects to the right final destination. For each new URL, confirm that it loads. Check that search engines can crawl and index it, and verify its expected canonical URL and locale annotations.

Make sure each hreflang annotation points to a final URL and includes the page’s own URL. The other listed pages should link back to it. Check that internal links and sitemap entries use the new preferred URLs instead of relying on redirects. Remove any temporary noindex directive or crawl block that would keep the new pages out of search.

In Search Console, inspect examples of the new URLs and monitor sitemap processing, indexing, impressions, and clicks. Review results by language or region because sitewide totals can hide a problem with one locale. During a normal move, Google says old URLs gradually leave the index as new URLs appear. This takes time, and the pattern alone does not show whether every regional page points to the right destination.

Separate transition effects from migration errors

Google says a site’s visibility can change temporarily while it recrawls and reindexes the pages. For most pages, a small or medium move takes a few weeks or more; larger sites take longer. Google does not give a fixed crawl schedule or recovery deadline, so a temporary drop alone does not show what caused it.

First investigate errors that persist: old URLs returning 404 responses, redirects reaching the wrong locale, new URLs blocked from crawling, or canonical tags pointing to an old or unrelated page. Also check whether hreflang links still name old URLs or fail to link back. Google can ignore incomplete or inconsistent locale annotations. Conflicting signals can also make it harder for Google to choose your intended URL.

If a page has no real replacement, do not redirect it to an unrelated locale page just to avoid an error. Let the retired URL return an appropriate not-found response. This makes clear that the page was removed instead of sending visitors to an unrelated destination.

What the migration means for AI search

Google says its AI Overviews and AI Mode use the same foundational SEO requirements as Search. A page must be indexed and eligible to appear with a snippet to qualify as a supporting link; Google lists no special migration markup for these features in its AI search guidance.

Accurate redirects, crawlable new URLs, and consistent indexing signals therefore matter for AI-search eligibility. However, this does not show that preserving hreflang makes a page appear in an AI answer, or that a technically sound migration will earn an AI citation.

Key Takeaways

• Map every locale separately: Send each old language or regional URL to its closest equivalent, and identify pages that are being merged or retired.
• Redirect to the final page: Use permanent redirects for moved URLs and avoid sending unrelated pages to a homepage or default-language version.
• Update every locale signal: Replace old URLs in canonicals, hreflang, internal links, and sitemaps with the final destinations.
• Test what each URL does: Check redirect destination, response, crawl access, canonical choice, and reciprocal hreflang links for every locale.
• Judge the transition by evidence: Temporary visibility changes are expected, but persistent routing, indexing, or canonical errors need investigation.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com