Site Migration SEO Checklist: Change Domain, Platform, or URLs Without Losing Rankings

Migrations are the highest-risk routine project in SEO. Nothing else can delete a site's earned visibility in one deployment, and nothing else fails so quietly — the site looks fine, the pages load, and weeks pass before anyone notices the traffic never came back.

The mechanism behind almost every ranking loss in a migration is the same: search engines have to re-discover your content at new addresses and transfer what they knew about the old ones. Everything on this checklist exists to make that transfer unambiguous — one old URL, one new URL, one hop, one clear signal. Ambiguity is what costs rankings, not change itself.

It applies to all four migration types, in rising order of risk: URL structure changes, replatforming, domain changes, and consolidations or splits. The last is riskiest because URLs stop mapping one-to-one — and one-to-one is what makes the transfer clean.

Phase 1 — Before you touch anything: inventory and baselines

You cannot verify a migration succeeded if you never recorded what "before" looked like. Do this while the old site is still live and healthy.

• Crawl the current site and export every indexable URL with its status code, title, and canonical — the source of truth for your mapping sheet.
• Export ranking URLs from Search Console, by page and by query. Pages that earn impressions matter even if your crawl thinks they're minor.
• Export top landing pages from analytics over a full year, so seasonal pages aren't missed.
• Export backlink data and note which pages hold external links. These are where a broken redirect is most expensive.
• Record a ranking baseline for your priority keywords — position by keyword, location, and device, taken shortly before launch. Without it, every post-launch wobble is unreadable.
• Note the current indexed page count and existing coverage issues, so you don't blame the migration for a problem that predates it.

Keep it all in one place. During the panic phase after launch, the sheet you built calmly is what settles arguments.

Phase 2 — URL mapping: the document the whole project depends on

The mapping sheet is one row per old URL with the new URL it becomes. Rules that keep it honest:

• Every old indexable URL gets a destination. No blanks. If a page has no equivalent, decide deliberately: map it to the closest relevant page, or let it return 410/404. "Closest relevant" means the same topic and intent — not the homepage.
• Do not blanket-redirect everything to the homepage. Search engines commonly treat mass redirects to an irrelevant destination as soft 404s, so the signal you hoped to transfer never arrives.
• Keep it one-to-one wherever you can. Many-to-one consolidation is sometimes right, but each merge should be a decision you can justify.
• Include the non-obvious URLs: paginated series, indexed faceted URLs, tag and category archives, image and PDF assets that earn links, and old campaign URLs that still get hit.
• Preserve URL patterns you don't have to change. The cheapest migration risk is the one you skip.

Migrations expose a shaky technical foundation all at once — if crawlability and indexing are fuzzy concepts on your team, read the technical SEO guide first, because every phase here assumes those basics are in place.

Phase 3 — Redirects and signals

301, not 302. A permanent redirect says "this moved for good." Temporary redirects tell search engines to keep the old URL — the opposite of your intent.

Kill the chains. A redirect landing on another redirect wastes crawl effort and dilutes the signal. Every old URL should reach its destination in one hop. Chains usually appear when a new migration is layered over an old one, so check existing rules for legacy entries and rewrite them to the new final URL. Protocol and host normalization (HTTP→HTTPS, www, trailing slashes) each add a hop too if applied after your migration rule.

Canonicals must point at the new self. Every new page's canonical should reference its own new URL; one still pointing at the old domain is a common and quietly fatal error. In a multi-language setup, hreflang annotations must move to the new URLs on every language version simultaneously — half-migrated clusters break reciprocity and get ignored.

Fix internal links at the source. Redirects are a safety net for external traffic, not your navigation. Update menus, in-content links, breadcrumbs, and structured data to the new URLs directly.

Sitemaps and robots. Publish a new XML sitemap containing only new, canonical, indexable URLs, and ship a robots.txt that matches production intent. Some teams temporarily keep a sitemap of old URLs so crawlers rediscover them and pick up the redirects sooner — reasonable, but remove it once processed.

