Site Migration SEO Planning: The Pre-Launch Checklist That Prevents Traffic Loss

Most ranking losses during a replatform, redesign, or domain move are not caused by the new site being "worse." They are caused by broken signal continuity: URLs that change without redirects, redirects that point to the wrong place, internal links that still reference dead paths, and a launch that happens before anyone has crawled the new build. A disciplined, sequenced plan removes almost all of that risk before go-live.

Why a sequence matters more than a checklist

A flat checklist lets you tick boxes in any order, which is how teams end up redirect-testing URLs that the dev team is still renaming. The work has dependencies. URL mapping must be locked before redirects are written. Redirects must be QA'd before the staging crawl is meaningful. The staging crawl must be clean before launch. Monitoring is set up before, not after, traffic shifts. Treat each phase as a gate: you do not advance until the prior phase passes.

Phase 1: Baseline everything (before you touch anything)

You cannot prove you protected rankings if you never recorded them. Capture a complete pre-migration snapshot while the old site is stable.

• Full URL inventory. Crawl the live site (Screaming Frog, Sitebulb) and merge it with URLs from Google Search Console, your XML sitemaps, server logs, and analytics. Crawlers miss orphan pages that still rank, which is why log files and GSC matter.
• Performance baseline. Export 16 months of GSC data (queries, pages, clicks, impressions, average position) and your top organic landing pages from analytics. This is your "before" line for every post-launch comparison.
• Backlink-earning pages. Pull pages with the most referring domains. These are your highest-priority redirects; a broken redirect here leaks link equity directly.
• Index and crawl signals. Record current indexed count, canonical tags, hreflang clusters, robots.txt, and structured data so you can diff them after launch.

Phase 2: URL mapping (the spine of the migration)

The mapping document is the single most important artifact in any site migration seo project. Build a spreadsheet with one row per old URL and these columns at minimum: old_url, new_url, status (keep / redirect / retire), redirect_type, priority, and notes.

• Map one-to-one wherever possible. Every old URL should resolve to the most relevant equivalent on the new site. Avoid collapsing many old URLs into a single generic page or the homepage; that is treated as a soft 404 and the ranking signals are not passed cleanly.
• Decide deliberately on retired pages. If content genuinely has no successor, redirect to the closest parent category, not the homepage. Only return a 410/404 for pages you actively want deindexed.
• Preserve URL patterns when you can. If the replatform lets you keep existing slugs, do it. Every changed URL is redirect risk you are choosing to take on.
• Flag high-value rows. Mark your top-traffic and top-backlink URLs as priority so QA and post-launch monitoring focus there first.

Phase 3: Redirect implementation and QA

Redirects are where migrations quietly fail. Two rules govern everything: use 301 (permanent) for moved content, and never chain redirects.

1. One hop only. Old URL → final destination in a single 301. Redirect chains (A→B→C) waste crawl budget and dilute signals; redirect loops take pages offline entirely.
2. Redirect to the final URL. Point at the canonical, trailing-slash-correct, HTTPS destination so the redirect does not hand off to another redirect.
3. QA the full map programmatically. Crawl your list of old_url values and assert each returns a single 301 landing on the intended new_url with a 200. A quick spot check with curl -sIL https://old.example/page shows the entire hop chain and final status for individual URLs.
4. Watch the edge cases: HTTP→HTTPS, www vs non-www, trailing slashes, uppercase paths, and query parameters. Each variant should funnel to one canonical form.

Do not consider redirects "done" until a re-crawl of the entire old-URL set shows zero chains, zero loops, and zero unintended 404s.

Phase 4: Staging crawl and pre-launch validation

Crawl the new site on staging as if it were production. This is the gate that catches the silent killers.

• The robots and noindex check. Staging is almost always blocked by robots.txt or a site-wide noindex. Confirm the launch build ships with crawling allowed and noindex removed. Shipping a blanket Disallow: / to production is the single most common catastrophic migration mistake.
• Internal links point to new URLs. Update navigation, in-content links, canonicals, sitemaps, and hreflang to reference final URLs directly. Internal links should never rely on redirects to resolve.
• Canonical tags self-reference the new URLs, not the old domain or staging host.
• Metadata, headings, and structured data carried over. Diff titles, meta descriptions, H1s, and schema against your baseline. Redesigns frequently drop content blocks and on-page elements that were doing ranking work.
• XML sitemaps regenerated with only canonical, indexable new URLs, ready to submit at launch.

If staging sits behind authentication, crawl with credentials or a staging-specific allowance so the audit is real and not a wall of 401s.

Phase 5: Launch sequence and monitoring

Launch is a procedure, not a moment. Run it in order and verify each step live.

1. Deploy, then immediately confirm production serves the correct robots.txt and that noindex is gone.
2. Verify a sample of priority redirects in production (they sometimes behave differently than on staging due to CDN or server config).
3. Submit the new XML sitemap in Search Console. For a domain move, use the GSC Change of Address tool and keep verification on both properties.
4. Keep old-host verification active so you retain visibility into how the old URLs are being crawled and redirected.

Then monitor daily for the first two to four weeks, weekly after that:

• Crawl stats and coverage in GSC: watch for spikes in 404s, redirect errors, or "Discovered – not indexed."
• Index count trending toward your baseline as Google reprocesses the new URLs.
• Server logs for how Googlebot is actually hitting the site and whether it is still requesting old URLs (expected for weeks).
• Rankings and clicks for your priority pages against the Phase 1 baseline. A modest, temporary dip during reprocessing is normal; a sustained drop on specific URL clusters points to a mapping or redirect defect you can trace.

Common mistakes that cause traffic loss

• Launching before the staging crawl is clean. The crawl exists to find problems while they are still cheap to fix.
• Redirecting everything to the homepage. It feels safe and destroys page-level relevance signals.
• Forgetting the redirects are only as good as their map. An incomplete URL inventory means orphan pages that rank simply vanish.
• Shipping noindex or Disallow: / from staging. Check it at launch, then check it again an hour later.
• Removing redirects too soon. Keep 301s in place for at least a year; Googlebot crawls old URLs long after launch.
• Migrating multiple variables at once. If you can avoid changing platform, design, and domain in the same release, do. Isolating changes makes diagnosis possible when something moves.

The one-line test for readiness

You are ready to launch when you can answer yes to all five: every old URL is mapped, every redirect is a single 301 to its final destination, the staging crawl is clean and indexable, the new sitemap is built, and monitoring is live against a recorded baseline. If any answer is no, the gate is closed.