A site migration SEO checklist covers three phases: pre-migration planning (benchmark metrics, crawl every URL, build a 1:1 redirect map), launch day (enable 301 redirects, update internal links, submit new sitemaps), and post-migration monitoring (check for broken links, verify tracking, watch rankings daily). Incomplete redirect mapping causes most of the traffic loss that follows a migration.
Here’s the part that catches people off guard: you can do 95% of a site migration correctly and still lose most of your organic traffic over one missed redirect or an unsubmitted sitemap. Migrations rarely fail gradually. They fail on launch day, and recovery can take months even when the actual fix is simple.
This checklist walks through every phase of a technically sound migration – including the parts most guides skip entirely, like how to classify which type of migration you’re actually doing, how to reconcile the wildly different “recovery timeline” numbers floating around online, and why a redesign can quietly gut the rankings of your best-performing pages even when every redirect works perfectly.
Everything here comes from real migration work across domain changes, CMS switches, and full redesigns – not a generic template applied to every project the same way.
What Is a Site Migration (and Which Type Are You Doing)?
A site migration is any major change to your website’s domain, structure, platform, or design – the kind of change significant enough that search engines need to re-evaluate the site essentially from scratch.
The 5 Common Migration Types and What Changes for Each
Not every migration carries the same risk profile, and knowing which type you’re doing tells you exactly which parts of this checklist deserve the most attention.
- Domain change. Moving to a new domain name – a rebrand, a TLD switch, or consolidating multiple domains into one. This carries the highest risk, since every single URL needs a redirect and Google has to re-establish trust in an entirely new hostname. Use Search Console’s change of address tool for this type specifically.
- CMS or platform switch. Moving from one content management system to another – WordPress to Shopify, for instance. URL structures often change even when the domain doesn’t, and structured data is the most common casualty since new platforms rarely rebuild schema markup identically.
- Site redesign (same domain, same URLs). A visual refresh or UX overhaul that keeps your existing URL structure intact. Lower redirect risk, but this is exactly the type where content thinning quietly damages already-ranking pages – more on that below.
- URL structure or information architecture change. Restructuring categories, consolidating duplicate pages, or fixing messy URL patterns, even without changing domain or platform. Every changed URL needs its own redirect, making this deceptively close to domain-change risk levels.
- Hosting or server migration. Moving to a new host without changing domain, platform, or URLs. Lowest SEO risk of the five, but still requires DNS attention and a post-launch speed check, since server changes can quietly affect load times either way.
Why Migration Risks SEO Even When Done Correctly
Even a technically flawless migration causes some temporary disruption, because Google needs time to recrawl, re-render, and re-index every changed URL and re-establish the ranking signals attached to it.
The risk isn’t the migration itself – it’s the gap between what you think changed and what actually changed. A redirect map built from memory instead of an actual site crawl. A robots.txt rule written for staging that accidentally ships to production. These are the failures that turn a manageable dip into a genuine crisis.
How Long Does It Take to Recover Traffic After a Migration?
This is the question every stakeholder asks, and it deserves an honest answer instead of a single reassuring number.
Why Recovery Estimates Vary So Widely
You’ll find genuinely conflicting statistics if you search around – some sources cite recovery averaging around 17 months, others cite closer to 500+ days with a meaningful share of sites never fully recovering. Both numbers are real; they’re just measuring different populations of migrations.
The gap comes down to what’s actually being measured. A study pooling all migrations – including botched ones with incomplete redirect maps, wrong redirect types, or dropped structured data – will show a much longer average recovery time and a real “never fully recovered” tail. A well-executed migration with a complete 1:1 redirect map, tested thoroughly before launch, recovers dramatically faster than that pooled average suggests.
What Actually Determines Your Recovery Timeline
Four factors matter more than any general statistic: how complete your redirect map is, how much your URL structure actually changed, your site’s total size, and how quickly you catch and fix post-launch errors.
A hosting migration with zero URL changes might show barely any visible dip at all. A full domain change with a restructured URL pattern and thousands of pages is a genuinely different project, and treating both the same way with one blanket “expect X months” expectation sets the wrong baseline for stakeholders from day one.
What Should You Do Before Migration?
Everything here happens before a single URL goes live on the new site.
Benchmark Your Current Metrics
Record your current organic traffic, keyword rankings for priority terms, number of indexed pages, and Core Web Vitals scores at least two to four weeks before migration. This is the dataset every post-launch comparison depends on – without it, you’re guessing whether a traffic dip is normal fluctuation or a real problem.
Crawl and Inventory Every Existing URL
Run a full crawl of your live site using a tool like Screaming Frog, and cross-reference it against your Google Search Console index coverage report, your analytics data, and your existing XML sitemap. Combining multiple sources matters – a crawl alone can miss orphaned pages, old campaign landing pages, or paginated archives that don’t appear in your main navigation but still receive real traffic.
Identify Your Top-Performing Pages and Backlink Targets
Flag the pages that carry a disproportionate share of your organic value – the ones ranking for competitive terms, driving the most traffic, or holding the most valuable backlinks. These deserve extra scrutiny during redirect mapping and testing, since losing one of these is a fundamentally bigger problem than losing a thin, rarely-visited page.
Set a Timeline and a Rollback Plan
Document exactly when DNS switches happen, when the old site goes read-only, and what specific condition triggers a full rollback to the previous version. Without this written down in advance, “we’ll fix it after launch” quietly becomes the default plan, and problems compound for days before anyone formally decides to act.
Define Your Escalation Triggers in Advance
This is the step most migrations skip entirely, and it’s the difference between reacting to a real problem fast and debating whether a drop is “normal” while it quietly gets worse.
Before launch, agree on a specific, numeric trigger – for example, a 20% drop in organic sessions sustained for three consecutive days, or a spike of more than 50 new 404 errors in a single day. Write down exactly who gets notified and what the first response step is when that trigger fires.
Having this decided in advance removes the emotional debate from a stressful moment. Nobody has to argue in real time about whether a dip counts as “normal post-migration noise” – the threshold was already agreed on when everyone was calm.
How Do You Build a Redirect Map That Actually Works?
This is the single highest-impact piece of migration work, and it’s where most traffic-loss disasters actually originate.
Building a 1:1 URL Map
Every URL from your pre-migration crawl needs a specific destination on the new site – not a blanket redirect to your homepage or blog index. Build this from your actual URL inventory, not from memory of “the important pages,” since memory reliably misses exactly the orphaned or older content that still holds real value.
Where a true 1:1 match isn’t possible – a page genuinely doesn’t exist anymore – redirect to the closest relevant parent category instead of defaulting to the homepage. A homepage redirect for unrelated content confuses both users and search engines and is treated as a soft failure, not a real redirect.
301 vs. 302 vs. 410 – Which Redirect for Which Scenario
Choosing the wrong status code is one of the most common, most damaging migration mistakes, and the differences matter more than they initially seem to.
| Status Code | What It Signals | When to Use It | Common Mistake |
| 301 (Permanent Redirect) | Page has permanently moved; transfer ranking signals to new URL | Any URL that has a genuine new home on the migrated site | Using 302 by default because a CMS or platform tool defaults to it |
| 302 (Temporary Redirect) | Page has temporarily moved; don’t transfer ranking signals | Short-term A/B tests or genuinely temporary content moves only | Using this for a permanent migration, causing Google to keep the old URL indexed indefinitely |
| 410 (Gone) | Content is permanently and intentionally removed | Content with no equivalent anywhere on the new site | Redirecting instead of using 410, creating a misleading redirect to unrelated content |
Check your redirect type at the server or platform configuration level specifically. Many CMS migration tools default to 302 without making that choice obvious, silently undermining the exact ranking-signal transfer the migration depends on.
Eliminating Redirect Chains and Loops
A URL that redirects to another redirect, which redirects again, adds crawl delay at every hop and can eventually break entirely. Audit your full redirect map specifically for chains longer than one hop, and collapse each one down to a single, direct old-URL-to-final-destination redirect.
Handling URL Parameters and Legacy Patterns
Old sites frequently carry URL parameters, trailing-slash inconsistencies, uppercase variants, or leftover patterns from a previous platform migration – and some of these still hold real traffic or link equity. Decide explicitly how your redirect map handles each pattern rather than letting edge cases silently fall through to a default 404.
Testing Your Full Redirect Map at Scale Before Launch
Spot-checking a handful of “important” URLs isn’t enough. Bulk-test your entire redirect map against the staging environment using a crawler, uploading the complete old-URL list and confirming every single one resolves to the correct destination with the correct status code – not just the pages someone remembers to check manually.
Catching a broken chain or an accidental 404 in this bulk test, before launch, costs minutes. Catching the same issue after launch costs real rankings while you scramble to fix it.
How Do You Set Up and Test a Staging Environment?
Blocking Search Engines From Your Staging Site
Add password protection through your hosting control panel, and layer a noindex meta tag on every staging page as a second line of defense. Relying on just one of these methods is risky – password protection alone can still leak through a misconfigured link, and a noindex tag alone does nothing if the crawler never reaches the page in the first place.
Running a Technical SEO Audit Before Launch
Crawl your staging site the same way you crawled your live site, and compare the results directly. Check for missing meta tags, broken internal links, incorrect canonical tags, and confirm your staging environment’s total URL count reasonably matches your original inventory.
A Pre-Launch Go/No-Go Checklist
Before you flip the switch, confirm every item below. If any single item fails, delay launch rather than fixing it live under pressure.
- Redirect map is complete and bulk-tested against staging with zero unresolved chains or unexpected 404s.
- Robots.txt on staging has been reviewed line by line to confirm none of its rules will accidentally carry over to production.
- Structured data validates cleanly on every major page template using a schema validator.
- Analytics and tracking codes fire correctly on staging and are confirmed to be collecting real event data.
- Rollback plan is documented, tested, and every stakeholder knows their specific role if it needs to activate.
- Escalation triggers are agreed on in writing, not just discussed verbally.
Treat this as a genuine gate, not a formality. A migration that fails even one of these checks going live is choosing to debug in public, in front of both users and search engines simultaneously.
What Happens on Launch Day?
Choosing a Low-Traffic Launch Window
Pick a quiet period – typically early in the week, outside peak business hours – so your team has room to catch and fix issues before they reach a large share of your visitors. If you run e-commerce, avoid launching anywhere near your highest-revenue season; a rocky migration during Q4 costs far more than the same rocky migration in a slower month.
Enabling Redirects and Removing Crawl Blocks
Activate your full redirect map and remove every temporary block – password protection and any noindex tags – from the newly live site at the same moment. These two actions need to happen together; leaving a stray noindex tag in place even briefly after redirects go live can get pages deindexed before Google even has a chance to see the corrected version.
Updating Internal Links and Submitting Your New Sitemap
Update your navigation menus, footer links, and in-content body links to point directly to final destination URLs, not through your new redirects. Submit your updated XML sitemap to Search Console immediately at launch, not days later – this actively speeds up how quickly Google discovers your new structure.
Completing Google Search Console Tasks
If you’ve changed domains, file a change of address request in Search Console right away. Verify ownership on the new property, and submit both your old and new sitemaps together – keeping the old sitemap live temporarily helps Google connect the dots between what moved and where it went.
How Do You Preserve On-Page SEO During a Migration?
A migration should move your existing SEO assets forward, not quietly reset them.
Carrying Over Titles, Meta Descriptions, and Heading Structure
Unless a deliberate on-page refresh is planned and resourced as its own separate project, transfer title tags, meta descriptions, and heading hierarchy unchanged. Rewriting all of this at the same time as a technical migration means you can’t isolate which change caused which ranking movement if something goes wrong afterward.
Check specifically that your priority pages retain one clear H1 and a heading structure that still reflects the page’s actual topic – new templates frequently restructure heading hierarchy purely for visual design reasons, sometimes demoting or removing the main heading entirely.
Preserving Image Alt Text and File Names
Bulk image migrations commonly strip alt attributes or rename files to generic, CMS-assigned strings during the transfer process. Spot-check a sample of image-heavy pages specifically after migration – this is a quiet loss that rarely shows up in a standard crawl report but genuinely affects image search traffic and accessibility.
Avoiding Content Thinning on Your Best-Performing Pages
This risk gets almost no attention anywhere, and it deserves far more.
“Simplifying” or “modernizing” content during a redesign usually means cutting word count, removing sections, or merging multiple pages into one. That’s exactly the kind of editorial change most likely to land on the content that’s already ranking well – because well-established pages tend to accumulate the most sections over time, making them the biggest visual targets for a design team looking to streamline.
Take the pages flagged earlier as top performers and require explicit SEO sign-off before any editorial team touches their content during the redesign process. A page ranking well because it thoroughly answers a query can lose that ranking fast if half its substance disappears in the name of a cleaner layout – even when every redirect and every technical element around it is flawless.
Is Your Structured Data Ready for AI Search After Migration?
This is genuinely underweighted across most migration guidance, and it’s becoming more consequential every quarter.
Which Schema Types Matter Most
Structured data – machine-readable markup following Schema.org vocabulary – needs to survive the migration intact and validate cleanly on the new platform. Article, Product, FAQ, HowTo, and Breadcrumb schema are the types most commonly used and most commonly dropped or mangled during a CMS switch specifically, since new platforms rarely rebuild markup identically to how the old one implemented it.
Test key page templates with a schema validator both before and after launch – don’t assume a like-for-like rebuild actually preserved everything correctly just because the page looks visually identical.
Why Dropped Schema Hurts AI Overview and Perplexity Visibility Specifically
Traditional search still rewards you for indexing and ranking even with imperfect schema. AI-powered search surfaces are less forgiving. Google’s AI Overviews, Perplexity, and similar tools lean heavily on structured data to accurately summarize and cite your content in generated answers.
If FAQ, HowTo, or Article schema quietly breaks during a migration, your pages can stop appearing in AI-generated answers even while your traditional rankings look completely stable – a visibility loss that won’t show up in standard rank tracking at all, since it’s happening on a different search surface entirely. Check this specifically as part of your post-launch review, not just your traditional SEO checks.
What Should You Monitor After Launch?
Checking Index Coverage and Crawl Errors Daily
Watch your Search Console index coverage report daily for at least the first two weeks. A sudden spike in “not found” or “crawled, not indexed” pages is an early warning sign that something in your redirect map or technical setup is wrong – catching this in days rather than weeks meaningfully limits the total damage.
Tracking Rankings and Traffic Against Baseline
Compare daily rankings and organic traffic directly against the baseline data you captured before migration. Some short-term fluctuation is genuinely normal while search engines reprocess your site. A sustained drop beyond that normal range, across multiple pages, signals a structural problem worth investigating immediately rather than waiting out.
Updating Backlinks and External References
Reach out to the owners of your highest-value referring domains and ask them to update links directly to your new URLs, rather than relying on the redirect indefinitely. A direct link transfers authority faster and more reliably than a permanent redirect chain, even a clean one-hop redirect.
Update your own owned properties too – social media profiles, email signatures, business listings, and any guest posts or press mentions you control directly.
Documenting the Migration for Next Time
Create a short post-migration report covering what went well, what broke, how long the project actually took versus the original estimate, and the final traffic and ranking outcome. Share it with everyone who was involved. This is the single fastest way to make your next migration meaningfully smoother than this one.
Common Site Migration Mistakes That Tank Rankings
Leaving Staging Robots.txt Rules in Production
A robots.txt file written to block all crawlers on staging sometimes gets carried over into production by accident during launch. This is one of the single most common causes of a sudden, total traffic collapse right after a migration – check this file the moment your new site goes live, every single time.
Redirecting Everything to the Homepage
Bulk-redirecting deleted or consolidated pages to your homepage instead of the closest relevant page confuses both users and search engines. Google treats this pattern as a soft signal that the redirect isn’t a genuine content match, weakening the ranking-signal transfer you’re counting on.
Migrating During Peak Traffic Season
Launching a migration during your highest-revenue period turns an ordinary, manageable dip into a genuinely costly event. If you run e-commerce, treat your migration calendar with the same seriousness as your promotional calendar – the two should never overlap.
Your Site Migration Action Plan (7 Steps)
- Classify your migration type and identify which sections of this checklist carry the highest risk for your specific situation.
- Benchmark your current site – traffic, rankings, indexed pages, and Core Web Vitals – at least two weeks before any changes begin.
- Crawl and inventory every existing URL, then build a complete 1:1 redirect map prioritizing your top-performing pages.
- Build and bulk-test your staging environment, confirming every item on the go/no-go checklist passes before scheduling launch.
- Launch during a low-traffic window, enabling redirects, removing crawl blocks, and submitting your new sitemap simultaneously.
- Monitor index coverage, rankings, and traffic daily for at least two weeks, using pre-agreed escalation triggers to guide your response.
- Document the full migration and share the report with every stakeholder involved, for reference on your next project.
FAQ
Does migrating a website hurt SEO permanently?
Not if it’s executed properly. Most migrations cause a temporary dip while search engines re-crawl and re-index the site, and well-executed migrations with complete redirect maps typically recover within weeks to a few months. Permanent losses almost always trace back to incomplete redirects, dropped structured data, or accidentally blocked crawling.
How long does it take to recover rankings after migration?
It varies significantly based on how complete your redirect map is and how much your URL structure changed. A hosting migration with no URL changes might show minimal disruption, while a full domain change with a restructured URL pattern can take several months to fully stabilize, longer if redirects were incomplete.
What’s the difference between a 301 and 302 redirect during migration?
A 301 redirect tells search engines a page has permanently moved and transfers the majority of its ranking signals to the new URL. A 302 redirect signals a temporary move and doesn’t reliably transfer those signals, which is why using 302 for a permanent migration is one of the most damaging redirect mistakes.
Do I need to redirect every single old URL?
Every URL that has a genuine equivalent on the new site should get a 301 redirect. For content with no equivalent anywhere on the new site, use a 410 status code instead of forcing a redirect to an unrelated page – a mismatched redirect confuses both users and search engines more than a clean removal signal does.
Can a site migration actually improve my SEO?
It can, though that’s not guaranteed just by migrating. A clean migration to a faster, better-structured platform can improve Core Web Vitals scores and fix accumulated technical debt like orphaned pages or old redirect chains. Treat ranking preservation as your primary goal, with any improvement as a secondary benefit that follows from doing the technical work correctly.
The Bottom Line on Site Migration SEO
A site migration doesn’t have to cost you the traffic and rankings you’ve spent years building. The sites that come through cleanly aren’t the ones with the fanciest new design – they’re the ones with a complete redirect map, a tested staging environment, and a team that agreed on escalation triggers before anything went live, not during a stressful launch-day scramble.
Work through this checklist in order, and don’t skip the go/no-go gate just because launch day is already on the calendar. A short delay to fix a broken redirect map costs far less than the months of recovery that follow launching with one.
The pages that matter most to your business deserve the most scrutiny during this process, not the least. Protect those first, and the rest of the migration gets meaningfully easier to get right.