Site Migration SEO Checklist: How to Protect Traffic During a Move

An SEO migration succeeds or fails before launch day. The sites that keep their traffic through a CMS change, domain move, HTTPS switch, or redesign are the ones that crawled and inventoried everything first, mapped every old URL to a specific new one, and watched Search Console daily for weeks afterward. The sites that lose 40% of their organic traffic usually did the redirects on launch night and hoped.

This is the checklist we run at Geeks360 for client migrations, organized into the four phases that actually matter: pre-migration inventory, redirect mapping, launch day, and post-launch monitoring. You can download the whole thing as a tracker at the end. If a migration is part of a bigger rebuild, it pairs with our web design and development work, where SEO sits in the plan from day one rather than getting bolted on the week of launch.

What counts as an SEO migration

“Migration” covers more ground than most teams expect, and each type carries a different risk profile. Anything that changes the URL, the template, the content, or the infrastructure is a migration in Google’s eyes.

The single most common cause of a bad migration is stacking several of these at once. Google’s own guidance is unusually blunt about it.

If you move to a new domain, swap your CMS, and launch a new design in one weekend, you lose the ability to diagnose what broke. Sequence them: move the domain, let it settle, then change the layout.

Sources and further reading

This checklist is built on primary documentation and established migration practice:

1. Google Search Central – How to move a site (site moves with URL changes).
2. Google Search Central – Changing your hosting (site moves without URL changes).
3. Google Search Central – Redirects and Google Search (permanent redirect guidance).
4. Google Search Console Help – Change of Address tool documentation.
5. Google Search Central – Troubleshooting site moves (common migration mistakes).
6. r/SEO and r/TechSEO – practitioner migration checklists and post-mortems.

Phase 1: Pre-migration inventory (start 4 to 6 weeks out)

This phase decides the outcome. Everything here happens while the old site is still live, because once it is gone you cannot recover what you failed to record.

1. Crawl the entire old site. Run a full crawl (Screaming Frog or similar) and export every URL with its status code, title, meta description, H1, canonical, and word count. This is your source of truth.
2. Pull URLs from every source, not just the crawl. Orphaned pages will not appear in a crawl. Combine the crawl with your XML sitemaps, Search Console pages report, GA4 landing pages, and server logs. Include images, PDFs, videos, and other assets, because those earn traffic and links too.
3. Benchmark performance before you touch anything. Export 12 months of Search Console data (queries, pages, clicks, impressions, average position), GA4 sessions and conversions by landing page, and your current rank tracking. Without a baseline you cannot prove recovery or diagnose loss.
4. Identify your money pages. Rank every URL by organic traffic, conversions, and backlinks. The top 20% get manual attention at every later stage; the long tail can be handled with pattern rules.
5. Export your backlink profile. Pull referring domains and the exact pages they link to. Those target URLs must resolve after launch, and the highest-value linking sites are worth an outreach email later.
6. Record technical baselines. Core Web Vitals, indexed page count, structured data coverage, hreflang setup, and robots.txt rules. You will compare against these after launch.
7. Verify Search Console for every variant. Old and new, www and non-www, HTTP and HTTPS. Google is explicit that all variants of both sites should be verified before a move.

If your inventory turns up problems that predate the migration – thin pages, duplicate templates, orphaned sections – a migration is the right moment to fix them, but do it deliberately. Our guide on what an SEO audit should actually tell you covers how to separate real issues from noise before you rebuild.

Phase 2: Redirect mapping (the part nobody budgets enough time for)

Redirect mapping is the heart of a migration. Every indexed old URL needs a specific, relevant destination on the new site. Not the homepage. Not a category page. The closest real equivalent.

1. Map old URL to new URL, one row at a time. Build a spreadsheet with the old URL, the new URL, the reason, and a check column. Pattern rules handle bulk sections; money pages get mapped by hand.
2. Use server-side permanent redirects. Google recommends HTTP permanent redirects such as 301 and 308, implemented server side. Client-side redirects are a last resort, not a plan.
3. Never redirect everything to the homepage. Google warns that redirecting many old URLs to one irrelevant destination can be treated as a soft 404. If a page has no equivalent, redirect to the closest relevant page or let it return a proper 404 or 410.
4. Avoid redirect chains. Googlebot follows chains, but each hop adds latency and risk. Redirect straight to the final destination; if a chain is unavoidable, keep it under three hops.
5. Decide what to retire on purpose. Pages with no traffic, no links, and no conversions can be allowed to 404. Document the decision so it does not look like an accident later.
6. Kill the PageRank myth. Google states plainly that 301 and other permanent redirects do not cause a loss in PageRank. Redirect correctly and the equity follows; the traffic loss teams see comes from bad mapping, not from redirecting itself.
7. Test the map on staging. Run your old URL list against the staging environment and confirm each one lands where the sheet says it should, with a single hop and a 200 at the end.

