400+ URLs across 3 languages. One controlled migration.
I led the SEO migration workflow for a multilingual B2B website rebuilt on a new WordPress architecture — from URL mapping and redirect logic to indexation controls and post-launch production QA.
The goal was not simply to move content, but to preserve valuable URLs, retire legacy inventory cleanly and prevent the rebuild from creating new SEO debt.
A website rebuild was not the migration plan.
The new site had to reconcile hundreds of legacy URLs, existing redirects, historical search paths and three language versions before the domain switch. Every old URL needed an explicit migration decision.
The old site, rebuilt site and historical URL footprint did not share one migration policy by default.
Old and rebuilt crawls, existing redirect rules and historical URLs were reconciled before assigning the final migration action.
Final URLs that remained valid and indexable
PreserveLegacy URLs with a relevant final destination
MapObsolete URLs without a meaningful replacement
RemoveEN, RU and UK paths validated across the migration
ValidateAn old URL was not redirected simply because it existed. Final treatment depended on destination relevance, historical state, language mapping and the intended indexation policy.
Four controls kept the rebuild from becoming an SEO reset.
URL decisions, multilingual signals, indexation rules and production QA were managed as one migration system rather than as separate technical tasks.
URLs reviewed across migration and technical QA
EN, RU and UK versions validated through the migration
Remaining after production internal-link cleanup
Deployment was only one checkpoint.
The migration had to preserve useful search signals while preventing legacy issues from being carried into the rebuilt site.
- × Map before launch. Every meaningful legacy path needed a final keep, merge, redirect or retirement decision.
- × Keep language signals aligned. Redirects, hreflang and internal links had to describe the same EN / RU / UK architecture.
- × Verify actual indexability. CMS settings alone were not accepted as proof of production robots and indexing behavior.
- × Re-crawl production. Internal redirects, broken paths and implementation errors were checked again after deployment.
URL architecture was decision-based
Old and rebuilt crawls, existing redirects and historical search URLs were reconciled before assigning a final treatment to each legacy path.
Language migration stayed connected
The move from legacy /ua/ paths to /uk/ was handled together with hreflang relationships and cross-language internal links.
SEO settings required live verification
Sitemap, robots, canonical and meta robots were checked on production. A results section still exposed indexable filter URLs and was corrected after launch.
Production signals were cleaned after launch
Internal 301s, 404/410 links, tool links and incorrect language references were corrected, while production was checked for residual staging URLs.
The launch exposed issues staging could not fully prove.
Production was re-checked after deployment to verify that redirects, indexation rules, internal links and language signals behaved as planned.
Production URLs still returned index/follow despite the intended policy. A dedicated noindex/nofollow rule was applied and verified.
Internal references were updated to point directly to final 200 URLs, while legitimate legacy redirects remained in place.
Broken internal references were removed or replaced with valid production destinations.
Incorrect language destinations and residual legacy language paths were corrected after deployment.
No staging-domain references were found in the production content or checked SEO elements.
Staging validates readiness. Production validates reality. The migration was re-checked after launch before being treated as complete.
The migration was closed only after production matched the plan.
Deployment itself was not the finish line. The final acceptance combined URL behavior, indexation, multilingual signals and production hygiene into one post-launch validation layer.
Redirect targets and retired paths followed the final migration map without critical chains or invalid destinations.
Production indexation rules were checked directly and incorrect indexable sections were corrected.
Legacy language paths, internal language links and hreflang relationships were aligned with the final architecture.
Internal links through unnecessary 301s and links to retired 404/410 destinations were removed or replaced.
No staging-domain references remained in the checked production content, links or SEO elements.
The deliverable was not just a redirect spreadsheet. It was a controlled migration process connecting legacy inventory, deployment decisions and final production acceptance.
Questions Behind the Migration Decisions
Practical details behind the URL, redirect and production QA decisions.
Why not redirect every removed URL?
A 301 was used only when the legacy URL had a genuinely relevant destination in the new architecture. When no equivalent existed, retiring the URL was preferable to redirecting old signals into an unrelated page.
Why include historical URLs from Google Search Console?
A current crawl does not show the complete historical search footprint. GSC data helped surface legacy 301 and 404 URLs that still needed an explicit migration decision even when they were no longer linked from the live site.
Why were existing redirects reviewed instead of copied?
Legacy redirect rules could contain outdated destinations, chains or URLs that were also being retired. They were reconciled with the final URL map before deployment rather than transferred into the rebuilt site automatically.
When is an SEO migration actually complete?
Not when the new site goes live. Production still needs to be validated for redirect behavior, indexability, internal links, multilingual signals, sitemap and robots rules. The migration was treated as complete only after those production checks matched the intended architecture.