Migrating a site without handing your rankings to a competitor.

First, know what counts as a migration

More things than people expect. Any change to URLs, hosting, CMS, domain, HTTPS, site structure or rendering is a migration in SEO terms, because any of them can drop the signals Google has attached to your pages. A redesign that changes URL patterns is a migration. Merging two sites is a migration. Moving your docs from a subdomain to a subfolder is a migration. Replatforming a store, say onto Shopify, is one of the riskiest versions of all, because the URL patterns are decided by the platform rather than by you.

If you are not sure whether what you are planning counts, assume it does. The cheapest time to find out is before it ships, not from a traffic graph two weeks later.

Before the move

Capture the current state

You cannot prove a migration was clean if you did not record what clean looked like. Before anything changes, capture the full URL set, the pages that currently earn rankings and traffic, and a baseline of the content and structured data on the important pages. This is the reference you will check the new site against.

Build the redirect map from the full URL set, not a sample

Every old URL mapped to its closest new equivalent. The word that matters is every. Sampling is how you miss the long tail of pages that quietly earned links over the years, and those are exactly the ones with equity worth preserving.

• One to one wherever possible. Map each old URL to the single best new URL, not a blanket redirect to the homepage. A homepage redirect for a page that ranked is a signal thrown away.
• No chains. Old URL to new URL in one hop. A redirect that passes through two or three others dilutes the signal and slows the crawl.
• A rule for the orphans. Pages with no exact new equivalent need a deliberate decision: the closest relevant page, or a considered 410 if the content is genuinely gone. Not a shrug to the homepage.

At launch

Redirects, canonicals and internal links together

These three have to move as one. The redirects send old URLs to new. The canonicals on the new pages have to point at the new URLs, not carry over aimed at the old ones, which quietly tells Google the migration never happened. And the internal links, the navigation especially, have to point straight at the new URLs rather than hop through a redirect, because every internal link left pointing at an old URL becomes a small tax on crawl and on the signal reaching the page.

Confirm the staging controls are gone

The noindex tags, robots rules and password walls that protect a staging site are the ones that tank a launch when they survive it. A single noindex carried from staging to production can de-index a section overnight. Confirm they are gone before the switch, and confirm the new site is actually crawlable, rather than discovering it after the traffic has already dropped.

# the checks that catch the most common launch-day disasters
curl -s https://newsite.com/robots.txt                              # no stray Disallow: /
curl -sI https://newsite.com/ | grep -i 'x-robots-tag'              # no noindex header
curl -s https://newsite.com/key-page/ | grep -i 'noindex'          # no meta noindex in the HTML

Check content parity on the pages that ranked

A redesign that looks better often says less. The new template is cleaner, the copy got trimmed, and the ranking followed the words that were cut. Compare the important pages old against new: titles, headings, body content and structured data. The page that ranked needs to still say the thing it ranked for, which makes this an on-page problem wearing a migration costume.

After the move

This is the half everyone skips, and it is where the misses actually surface. A migration is not finished at launch. It is finished when the rankings have settled and you have confirmed nothing broke on the way.

• Watch Search Console. Submit the new sitemap, watch coverage for a spike in errors or excluded pages, and use the change of address tool if the domain changed.
• Watch the logs. The redirect that got missed shows up as 404s in the server log a week or two later, not on launch day. That lag is why "it looked fine at launch" is not the same as "it worked."
• Watch the rankings, and hold your nerve. Some movement while Google recrawls and reassigns signals is normal. A clean, same-content migration settles in days to weeks. If it does not recover, that is a signal to go back to the redirect map, not to panic-change things.

The launch-day checklist

• Full URL set captured, rankings and traffic baselined, content and schema recorded on the important pages.
• Redirect map built from every old URL, one to one, no chains, orphans decided deliberately.
• Canonicals on new pages point at new URLs.
• Internal links, navigation first, point at new URLs directly, not through redirects.
• Staging noindex, robots and password rules confirmed removed. New site confirmed crawlable.
• Content parity checked on every page that earned rankings.
• New sitemap submitted, change of address filed if the domain moved.
• Logs and Search Console watched through the settling window, misses fixed as they surface.

What this adds up to

A migration loses rankings when continuity breaks somewhere between the old site and the new one, and every break in that list is preventable with a plan and a check. The order is the point: capture before you move, move redirects canonicals and links as one, confirm the staging controls are gone, then watch the result rather than assume it. Treat the launch as the middle of the project, not the end of it, and the rankings survive the move.