Site and Domain Migrations

A migration is the highest-risk routine move in technical SEO. Done right, you keep your rankings and nobody notices. Done wrong, you drop traffic overnight and spend months clawing it back. The difference is almost entirely in the redirect map: whether every old URL lands on its true replacement.

What counts as a migration

A migration is any change to the URLs Google has indexed. That covers more than a new domain. It includes a URL restructure (new folder scheme or slug pattern), a domain change (moving to a new hostname), a protocol change (HTTP to HTTPS), and a platform change (a new CMS or framework that alters URLs). Each one asks Google to move the strength attached to old addresses onto new ones, and each one carries the same core risk if the mapping is wrong.

The reason a protocol change belongs here is that HTTP and HTTPS versions are different URLs to Google. Even that "small" move is a migration and needs the same redirect discipline as swapping domains.

What makes migrations dangerous is that the risk is invisible until the crawl catches up. You flip the switch, the new site looks perfect in a browser, and traffic seems fine for a few days because Google is still serving the old index. Then it recrawls, finds the redirects, and the quality of your mapping decides whether rankings hold or collapse. By the time the damage shows in Search Console, the mistake is weeks old. That lag is exactly why the work is front-loaded into planning: you cannot fix a bad map reactively without another painful recrawl cycle.

Plan the URL map

The plan is a full old-to-new URL map: a list pairing every indexed old URL with its true equivalent on the new site. "True equivalent" is the load-bearing phrase. Each old URL maps to the page that replaces it, the product to the product, the article to the article, the category to the category.

The classic failure is redirecting everything to the homepage to "not lose anyone." Google reads a redirect from a specific page to a generic homepage as a soft 404, because the destination does not match what the old URL was about. So those redirects consolidate nothing, and the strength you meant to carry over evaporates. If a page has no real equivalent, decide deliberately: redirect it to the closest relevant page, or let it return a clean 404. Do not sweep it to the homepage.

Every old URL maps to its true equivalent, not the homepage. A page-to-homepage redirect reads as a soft 404 and carries nothing over, which is how migrations quietly lose their rankings.

Execute the redirects

Redirect each old URL with a single 301 or 308 to its destination, in one hop, landing on a page that returns 200. One hop matters: if the old URL redirects to a URL that itself redirects, you have a chain, and chains dilute signal and slow every request. Crawl the full old list following redirects with a tool like Screaming Frog or Sitebulb, and confirm each one resolves in a single step to a live page. Redirect codes →

Then fix the surrounding signals so they all describe the new site. Repair any redirect endpoints that return 4xx or 5xx. Collapse chains and loops. Keep canonicals, hreflang annotations, internal links, and sitemaps consistent with the new URLs, because a migration that redirects correctly but leaves canonicals pointing at the old domain sends Google a contradiction. Canonical and HTTPS consolidation → Above all, preserve the URLs other sites link to; those backlinks are the strength you are trying to keep, and a broken redirect on a linked-to page throws it away. Preserving backlinked URLs →

Monitor after the move

Keep the redirects live for at least a year, and in practice indefinitely, because Google recrawls old URLs on its own slow schedule and external links keep sending real people through them. Tearing redirects down early is how you lose the consolidation you set up.

Watch both Search Console properties, the old one and the new one, through the transition. Expect a temporary dip. Rankings usually wobble for a stretch as Google recrawls, re-renders, and re-selects canonicals across the whole site, and that takes many passes rather than one clean switch. A dip that recovers is normal; a dip that keeps deepening means the map has holes. Compare crawled URLs, indexed counts, and top pages across both properties, and chase any old URL that is not resolving cleanly to its new home. Submit fresh sitemaps of the new URLs to speed discovery, and keep the old sitemap available long enough for Google to process the redirects rather than pulling it on day one.

A protocol migration to HTTPS is also a security and infrastructure decision, and infrastructure is the substrate under every signal here. That is the next chapter. HTTPS and infrastructure next →