The staging noindex trap. The most common catastrophic migration bug: a site-wide noindex (or Disallow: /) applied to protect staging, then shipped to production. Password-protect staging instead of relying on noindex, and make "check for noindex on production" a named launch-day task with an owner. If it happens anyway, pages vanish rather than drop — the not-indexed diagnosis applies.

Phase 4 — Launch day

Run these within the first hours, in this order, because each one being wrong invalidates the checks after it:

1. Robots and noindex check. Fetch production robots.txt; spot-check templates for a stray noindex in headers or meta tags. Nothing else matters if this is wrong.
2. Redirect sampling. Test top traffic pages, top link targets, and one of each URL pattern from your mapping sheet. Confirm 301, single hop, correct destination.
3. Status codes across the crawl. Re-crawl the new site and look for 404s, 5xx, and unexpected redirects. Confirm canonicals and hreflang reference new URLs.
4. Search Console setup. Add and verify the new property, submit the new sitemap, and use the change-of-address tool if it applies to your move. Keep the old property — you'll need its data.
5. Analytics and tracking. Confirm tags fire on the new templates. A tracking outage looks exactly like a traffic loss and sends you chasing an SEO problem that doesn't exist.
6. Keep the old domain and its redirects live. Hold them well past the point where crawling of old URLs dies down. Letting the domain expire discards the transfer.

Phase 5 — The recovery curve, and what a real problem looks like

Expect a dip. Rankings and traffic commonly move for weeks while search engines recrawl, process redirects, and re-evaluate the new URLs — turbulence early, then a gradual return toward baseline, with larger sites taking longer simply because there is more to recrawl.

Normal: individual keywords bouncing, new URLs appearing and disappearing from results, indexed counts fluctuating as old URLs drop out and new ones enter.

Genuine warning signs:

• Traffic falls and keeps falling past the first few weeks instead of flattening and recovering.
• A whole section missing from the index rather than individual pages — that points at a template, a robots rule, or a redirect pattern, not churn.
• Crawl or redirect errors at scale in Search Console, rather than scattered one-offs.
• Old URLs still ranking weeks later — usually the redirect isn't reaching them, or is the wrong type.

Telling a real decline from ordinary volatility is a skill worth having before you need it — the framework in is this ranking change real or just noise applies directly, with one adjustment: after a migration, lean toward "something we did" rather than "the SERP moved."

Rollback thinking. Decide before launch what would trigger a rollback and what rolling back even means. For a redirect or robots error, fixing forward is usually faster than reverting. For a full domain move, a true rollback is itself a second migration — so the realistic plan is "fix forward fast" plus a tested code and database restore for functional failures.

FAQ

Will I lose rankings if I change my domain? Expect temporary movement. Search engines have documented processes for handling site moves, and a clean one-to-one 301 mapping with consistent canonicals is designed to transfer signals. Losses that persist usually trace to broken mapping, chains, or missed URLs rather than to the move itself.

How long should I keep the old redirects? Longer than feels necessary. Old URLs keep receiving crawler and human traffic from links and bookmarks for years. Treat redirects as permanent infrastructure, not a launch task.

Should I migrate and redesign at the same time? Separating them is easier to diagnose: when something drops, you know which change caused it. If business reality forces them together, tighten the baselines and expand the launch checks.

Do I need the change-of-address tool in Search Console? It applies to moving between domains, not to URL changes within one domain. Check the current Search Console documentation for which move types it covers, and treat it as an assist to correct 301s, never a substitute.

A migration that goes well looks boring: one hop, one destination, one canonical, one clear sitemap, and a baseline you can point at.

Before you launch, take a proper ranking baseline and keep watching it through the recovery window. Track your keyword positions daily with SBRanker so you can tell a normal post-migration dip from a problem that needs fixing today.