Website migrations are launches. Most failures come from a pile of tiny “eh, we’ll fix it later” decisions. Then Search Console lights up like a Christmas tree and everyone suddenly cares.

This is a practical SEO checklist you can run like a Mission Control playbook. The focus is broken links, redirects, and the stuff that keeps traffic from falling off a cliff on launch week.

TL;DR migration checklist

  • ✅ Inventory old URLs (old sitemap + logs)
  • ✅ Build a 301/410 redirect map (old → new)
  • ✅ Update internal links (don’t rely on redirects)
  • ✅ Launch QA crawl (catch 404s, loops, chains)
  • ✅ Monitor Search Console + logs after launch

Prep (T‑minus: before you touch anything)

1) Inventory URLs

You need an “old world” URL list. The best sources:

  • Old sitemap(s)
  • Server logs (what people and bots actually hit)
  • Analytics / Search Console exports

Don’t skip the boring edge cases: old PDFs, campaign landing pages, and “random” blog posts from 2017 that still have backlinks. Those are exactly the URLs that will show up as 404s for months if you don’t map them now.

2) Decide your redirect policy

  • 301 for real moves (old page has a new home).
  • 410 for intentional removals (no replacement).
  • Avoid blanket redirects (everything → homepage) unless you enjoy confusing users.

3) Freeze the window

Plan a deploy window and a rollback plan. Migrations fail most often when changes keep shipping while redirects are half done.

Map redirects (write the flight plan)

If you have old + new sitemaps, you can generate a mapping workflow instead of hand-editing spreadsheets. Use TinyUtils Sitemap Delta to compare lists and export redirect rules.

A simple way to think about the mapping: for each old URL, pick the new URL that answers the same intent. If there isn’t a real replacement, don’t fake it — return a 410 and move on.

Old URL New URL Status
/pricing/ /plans/ 301
/blog/old-post/ /blog/new-post/ 301
/downloads/legacy-brochure.pdf (no replacement) 410

Rules of thumb

  • Closest match beats “kind of related”. Redirect to the page that answers the same intent.
  • Specific before wildcard. Wildcards are powerful and dangerous.
  • Kill chains. Old URLs should point directly to the final destination.
  • Normalize slashes and casing. Most redirect bugs are “almost the same URL”.

Don’t forget the “boring” redirects

Migration redirect maps are usually about content URLs, but you also want your canonical behavior to be consistent:

  • HTTP → HTTPS (pick one and enforce it).
  • www vs non‑www (pick one, redirect the other).
  • Trailing slash (pick a convention and stick to it).

These don’t feel exciting, but they prevent loops and “why does Google have two versions of every page?” headaches.

Query strings: decide your policy early

Some migrations change URL parameters (filters, pagination, search). Others only use parameters for tracking (UTMs). Decide what you’re going to do:

  • Keep parameters when they affect the page content.
  • Ignore/drop tracking parameters if you want cleaner analytics and fewer “duplicate” URLs.
  • Map only when there’s a real one-to-one translation between old and new parameter schemes.

Implement (don’t forget internal links)

Redirects are necessary — but they shouldn’t be your internal navigation system. After you add redirects:

  • Update nav and footer links.
  • Update canonical URLs.
  • Update sitemap(s) to reflect the new structure.

A quick sanity check that catches a lot of mistakes: every old URL should do exactly one hop (301) and land on a 200. If you see 301 → 301 → 200 chains, fix them now. Google follows chains, but you’re wasting crawl budget and making users wait.

Launch QA (catch disasters before Google does)

Think of this as the launch simulation. Do a crawl right after launch, and start with templates because they multiply: homepage, nav/footer, category pages, top blog templates.

What you’re looking for

  • 404s on important pages
  • Redirect loops
  • Redirect chains
  • Robots/sitemap mistakes

Launch-day checklist (the part people skip)

  • Deploy redirects first, then deploy the new site.
  • Submit the new sitemap in Search Console and keep the old sitemap reachable for a couple of weeks.
  • Purge CDN caches after redirects go live so edge caches learn the new routes.
  • Watch logs for 10–15 minutes: spikes in 404s, 500s, or 301→301 chains are your early warning system.
  • Spot-check your “must-work” list of 10–20 high-traffic URLs on mobile and desktop.

Post-launch hardening (first week)

  • Chain hunting: remove 301→301 chains so old URLs go straight to the final destination.
  • Internal link cleanup: replace internal links pointing at redirected URLs with the final URLs.
  • Patch unexpected 404s daily: there’s always a forgotten campaign URL or an old PDF with backlinks.
  • Re-crawl weekly: small regressions show up fast when you have a repeatable scan.

Communication plan (keep humans calm)

Migrations aren’t just technical. People need to know what’s happening. A simple plan works:

  • Content freeze notice: tell editors when the freeze starts and ends.
  • Status pings: “redirects live”, “staging QA done”, “production cutover” keeps everyone aligned.
  • One incident owner: one person watches logs/Search Console right after launch.

30-minute final rehearsal

  1. Run a small crawl against staging with redirects enabled (even 200 URLs is enough to catch obvious mistakes).
  2. Spot-check the top 10 pages on mobile and desktop.
  3. Confirm rollback is a real button you can press (revert commit, redeploy).
  4. Write down “who is watching what” for the first hour after cutover.

After launch (watch telemetry like it’s your job)

  • Watch Search Console for spikes in “not found” URLs.
  • Watch logs for repeated 404s (especially old URLs still being hit).
  • Fix the top 20 issues first — it’s usually most of the impact.

One practical trick: keep a simple “top 50 old URLs” list and re-check it daily for the first week. It’s boring, but it catches the high-impact issues fast — before they become “why is traffic down 30%?” threads.

Next steps

If you’re migrating soon, start by comparing sitemaps with TinyUtils Sitemap Delta. Then run Dead Link Finder after launch to catch the broken stuff fast.