Seofable Team·2026-07-20·14 min read

Site Migration Checklist for SEO (2026 Guide)

Most migration checklists treat every migration the same. That's the first mistake. A domain change from oldbrand.com to newbrand.com carries different risk than moving from WordPress to a headless CMS, and both are nothing like adding HTTPS to a site that's already stable. We've watched teams follow a generic 40-item checklist and still lose 60% of organic traffic — because the checklist didn't tell them which 5 items mattered most for their specific move.

This guide splits the work by migration type, gives you real benchmarks for what "normal" traffic loss looks like, and — the part most guides skip — a decision tree for when a ranking drop is expected noise versus a real problem that needs a rollback.

What Counts as a Site Migration (and Why One Checklist Doesn't Fit All)

A site migration is any change that alters URLs, hosting, domain, or site structure at scale. Google has to re-crawl, re-evaluate, and re-index your site essentially from scratch in some cases. The risk isn't the change itself — it's how much of your existing signal (links, crawl history, content structure) survives the transition.

Four migration types cover almost every real-world case:

Domain or brand change

This is the riskiest move because you're asking Google to transfer trust from one domain to another entirely. Your backlink profile doesn't move automatically — every external link pointing to the old domain has to pass through a 301 redirect to reach the new one. Google confirms that 301 redirects pass 100% PageRank when implemented correctly, closing the door on the older idea that 301s reduce link equity. That said, the transfer isn't instant — equity recognition isn't instant even with a 301, since Google has to recrawl the old URL first, and the consolidation happens over multiple crawl cycles. So expect a lag before backlink signals fully register on the new domain, even with clean redirects. Brand search volume also resets; people keep typing the old domain name into Google for months.

CMS or platform migration

Moving from WordPress to Webflow, Shopify to a custom stack, or any replatform usually breaks URL structure even when nobody meant it to. Trailing slashes disappear, category pages get new slugs, pagination changes format. The technical markup also shifts — new themes often ship with different heading structures, missing alt text, or canonical tags pointing to the wrong URL by default. Check every template type, not just the homepage.

HTTPS or subdomain/subfolder restructure

Lower risk in theory, but redirect chains are the silent killer here. Moving from http:// to https:// and from www to non-www in the same launch creates two redirect hops per URL unless you configure it as one. Google's John Mueller advises keeping redirect chains to fewer than 5 hops for URLs that are frequently crawled, since Google will only follow 5 hops in a chain per crawl attempt — beyond that, it won't land on the destination URL at all. Each additional hop adds latency and crawl-budget cost. Do the HTTPS switch and any subdomain-to-subfolder move as a single combined redirect, not two separate steps.

Content or URL structure overhaul

Changing your category structure or flattening deep URLs (/blog/category/subcategory/post to /blog/post) is deceptively risky because it's easy to convince yourself it's "just URLs." It's not — it changes internal linking patterns, breaks old sitemaps, and often orphans pages nobody remembered existed. This is the type where a full crawl before launch matters most, because you're the one deciding what stays and what gets pruned.

Pre-Migration Planning and Benchmarking

You can't tell if a migration worked if you don't know your starting point. Skip this stage and you'll be arguing about whether traffic actually dropped, three weeks after launch, with no data to settle it.

Full site crawl and URL inventory

Crawl the entire current site with Screaming Frog (or a similar crawler) before touching anything. Export every indexable URL, its status code, title tag, canonical tag, and internal link count. This becomes your source-of-truth inventory for building the redirect map later. If your site has more than a few thousand URLs, this step alone can take a day — budget for it.

Cross-reference the crawl against your XML sitemap and Google Search Console's index coverage report. Pages that are indexed but missing from your crawl (or vice versa) need investigating before migration, not after. If you're setting up a brand-new site alongside a migration, our SEO checklist for new websites covers the launch-specific steps that overlap here.

Baseline rankings, traffic, and backlink export

Pull and save, before launch:

• Organic sessions and conversions for the last 12 months, segmented by landing page
• Rank tracking data for your top 50-100 keywords, ideally with historical position history
• A full backlink export from Ahrefs, Semrush, or Google Search Console's links report
• Top-performing pages by organic traffic, so you know exactly which URLs cannot afford to break

Tools matter less than doing it at all. If you want a rundown of what's worth paying for right now, we've got a breakdown of AI SEO tools that includes crawlers and rank trackers suited to migration audits.

Assign a rollback owner and go/no-go criteria

One person owns the rollback decision. Not a committee, not "we'll figure it out." Before launch, write down the specific conditions that trigger a rollback — we cover concrete thresholds in the realistic expectations section below — and get sign-off from whoever controls DNS and hosting. This sounds like overkill until day 3 post-launch when traffic craters and three people are arguing about whether it's "probably fine."

The Core SEO Migration Checklist

This is the tactical layer — the stuff that actually determines whether Google can find and trust your new URLs.

Build a 1:1 redirect map

Every old URL maps to exactly one new URL. Not a blanket redirect to the homepage, not a category-level catch-all — a specific, one-to-one mapping wherever the content has a clear equivalent.

Build this in a spreadsheet with columns for old URL, new URL, redirect type, and a "verified" checkbox you tick off after testing. For sites over 10,000 URLs, script the matching (regex rules based on URL patterns) rather than mapping by hand — but spot-check at least 5% manually before launch, because automated matching mismatches high-value pages more often than you'd expect.

Preserve content and internal links

Content parity means the new page has the same core content, headings, and target keyword focus as the old one — not necessarily identical copy, but equivalent depth and intent match. Rewriting content and changing URLs in the same migration is the single biggest cause of unexplained ranking drops, because you've changed two variables at once and can't isolate which one caused the drop.

Internal linking has to be rebuilt to point at new URLs, not left pointing at old ones that then rely on redirects. A site with 5,000 internal links all firing through redirect chains loads slower for crawlers and dilutes link equity with every hop. Update internal links to point directly at final destination URLs before launch.

Update sitemaps, canonicals, and robots.txt

Your new XML sitemap should contain only new, live URLs — remove old URLs entirely once redirects are confirmed working. Canonical tags on every new page need to self-reference the new URL, not the old one (a shockingly common bug after CMS migrations, where the theme defaults to canonical-ing the staging URL or an old permalink structure). Check robots.txt isn't still blocking directories that mattered on the old site, and isn't accidentally carried over from staging with a blanket Disallow: /.

Technical Setup: DNS, Hosting, Staging

Get the staging environment right and launch day gets boring, in a good way.

Test the entire new site on a staging environment first, and make sure that staging environment itself is blocked from indexing (via robots.txt disallow or a noindex meta tag, plus password protection) — staging sites that leak into Google's index create duplicate content headaches that outlive the migration by months.

Before cutover, confirm:

DNS propagation typically completes within a few hours but can take up to 48 hours in edge cases depending on ISP caching. Don't panic if some users see the old site for a day — that's normal, not a migration failure.

Launch Day Checklist

Launch during your lowest-traffic window — for most B2B sites that's a weekend early morning; for ecommerce, avoid peak shopping days entirely.

Keep the old Search Console property active too — don't delete it. You'll need its historical data for comparison during the diagnostic phase, and Google still shows the "change of address" or migration data there for a limited window after a domain move — these notifications display for 180 days.

Post-Launch Diagnostic Framework (First 30/60/90 Days)

Here's the part most checklists skip entirely: what to actually do when rankings drop after launch, instead of just "monitor Search Console and wait."

Week 1: crawl and indexing checks

Run a fresh crawl of the live new site and compare it against your pre-migration inventory. Check the index coverage report in GSC daily this week — you're looking for a spike in "Discovered — currently not indexed" or "Crawled — currently not indexed," which signals Google is finding your new URLs but not prioritizing them yet. That's normal in week 1. A spike in 404s or redirect errors is not — fix those immediately.

Cross-check log files if you have access (log file analysis) to confirm Googlebot is actually crawling the new URLs and not stuck hammering old ones that no longer redirect correctly.

Weeks 2-4: ranking and traffic diagnosis

If rankings have dropped by week 2-4, work through this in order — don't jump to "the migration failed":

1. Redirects first. Spot-check your top 50 traffic-driving URLs. Are the redirects live, 301 (not 302), and pointing to the exact right page — not a category page or homepage catch-all?
2. Indexing second. In GSC's index coverage report, are the new URLs actually indexed? Search site:yourdomain.com/specific-page-url to confirm.
3. Content parity third. Compare the new page's content against the old cached version. Did a "quick content refresh" during migration accidentally cut the section that was ranking for your target keyword?
4. Internal links fourth. Crawl the new site and check that your top pages still receive strong internal link counts. A page that lost half its internal links during a restructure will lose ranking power even with a perfect redirect.

If all four check out clean and rankings are still down, the cause is more likely a normal re-crawl lag than a technical failure — move to the next stage.

Month 2-3: recovery confirmation

By week 8-12, rankings for most pages should be back within 10-15% of pre-migration positions, assuming no errors were found in the diagnostic steps above. If specific pages are still down more than that with clean redirects, indexing, and content parity, check whether competitors gained ground during your migration window — sometimes it's not you, it's the market moving while you were heads-down on DNS settings.

Realistic Expectations: Traffic Loss, Recovery Time, and When to Roll Back

Here's the part vendors selling migration services don't like to say out loud: some traffic loss is normal, and no amount of preparation eliminates it entirely.

These are rough benchmarks based on how Google's re-crawl and re-evaluation cycles typically behave, not a guarantee — your mileage depends on site size, authority, and how clean your execution was. Our guide on how long SEO takes to work covers the broader ranking-factor timeline that applies here too, since a migration is essentially asking Google to re-establish trust signals from a partial reset.

Rollback triggers — decide these before launch, not during the panic:

• Traffic drops more than 50% within the first week with no explanation found in the week-1 diagnostic checks
• Redirect errors affecting more than 10% of your top 100 URLs that can't be patched within 48 hours
• Core site functionality broken (checkout, forms, login) that can't be fixed same-day
• Indexing coverage shows the new site is being actively excluded (not just slow to index) two weeks post-launch

If none of those apply, don't roll back just because week 1 looks scary. A 20% dip in week 1 that's trending back up by week 3 is normal. A 20% dip that's still 20% down in week 6 with clean technicals is a different conversation — possibly a content or authority issue rather than a migration bug, and rolling back won't fix it anyway.

Common Mistakes That Tank Rankings After Migration

• Chained redirects. Old URL → intermediate URL → final URL. Each hop is friction Google has to resolve; consolidate to one hop.
• Orphaned old URLs with no redirect at all. Especially common with paginated archives, tag pages, or old campaign landing pages nobody remembered to inventory.
• Losing internal links during a redesign. New navigation often drops footer links or related-post modules that were quietly carrying link equity to deep pages.
• Forgetting to update Google Analytics and GSC. Tracking codes left pointing at the old domain mean you're flying blind on the exact days you need data most.
• Blocking the new site in robots.txt during soft-launch, then forgetting to remove it. We've seen this one personally — a client's new site sat fully built and live for four days with Disallow: / still active from staging, and nobody noticed until organic traffic showed zero new-domain impressions in GSC.
• Treating a redesign and a URL change as separate low-risk events when done together. Combined, they're higher risk than either alone — plan them as one migration, not two small changes.

For more fact-checked SEO guides beyond migrations, our blog covers the rest of the technical and content side.

FAQ

How long does it take to recover SEO rankings after a site migration?

Anywhere from a few weeks to 3-4 months, depending on migration type and site size. HTTPS-only switches often fully recover within 3 weeks; domain changes or full restructures can take 8-16 weeks. Clean redirects and content parity speed this up significantly; chained redirects and content rewrites slow it down.

How much traffic loss is normal during a migration?

A 10-30% short-term dip is within normal range depending on migration type — see the table above. A dip beyond that range, or one that shows no sign of recovering within 6-8 weeks, is a signal to run the diagnostic checks rather than assume it's temporary.

Should I use 301 or 302 redirects during a migration?

301 (permanent) for the actual launch, always. 302 (temporary) only makes sense during a testing phase on staging, never on the live final redirect map — a 301 makes the destination canonical, while a 302 keeps the source canonical, meaning Google tends to keep ranking signals with the old URL instead of consolidating them onto the new one.

How long should old redirects stay live?

Google's own guidance is to keep redirects in place for as long as possible, generally at least 1 year, to allow Google to transfer all signals to the new URLs, including recrawling and reassigning links from other sites. For high-authority legacy URLs with strong backlink profiles, keep redirects live indefinitely if you can — there's little cost to maintaining them and real risk in removing them too early, since some external links and bookmarks never get updated.

How do I know if my migration failed and I need to roll back?

Use the rollback triggers above: a traffic drop over 50% in week one with no explanation from the diagnostic checks, broken core functionality that can't be patched fast, or clear signs Google is excluding your new site from indexing two weeks post-launch. Short of those, ride out the normal recovery window before pulling the plug.

Do I need to migrate every page, or can I cut low-value URLs?

Pruning is fine — smart, even — if it's deliberate. Redirect thin or outdated pages to the closest relevant equivalent, or serve a proper 410 (Gone) if there's genuinely no replacement. What tanks rankings isn't pruning; it's silently dropping pages with no redirect and no explanation, leaving Google to find 404s where indexed content used to be.

✓ Fact-checked 2026-07-19 — Corrected the outdated claim that 301 redirects lose backlink/PageRank value (Google confirms 301s pass full PageRank, though transfer isn't instant); corrected the redirect-chain/hop-dilution claim to reflect Google's confirmed 5-hop crawl limit; corrected the 6-12 month redirect retention claim to match Google's official "at least 1 year" guidance; refined the 302-redirect explanation to reflect Google's canonical-consolidation mechanism; added the confirmed 180-day window for Search Console's change-of-address notifications. Mobile-first indexing, DNS propagation behavior, and GSC index-status labels were checked and found accurate as stated.