How to Plan a 300+ URL Multilingual SEO Migration Without Losing Control

Website migrations rarely fail because a team forgot that redirects exist. They fail because the team never created a complete model of what is changing.

A mature multilingual site may contain current URLs, historical URLs, subdomains, old domains, parameter variants, PDFs, images, translated pages, orphan pages and links that still receive traffic even though nobody remembers creating them. When design, framework, domain and language structure change together, a simple spreadsheet of “old page → new page” is not enough.

This article describes an anonymized pre-launch planning case for a B2B manufacturer. The combined live and historical inventory was expected to exceed 300 candidate URLs once all properties and languages were merged. The project included an established country-domain site, a planned global domain, separate language properties and incomplete analytics access.

Disclosure: This is a planning case study, not a before-and-after performance story. The migration had not launched at the time of writing. No ranking, traffic or revenue result is claimed. The value demonstrated here is risk control, evidence quality and release design.

The situation

The business wanted to consolidate a fragmented international presence into a clearer global architecture. The legacy setup had several risk factors:

• a mature local domain with existing search equity;
• more than one public domain or language property;
• historical URLs that were not represented in the current navigation;
• languages distributed across different hosts;
• limited Search Console access outside the main property;
• no dependable GA4 baseline;
• product, category, sector and technical-content overlap;
• management pressure to simplify the website without losing discoverability.

The visible website was only part of the migration surface. The true project was the union of everything search engines, users and external links might still request.

Why “crawl the current site and redirect it” was insufficient

A current crawl answers: What can a crawler reach today? It does not fully answer:

• Which historical URLs still have links or impressions?
• Which pages are orphaned?
• Which URLs were removed from navigation but remain indexed?
• Which PDFs or images attract discovery?
• Which language page is the true equivalent of another?
• Which duplicate should consolidate and which intent deserves a new page?
• Which pages never should have existed as independent URLs?

Migration planning therefore began with evidence sources, not the new menu.

Stage 1: Build a forensic URL inventory

We defined one master matrix. Each row represented an existing, historical or proposed URL—not merely a navigation item.

Evidence sources

• full crawl of every accessible host;
• XML sitemaps and sitemap indexes;
• Search Console pages and performance exports for accessible properties;
• analytics exports where reliable access existed;
• backlink and referring-page exports;
• server/CDN logs when available;
• historical web archives;
• CMS/database exports;
• internal documents listing product models, sectors and languages;
• manual findings from navigation, footer, search and filtered routes.

Essential fields

The matrix was a control system, not a reporting decoration. Any URL without a decision remained an explicit risk.

Stage 2: Decide architecture before writing redirects

Redirects cannot compensate for a confused destination architecture. We first separated four concepts that had been mixed together:

1. Product/category: what the company offers.
2. Model/attribute: a product distinction that may or may not deserve a landing page.
3. Sector/use case: where and why the solution is used.
4. Language/market: who the content is for and in which locale.

The destination model favored stable language subdirectories on a global domain, with each locale owning self-contained URLs. This approach makes governance, analytics, internal linking and language relationships easier than scattering equivalent content across unrelated hosts.

That does not mean subdirectories are always correct. The decision depends on brand, legal entity, operations, market independence and existing equity. The important part is to document the trade-off and apply it consistently.

Stage 3: Create page-level intent rules

Mapping solely by page title causes subtle mistakes. Two URLs may look similar while serving different search intent.

Each source URL was classified:

• Keep: the intent and content remain valid.
• Improve: the URL survives but requires stronger content or structure.
• Merge: several pages serve the same intent and consolidate into one stronger destination.
• Redirect: the old location moves to a true equivalent.
• Remove with 404/410: no replacement exists and keeping it would mislead users.
• Investigate: evidence is incomplete or stakeholders disagree.

We rejected the common shortcut of redirecting every retired URL to the homepage. A redirect should lead to the closest useful equivalent. If none exists, a truthful 404 or 410 can be better than a misleading soft 404.

Stage 4: Build the redirect matrix

For every moving URL, the matrix required:

• exact source URL;
• exact destination URL;
• one permanent redirect hop;
• reason for the mapping;
• content-equivalence check;
• owner;
• implementation status;
• pre-launch test;
• post-launch test.

Redirect quality rules

• no chains;
• no loops;
• no mass homepage redirects;
• preserve meaningful deep destinations;
• normalize protocol, hostname and trailing-slash behavior;
• update internal links rather than relying on redirects internally;
• retain redirects long enough for users, crawlers and external links;
• test parameter behavior explicitly.

Google recommends permanent server-side redirects for permanent URL changes and warns that site moves can cause temporary ranking fluctuations while URLs are recrawled and reindexed.

Stage 5: Design canonical and hreflang together

