International Site Migration: How to Keep Multilingual Rankings When You Change URL Structure
International site migrations—moving from subdomains to subdirectories, or restructuring URLs sitewide—most commonly fail in two places: 301 mapping that isn’t done language-by-language, and hreflang sets that get new URLs but never get reconnected. Miss either one and multilingual pages typically lose rankings within 2–8 weeks. The fix is a per-language URL mapping table, a phased cutover, and daily GSC monitoring—not a single big-bang launch.
Why is international migration risk so much higher than a single-language site?
A single-language migration only needs one 301 list. An international site has to handle N languages × each language’s own URL structure at the same time, and a 301 or hreflang error in any one language version can drag down the others—because an hreflang set is a group of mutually referencing tags, and Google’s own documentation notes that if even one URL in the set is broken or stale, the whole set can be judged invalid and get ignored. In a real case we’ve seen: a trilingual site (Traditional Chinese / Simplified Chinese / English) mapped only the English 301s during migration, left the two Chinese versions on the old URL structure for two weeks, and combined organic traffic across all three languages dropped 34% by week 3 post-migration—recovery only began at week 7, after the missing mapping was patched in.
How do you build a per-language URL mapping table?
Don’t rely on rule-based mapping (a single regex applied sitewide). Build a page-by-page, language-by-language mapping table with at minimum these columns:
| Field | Description | Example |
|---|---|---|
| Old URL | Full URL before migration | zh.example.com/products/shoes |
| New URL | Full URL after migration | example.com/en/products/shoes/ |
| Language code | Corresponding hreflang value | en |
| 301 status | Configured and tested? | Pending / Tested |
| hreflang updated | Is the new URL in the new hreflang set? | Yes / No |
| Content consistent | Was content accidentally altered in transit? | Yes / No |
Manage this in a spreadsheet. Before migrating, run a full-site crawl (e.g., Screaming Frog) to export every existing URL across all language versions, then map each one to its new URL individually—missing even one entry can create an orphan page.
Phased cutover vs. a single big-bang launch: what’s the difference?
The biggest risk of a single big-bang cutover is that if there’s a systemic error in one language’s 301s or hreflang, the whole site is affected at once and it’s hard to isolate which layer broke. Recommended phased order:
- Batch 1 (week 1): Launch the 1–2 lowest-traffic language versions first to validate 301 mapping, hreflang return links, and canonical correctness.
- Batch 2 (weeks 2–3): Once Batch 1’s GSC indexing and rankings look normal, cut over secondary-market languages.
- Batch 3 (from week 4): Cut over the highest-traffic language last (usually your primary market’s language)—by now the mapping process has been validated twice, so risk is lowest.
- Wind-down (weeks 5–8): Keep old-URL 301s live for at least 6 months, and check the GSC Page Indexing report weekly to confirm new URLs are progressively replacing old ones.
GSC monitoring checklist during migration
- Daily: Check whether “Crawled – currently not indexed” and “Duplicate, Google chose different canonical than user” counts in the Page Indexing report are climbing—both are early signals that 301s or canonicals aren’t matching up.
- Every 3 days: Spot-check 5–10 new URLs with the URL Inspection tool to confirm the canonical and hreflang Google is reading match what you intended.
- Weekly: Compare week-over-week impression changes in the Performance report for each language; flag any language version whose impressions drop more than 20% in a single week.
- Weeks 4, 8, and 12 post-migration: Run a full-site hreflang scan (paired return links, no orphaned tags) to confirm no new breakage has crept in over time.
FAQ
Q1: How long does it take for rankings to stabilize after an international site migration? If 301s and hreflang are mapped correctly, most language versions return to pre-migration levels within 2–6 weeks; if a gap is found mid-migration and fixed, stabilization is typically delayed another 2–4 weeks.
Q2: Can I use a single regex rule for 301 mapping? For a small single-language site, yes. For an international site, no—different language versions’ URL structures and legacy URL patterns are rarely fully symmetric, so rule-based mapping tends to miss exception pages; a per-language list is more work but far more controllable.
Q3: How long should old-URL 301s stay live? At least 6 months, and 12+ months for language markets with heavy external backlinks or slow crawl/indexing behavior—wait until both external links and crawler behavior have visibly shifted to the new URLs before considering removal.
Q4: Can I change URL structure and redesign content at the same time? Not recommended. Changing URL structure and content simultaneously makes it nearly impossible to attribute a ranking drop to either cause. Do a pure URL migration first, watch it stabilize for 2–4 weeks, then plan the content redesign separately.
The step teams most often skip mid-migration is confirming the hreflang set was actually reconnected to the new URLs—GeoSeoToday’s hreflang generator and GEO checker scans all language tags before and after cutover to confirm they still reference each other correctly. If you’re not yet confident on the fundamentals, start with 7 hreflang Mistakes That Cause Duplicate-Language Self-Cannibalization before planning your migration timeline.