Phase 3: Launch day

Launch day is execution, not decisions. Every decision should already be in the sheet. Work the list in order.

1. Remove the staging blocks. The most expensive migration mistake in the business is shipping a live site with a leftover noindex tag or a robots.txt Disallow. Check both, on the live domain, before anything else.
2. Turn on the redirects and spot-check immediately. Test your top 50 money pages by hand, plus a random sample of the long tail. Confirm single-hop 301s that resolve to a 200.
3. Confirm canonicals point to the new URLs. Each new page should carry a self-referencing canonical. Update hreflang annotations to the new URLs if you run multilingual pages.
4. Update internal links to the new URLs. Do not rely on redirects for your own navigation, menus, footers, and in-content links. Fix them at the source.
5. Submit the new XML sitemap in Search Console. Keep a copy of the old-URL sitemap temporarily to monitor de-indexing, then retire it.
6. File a Change of Address if the domain changed. Required for domain or subdomain moves, for every verified variant. Not needed for HTTP to HTTPS or www changes on the same domain.
7. Check analytics and tag firing. GA4 property, GTM container, conversion events, and call tracking all need to fire on the new templates. A migration that keeps rankings but loses conversion tracking is still a failure.
8. Confirm server capacity. Google crawls a migrated site more heavily than usual because old-site crawls redirect into the new one. Make sure hosting can absorb the spike.

Phase 4: Post-launch monitoring (the first 90 days)

Expect fluctuation. Google says ranking movement during a move is normal and that a medium-sized site can take a few weeks or more for the new URLs to replace the old ones in results, with larger sites taking longer. Your job is to separate normal settling from real breakage.

1. Week 1, daily: crawl for 404s and redirect errors, watch the Index Coverage report for error spikes, check server logs for Googlebot behavior, and confirm conversions are still tracking.
2. Weeks 2 to 4, weekly: compare Search Console clicks and impressions against your pre-migration baseline page by page, watch indexed counts fall on the old sitemap and rise on the new one, and track rankings for your priority keywords.
3. Months 2 to 3, biweekly: chase link updates from your highest-value referring domains, fix any pages that have not recovered, and re-check Core Web Vitals on the new templates.
4. Keep the redirects at least a year. Google recommends keeping them for as long as possible, generally at least 1 year, so signals fully transfer. From a user perspective, keeping them indefinitely is reasonable.

If traffic has not recovered after 8 to 12 weeks, the cause is almost always one of five things: a leftover noindex, redirects pointing at wrong or non-existent URLs, mass redirects to the homepage being read as soft 404s, content that was quietly thinned during the redesign, or sitemaps still listing old URLs. Our post on hidden SEO issues killing your revenue covers several of these failure modes in more detail.

The mistakes that cost the most traffic

Across migrations, the same handful of errors do most of the damage: launching with staging noindex still in place, mapping redirects only for pages that appear in a crawl (missing orphans and assets), pointing everything at the homepage, stacking a domain move and a redesign in the same release, and having no pre-migration baseline to measure against. None of them are exotic. All of them are avoidable with the checklist above.

One more that shows up on e-commerce moves specifically: forgetting that product, category, and faceted URLs carry the revenue. Replatforming a store is a different animal from moving a brochure site, and it deserves its own mapping pass – which is where our e-commerce marketing team spends most of its migration time.

Take the checklist with you

We turned this whole process into a free, ready-to-use migration tracker. It covers all four phases as a checkable task list with owners and status, plus a redirect mapping tab (old URL, new URL, status code, test result) and a baseline tab for recording your pre-migration Search Console and GA4 numbers so you can prove recovery later. Plan it, run it, and evidence it in one file.

Planning a migration?

A migration is the one project where SEO has to be in the room before the build starts, not invited to review the week of launch. If you want the mapping, testing, and monitoring handled by a team that has done it before, see our SEO services, or start with an SEO audit to benchmark exactly what you have to protect. Want to talk it through first? Get in touch.