Multilingual migrations often fail because canonical and hreflang send contradictory signals.

The rule set was simple:

• each English page canonicalizes to its English URL;
• each Turkish page canonicalizes to its Turkish URL;
• each pair references the other with reciprocal hreflang;
• x-default points to the intended default/global version;
• hreflang references final 200 canonical URLs, never redirects or errors;
• pages without true equivalents do not receive invented pairs;
• sitemaps and internal links use the same canonical destinations.

Canonical says which URL is preferred among duplicates. Hreflang helps select the right localized version. They solve different problems and must agree.

Stage 6: Separate migration scope from content ambition

One of the highest-risk decisions in a migration is changing everything at once.

The project separated:

• must-have migration parity: essential content and functions required to replace the old site safely;
• launch improvements: fixes necessary to prevent known technical or content defects;
• post-launch growth: new landing pages, large content expansions and experimental features.

This reduced the number of moving variables. A site can change domain, design, CMS, taxonomy, copy and language structure at once—but diagnosing a loss becomes much harder.

Stage 7: Define release gates

The migration could not launch because “the homepage looked finished.” It needed measurable gates.

Pre-launch crawl gate

• all intended public URLs return the expected status;
• no production page contains noindex unintentionally;
• canonicals use the production origin;
• hreflang is reciprocal;
• titles, descriptions and H1s are localized;
• sitemap contains only canonical indexable URLs;
• robots references the sitemap and does not block required content;
• structured data is valid and factual;
• internal links point directly to final URLs;
• old-to-new redirects pass automatically;
• mobile and performance checks meet agreed thresholds.

Launch gate

• DNS/CDN/SSL and origin health verified;
• redirect rules deployed with rollback available;
• forms and critical conversions tested;
• monitoring and error logging active;
• Search Console ownership ready for relevant properties;
• release annotation and contact owners recorded.

Post-launch gate

• crawl old and new URL sets;
• inspect representative pages;
• submit sitemap;
• monitor 404, 5xx, indexing, canonical selection and hreflang;
• compare non-brand impressions and landing pages;
• verify conversions, not only sessions;
• check external links still reach relevant destinations.

What we deliberately did not claim

This kind of work is often marketed with a traffic chart before enough time has passed—or before the migration exists. We did not claim:

• zero ranking fluctuation;
• guaranteed preservation of every position;
• immediate transfer of all signals;
• results from inaccessible analytics;
• successful international growth before launch;
• that a spreadsheet alone protects a migration.

Good planning reduces avoidable risk. It cannot control every search-system response.

Lessons that apply beyond 300 URLs

Inventory is more important than page count

A 50-URL site with three old domains and poor evidence may be riskier than a clean 5,000-URL platform.

Language equivalence is a content decision

Hreflang cannot decide that two vaguely related pages are translations. Editors and subject experts must confirm equivalence.

The matrix needs owners

An unassigned redirect, translation or validation is not a plan; it is a note.

“No data” is a risk state

When analytics or Search Console access is missing, document the limitation and use multiple alternative sources. Never replace missing evidence with confidence.

Validation must use the same URL set

The pre-launch inventory becomes the post-launch test suite. That continuity is what turns research into control.

Frequently asked questions

Should a multilingual site use subdirectories, subdomains or country domains?

There is no universal answer. Subdirectories often simplify shared authority and governance. Subdomains can support operational separation. Country domains send strong geographic signals but require independent management. Existing equity, market independence, legal structure and resources should drive the choice.

How long should redirects remain active?

Keep permanent redirects for as long as users, search engines or external links may request the old URLs. In practice, long-term retention is safer than removing them soon after the move.

Should every old URL redirect somewhere?

No. Redirect only when a relevant replacement exists. Removed content with no equivalent should return an honest 404 or 410 and offer useful navigation.

Can a migration launch without analytics?

It can, but the measurement risk is serious. Establish Search Console, conversion tracking and a reliable baseline before launch whenever possible. If access is missing, record the limitation rather than claiming performance continuity.

Does hreflang prevent duplicate content?

Hreflang helps search engines select localized versions. It does not replace good canonicals, distinct localization, crawlable links or consistent architecture.

Migration confidence comes from traceability

The strongest migration plan lets a reviewer start with any old URL and answer: What was it? Did it have evidence? What decision was made? Where will it go? Who owns the change? How will we test it? What happened after launch?

If your migration includes multiple languages, domains, frameworks or hundreds of historical URLs, request a migration risk review before the new structure is locked. The cheapest redirect to fix is the one caught before deployment.

Sources

• Google Search: Site moves with URL changes
• Google Search: Redirects and Search
• Google Search: Managing multilingual and multi-regional sites
• Google Search: Localized versions and hreflang
• Google Search: Canonicalization
• Google Search: Debugging traffic drops