What is SEO site migration?

SEO site migration is the set of technical steps that accompany a domain change, a platform rebuild or a URL restructuring, aimed at carrying an established ranking across so Google does not have to reassess every page from scratch. The core is the URL map: every old URL needs one precise new destination, never the homepage as a shortcut, connected by a permanent redirect (301 or 308) kept in place as long as possible: Google says generally at least a year, the time it needs to transfer all signals to the new URLs. Three tasks sit around that map and get skipped often: updating canonical and hreflang tags so they point at the new URLs, submitting the refreshed sitemap in Search Console, and using the change-of-address tool only when the domain or subdomain changes, not for a redesign on the same host.

See also: Topical authority · The idea that a site is recognized as competent across a whole semantic domain: a content architecture, not a metric.

What actually happens, step by step

Before anyone touches a line of code, the existing site needs a snapshot: which URLs carry organic traffic, which rank for important queries, which get links from other sites. That produces the one-to-one map, old URL to matching new URL, because Google's own documentation is explicit about it: a redirect has to land on the corresponding page, not a catch-all, and chains should stay under five hops, ideally under three. Every new URL carries its own self-referencing canonical tag, and on a bilingual site the hreflang attributes need rewriting to the new addresses. Structured data in JSON-LD moves along with everything else: a product or an FAQ that loses its markup in the transition comes back readable only as plain text to a generative engine. The new sitemap gets submitted in Search Console as soon as the migration begins: for weeks the coverage report will show mostly the old URLs indexed, which is the expected sequence, not a warning sign.

An enterprise example

An engineering firm with a hundred and twenty technical pages moves from a proprietary CMS to a modern one, also regrouping its folders by service instead of by publication date. The domain stays the same, so Search Console's change-of-address tool is not needed: the lever is entirely the redirect map and the internal links, which would otherwise keep pointing at paths that no longer exist. Before launch the team exports the full list of URLs indexed by Search Console and the old sitemap, cross-checks both lists so no low-traffic page with valuable external links gets forgotten, and tests the redirects in staging with the same tool it will later use to verify them in production. Bumping the publish date on the moved pages does nothing if the content itself has not changed: this is about technical continuity, not content freshness, a different signal.

Why it matters for decision makers

A badly run migration is one of the few site changes whose cost shows up immediately, in organic traffic lost, often built up over years. The right question for whoever proposes the rebuild is not "how much does it cost" but "where is the URL-by-URL redirect map, before anyone touches the server": a vague answer means real risk. Worth keeping separate too: this is about not losing what already exists, while whether and why to redesign a site in the first place is a different question. The structure that survives a migration, with the same URL hierarchy and the same internal links, is also what holds up the topical coverage built over time: breaking it in a rush means starting over.