What Is Site Migration?

Written byFlavio Amiel Founder, Roborank

Updated July 15, 2026

A site migration is any significant change to a website’s URLs, structure, hosting, protocol, or content platform that alters how search engines crawl, index, and rank it. Examples range from an HTTP-to-HTTPS switch to a full domain change or CMS replatform. Each type needs redirects and URL mapping to carry accumulated ranking signals from old addresses to new ones.

Key Takeaways

Google recommends server-side permanent redirects — 301 or 308 — from every old URL to its closest new equivalent, kept “for as long as possible, generally at least 1 year.”
URL-change migrations use Search Console’s Change of Address tool; a move from HTTP to HTTPS does not require it.
Google advises moving all URLs at once on small and medium sites, but moving one section at a time is acceptable for large sites so problems are easier to isolate.
A medium-sized site can take a few weeks for most pages to move, and the move happens on a per-URL basis rather than all at once.
Redirecting many unrelated old URLs to a single page such as the homepage is treated as a soft 404 and forfeits those pages’ ranking signals.

How Site Migration Works

A site migration changes the addresses or the environment your content lives in, and search engines have to relearn the map. The core mechanic is the redirect. When Google requests an old URL and receives a server-side permanent redirect — a 301 or 308 response — pointing to the new URL, it eventually transfers that page’s accumulated ranking signals to the new address. Google’s own guidance is explicit: use server-side permanent redirects “when possible,” avoid redirect chains longer than three hops, and keep the redirects live “for as long as possible, generally at least 1 year.”

The redirects only work if they are aimed correctly. That requires a complete mapping of every old URL to its closest new equivalent, built from your sitemaps, server logs, analytics, and link reports. Each new URL should carry a self-referencing canonical tag, and any multilingual annotations — hreflang — need updating to the new addresses. Internal links on the new site should point at the new URLs directly rather than hopping through redirects.

Then you tell Google. For a host or domain change you submit Search Console’s Change of Address tool and a fresh sitemap of the new URLs; you also remove any development-phase noindex rules or robots.txt blocks that were shielding the new site. The one exception Google names: an HTTP-to-HTTPS migration does not need the Change of Address tool. Finally you watch, because the move “takes place on a per-URL basis” and “a medium-sized website can take a few weeks for most pages to move.”

Types of Site Migration

“Site migration” is an umbrella covering several distinct events, each with its own risk profile:

Protocol migration (HTTP to HTTPS) — same domain, same paths, only the scheme changes. Lowest risk, and the only type that skips the Change of Address tool.
Domain migration — moving from one hostname to another (old.com to new.com), including www to non-www consolidation. Requires the Change of Address tool for every subdomain and variant.
URL structure change — the domain stays but paths change, often during an information-architecture overhaul. Demands the most careful old-to-new mapping.
Platform or CMS replatform — moving between content systems (for example WordPress to a headless setup). URLs often change as a side effect, so it becomes a URL migration too.
Consolidation — merging several sites into one, the highest-complexity case because it multiplies the mapping and redirect work.

Real migrations frequently combine types — a replatform that also changes the domain and the URL structure at once — which is why a single, authoritative URL map is the non-negotiable artifact.

Example of Site Migration

The largest well-documented public migration is the UK government’s consolidation into GOV.UK, reported by the Government Digital Service on December 19, 2014. Over roughly 15 months, GDS moved 312 agencies and government organisations onto a single site, closed 685 website domains and subdomains, and published more than 150,000 pages in their place.

The number that matters for anyone studying migrations is the redirect count: GDS put in place more than 1.8 million redirects from the old government websites, each pointing either to the corresponding GOV.UK page or to an archived copy on the National Archives. That is the discipline the mechanism demands, at scale — not a blanket redirect to the homepage, but a per-URL decision about where each retired address should now resolve. Pages that had a living equivalent were redirected to it; pages that were genuinely retired were redirected to an archive rather than dropped, so external links and bookmarks kept working instead of dying as 404s.

The lesson generalizes to a migration of any size. The GOV.UK team treated the mapping as the project, not an afterthought, because the redirect is only as good as its destination. Whether you are moving 150,000 pages or fifteen, the winning move is the same: enumerate every old URL, decide its true new equivalent, redirect it there permanently, and leave the redirects up long enough for search engines to finish carrying the signals across — which for Google means at least a year.

The thing people get wrong

The failure I see wreck more migrations than any other is the lazy redirect: pointing every retired URL at the homepage because a proper old-to-new mapping felt like too much work. Google treats that as a soft 404 and quietly drops the signals those pages earned over years. A redirect only transfers authority when it lands on a genuinely equivalent page — the old product page to the new product page, the old article to the new article. The second silent killer is treating launch day as the finish line. Rankings move per URL over weeks, so the redirects, the sitemaps, and the monitoring all have to survive well past go-live. Keep the redirects up at least a year, watch the old and new index counts cross over in Search Console, and do not touch anything until they settle.

Frequently Asked Questions

How long should redirects stay in place after a site migration?

Google recommends keeping migration redirects “for as long as possible, generally at least 1 year,” so it can transfer all ranking signals to the new URLs. Many teams keep them indefinitely, because visitors and external links still resolve through them long after the year is up.

Do I need the Change of Address tool for an HTTPS migration?

No. Google states that if you are moving from HTTP to HTTPS you do not need the Change of Address tool. That tool is for host or domain changes. An HTTP-to-HTTPS switch on the same domain is handled through redirects and canonical tags alone.

How long does a site migration take to reflect in Google?

A medium-sized site can take a few weeks for most pages to move, and larger sites take longer. The move happens on a per-URL basis, so pages transfer gradually rather than all at once — monitor the crossover in Search Console’s index coverage report.

Should I migrate my whole site at once or in sections?

Google advises moving all URLs simultaneously on small and medium sites, which speeds detection. Large sites can move one section at a time — ideally starting with infrequently changing content — because staged moves make monitoring and troubleshooting easier when something breaks.

The Bottom Line

A site migration is a controlled hand-off: you are moving a set of URLs and asking Google to carry each page’s earned authority to its new address. The mechanics are unglamorous — a complete old-to-new map, permanent redirects that land on true equivalents, updated sitemaps and internal links, and patient monitoring as pages cross over one by one. Skip the mapping or pull the redirects early and the rankings you spent years building leak away.

Sources

Site moves with URL changes — Google Search Central
300+ websites to just 1 in 15 months — Government Digital Service (Inside GOV.UK)

Roborank does this

Roborank watches your rankings and technical health across a migration — so a broken redirect or a traffic drop on the new URLs surfaces the day it happens, not the month after.

Monitor your migration →

Rank & Cash — the weekly SEO breakdown

One practical teardown a week on ranking in search and getting cited by AI. No fluff.