Prevent Migration Traffic Loss: 6 Week Site Migration Checklist

The single biggest predictor of a clean site migration is whether every page-level 301 redirect ships on launch day, not after. Before touching development, inventory every URL that earned clicks in the last 12 months, build a redirect map tied to that inventory, and set a firm baseline in analytics. Give yourself a 6-week deadline: if traffic hasn’t started recovering by then, stop waiting and start auditing.

TL;DR:

• Ensuring all page-level 301 redirects are implemented on launch day is critical; delays cause loss of rankings and traffic recovery can take 60 to 120 days if the redirect map is incomplete.
• Conduct a comprehensive pre-migration inventory using 12 months of Search Console data, backlink profiling, and site audits to identify priority URLs and establish baseline KPIs.
• Build the redirect plan by matching each old URL to the most relevant new page or category, implementing server-side redirects, and avoiding redirect chains or gaps.
• Launch preparations must include verifying redirects, disabling staging noindex tags, checking robots.txt, and submitting updated sitemaps to prevent indexing issues.
• Post-launch SEO recovery requires weekly monitoring of key metrics, fixing high-impact redirect errors, canonical issues, and internal link gaps within six weeks to avoid long-term traffic loss.

What Is a Pre-Migration SEO Checklist?

A pre-migration checklist is the inventory and baseline work you complete before a single line of code changes on the new site. Skip this stage and you’re mapping redirects blind, guessing at which pages actually mattered, and setting no measurable line in the sand to judge recovery against.

Start with your data. Export Search Console performance data (queries, pages, clicks, impressions) for a full 12 months, not 90 days. Seasonal service businesses especially need the longer window; a landscaping company’s top page in July looks nothing like its top page in January. Sort by clicks and impressions to build your priority list of value-bearing URLs.

Here’s the sequence that keeps this stage from sprawling into chaos:

1. Export and segment your Search Console data. Pull queries, pages, clicks, and impressions for the trailing 12 months, then flag the top 20% of URLs by traffic. These are your non-negotiable redirect targets.
2. Set numeric KPIs before launch, not after. Document current rankings for your top 20 to 30 keywords, current conversion rate, Core Web Vitals scores, and server response times. You need a “before” snapshot or every post-launch conversation becomes a guessing match.
3. Crawl the live site with a tool like Screaming Frog. Capture canonical tags, current sitemap structure, internal link patterns, and any existing redirect chains already in place. Old redirect chains have a habit of resurfacing during a migration and compounding into new problems.
4. Inventory your backlink profile. Pull your top linked-to pages from Search Console’s Links report or a backlink tool, and flag every URL with meaningful external links. These pages need redirects even if their organic traffic looks modest, because the link equity pointing at them is worth protecting.

Your KPI baseline should cover four categories: keyword rankings for your money terms, conversion volume by channel, Core Web Vitals (LCP, INP, CLS), and server capacity under load. Semrush’s migration checklist frames this stage the same way: audits and baselines first, build second, launch third. Skipping straight to development because a deadline is looming is how teams end up redirecting pages that never mattered while missing the ones that did.

• Confirm which CMS or platform is hosting the new site and whether URL structures will change.
• Document any subdomains, subdirectories, or international versions that need separate mapping.
• List every third-party integration (forms, booking tools, chat widgets) that touches page-level tracking.
• Note any pages currently ranking for featured snippets or rich results, since these are the first to lose visibility if structured data breaks.

Pro Tip: Pull your Search Console export as a spreadsheet, not a screenshot. You’ll need to sort, filter, and cross-reference it against your redirect map dozens of times over the coming weeks, and a screenshot won’t let you do any of that.

How Do You Build and Test a Site Before Launch?

Build the new site on a staging environment that mirrors production, not a stripped-down preview. Block it from public discovery with password protection or IP restriction, but plan a controlled way to let Googlebot crawl it before launch if your team wants pre-indexing validation. This is a deliberate tradeoff: full lockdown is safer against accidental indexing, but it means your first real crawl data arrives on launch day instead of before it.

Run a full technical audit before you consider the build finished. Crawl the staging site with Screaming Frog to catch broken internal links, missing title tags, and orphaned pages. Run Lighthouse or PageSpeed Insights to check Core Web Vitals against your baseline numbers from the previous stage. Validate any structured data changes with the Schema so rich results don’t quietly disappear a week after launch.

A few build-stage tasks that get skipped under deadline pressure and cause disproportionate damage later:

• Confirm every staging page has a noindex tag or is behind authentication, so nothing leaks into Google’s index prematurely.
• Test forms, checkout flows, and any gated content on staging exactly as a user would experience them, not just visually.
• Coordinate with your developers on DNS TTL (time to live) settings; lowering TTL 24 to 48 hours before launch shortens the propagation window if you need to roll back.
• Confirm a full backup of the current production site exists and is restorable, with a documented rollback plan the whole team has actually read.
• Resist the urge to bundle unrelated content changes into the build. Rewriting page copy, restructuring headings, or changing calls to action while URLs are also changing muddies your ability to diagnose what caused any ranking shift after launch.

That last point deserves emphasis because it’s where scope creep does the most quiet damage. A migration is already a controlled experiment with a lot of moving variables. Every content change you layer on top removes your ability to isolate cause and effect when something moves in Search Console three weeks later.

Pro Tip: If your team wants Googlebot to crawl staging before launch, use a temporary robots.txt allowlist tied to Google’s published IP ranges rather than opening the environment to the public internet. It’s more setup work, but it avoids the far more common mistake of forgetting to lock staging back down.

Building a URL Mapping and Redirect Plan That Actually Holds

Page-level redirects, not domain-level ones, are what separate migrations that hold their rankings from migrations that lose six months of traffic. A domain-level redirect (sending every old URL to the new homepage) technically resolves the link, but it tells Google nothing about which new page replaced which old one, and rankings for specific queries tend to evaporate rather than transfer.

Pull your legacy URL list from four sources: Search Console’s performance export, server log files, your analytics platform’s all-time page report, and Archive for any pages that predate your current tracking setup. Cross-reference all four. A URL that shows up in server logs but not in Search Console might still be pulling direct traffic or backlinks worth protecting.

Follow these mapping rules when building the CSV:

1. Match exact content first. If a page’s content and intent survive the migration unchanged, map it one-to-one to its new URL.
2. Consolidate deliberately, not by default. If three old pages are merging into one new page, choose the strongest performer as the redirect target and document why the other two were folded in.
3. Never leave a gap. Every URL with clicks, impressions, or backlinks in the last 12 months needs an explicit destination, even if that destination is a category page rather than a like-for-like match.
4. Record every decision in the mapping file itself. Six weeks post-launch, when you’re auditing a ranking drop, you need to see why a given redirect points where it does, not reconstruct the logic from memory.

Once the map is final, implement server-side 301 (or 308) redirects rather than client-side JavaScript or meta-refresh redirects, which Google crawls less reliably. Google’s own site-move guidance is explicit on this point: prepare the mapping, use server-side permanent redirects, avoid chains, and submit updated sitemaps once the move is live. A redirect chain (URL A to B to C) wastes crawl budget and occasionally breaks outright, so flatten every chain to a single hop before launch.

A practitioner case study covering a 1,500-page site move found that missing page-level redirects, not the domain change itself, was the largest single cause of traffic loss. When redirects shipped weeks after launch instead of alongside it, the site spent months rebuilding signals that a same-day redirect map would have preserved.

Two things matter after implementation that teams routinely forget:

• Keep every redirect live for at least 180 days. Removing them early, even after rankings seem to have stabilized, risks breaking the signal for pages Google hasn’t fully reprocessed.
• Update your own internal links to point at the new URLs directly, rather than relying on the redirect to catch internal clicks. Redirected internal links waste a hop and dilute the signal slightly on every crawl.

What Should Happen on Launch Day for SEO?

Launch during a genuinely low-traffic window for your business, and make sure whoever controls DNS and whoever controls SEO validation are on the same call, not working from separate checklists. Coordinate the DNS switch with your CDN or hosting provider, and confirm cache invalidation happens immediately, not on the next scheduled cache cycle.

Run through this sequence in order, not in parallel:

1. Verify every redirect resolves correctly. Spot-check your highest-traffic URLs first, then run an automated crawl against the full mapping file to catch anything the spot check missed.
2. Remove every noindex and nofollow tag left over from staging. This single step causes more post-launch panic than almost anything else on this list, because a forgotten noindex tag silently blocks reindexing for days before anyone notices.
3. Check robots.txt line by line. Confirm it isn’t still pointing at a staging sitemap or accidentally disallowing sections of the live site.
4. Submit your updated sitemap(s) to Search Console and request indexing for your highest-value URLs individually through URL Inspection.
5. Confirm status codes across your top pages. Every priority URL should return a 200 (or a clean 301 to its mapped destination), never a 404 or a soft 404.

While that’s running, keep a second team watching operational health:

• Test every form, checkout flow, and gated content path exactly as a real visitor would.
• Watch server logs in real time for spikes in 4xx or 5xx errors, which often surface faster there than in any dashboard.
• Use Search Console’s URL Inspection tool on your top 20 to 30 pages to confirm Google sees the live version, not a cached staging artifact.

Nothing on this list is exotic. What causes damage is skipping steps under launch-day pressure, particularly the noindex check, because it’s invisible until someone notices rankings quietly draining a week later.

How Long Does It Take to Recover SEO Rankings After Migration?

Monitor weekly, not monthly, for the first six weeks. Pull clicks, impressions, average position, and index coverage from Search Console every week, and mark your launch date plus any known Google algorithm update dates directly on the chart. Weekly granularity is what lets you tell a migration-caused dip apart from an algorithm-caused one; monthly data smooths over exactly the pattern you need to see.

Watch server logs alongside Search Console data. A spike in crawl requests to old URLs that are returning errors instead of redirects is one of the clearest early warning signs something in the mapping file is incomplete.

If traffic hasn’t started recovering by the six-week mark, stop waiting and start auditing. Practitioners who tracked a 1,500-page migration closely recommend exactly this kind of firm deadline, because “give it more time” is the most common excuse for not catching a redirect gap that’s actively costing rankings. Walk your mapping file URL by URL against live crawl data, and check whether any old pages are still accessible and competing against their replacements in search results.

Prioritize fixes in this order when you find problems:

• Missing or incorrect redirects on high-traffic legacy URLs, since these carry the most equity per fix.
• Canonical tag conflicts, where the new page points its canonical at the wrong URL or, worse, back at a staging domain.
• Internal link pruning that orphaned formerly high-value pages during the redesign.
• Sitemap errors, including stale URLs still listed or new URLs missing entirely.

Set a reporting cadence and stick to it: weekly dashboards for the first six weeks, then a formal audit at 30 days and another at 90 days. Stakeholders tolerate a dip far better when they know exactly when the next check-in happens and what it will measure.

Pro Tip: Build your weekly dashboard before launch, not after. Pulling the same five metrics into the same spreadsheet every Monday takes ten minutes if the template already exists and an hour if you’re rebuilding it from scratch each time.

What’s a Realistic Timeline for SEO Recovery After a Migration?

Recovery timing splits cleanly into three bands depending on how well the redirect map holds up. Published migration benchmarks put well-managed migrations, meaning a complete page-level redirect map shipped at launch, at an initial traffic dip under roughly 15%, with recovery typically landing in the 60 to 120 day range.

Partial redirect coverage tells a rougher story:

• Well-managed migrations: initial dip under about 15%, recovery in 60 to 120 days.
• Partial redirect coverage: dip in the 20% to 40% range, recovery timeline stretches and becomes harder to predict.
• Poor redirect coverage: dip of 50% or more, with recovery sometimes taking months, occasionally over a year.

Two factors outside the redirect map itself tend to lengthen recovery. A large backlink profile means Google has more external links to reprocess and more authority to redistribute across new URLs, which naturally takes longer than a site with a modest link profile. A migration that coincides with an algorithm update also complicates recovery tracking.

Set your “stop waiting” deadline before launch, not during the anxious week six conversation. Six weeks is a reasonable default for most service-business migrations. Larger sites with deeper backlink profiles may justify extending that to eight weeks, but the deadline needs to exist and be written down before launch, or it will keep sliding indefinitely.

What Are the Most Common Site Migration SEO Mistakes?

Most migration failures trace back to one of four root causes, and each has a clear diagnostic and fix.

• Domain-level redirects instead of page-level mapping. Every old URL dumps into the new homepage. Fix: rebuild the redirect map at the page level using your Search Console export as the source list, and reimplement as 301s to matching destinations.
• Robots.txt or noindex blocks left in place. Either the new site inherited a staging noindex tag, or robots.txt is still disallowing sections that should be crawlable. Fix: audit robots.txt and every template’s meta robots tag immediately after launch, not days later.
• A forgotten copy of the old site still live. Staging environments or old subdomains left accessible can compete against the new site in search results. Fix: confirm the legacy environment returns a 410 or is fully deindexed, not just password-protected after the fact.
• Pruned internal links with no redirect backup. A slimmer navigation is a legitimate design choice, but removing links to formerly high-value pages without redirecting or relinking them cuts their discoverability. Fix: cross-check your old internal link map against the new navigation and rebuild links to business-critical pages, following guidance on preserving internal link equity during structural changes.

Each of these is preventable at the checklist stage covered earlier in this guide. Almost none of them are difficult to fix once identified; the damage comes from the delay between the mistake happening and someone noticing it.

Who’s Behind This Migration Guidance?

Todd Stager built this checklist framework from running SEO consulting engagements where the migration itself, not the redesign, was the actual risk. That’s a distinction most agencies gloss over, and it’s the reason this guide treats redirect mapping as the load-bearing task rather than an afterthought to development.

If you want a working template rather than a from-scratch build, Toddstager maintains a step-by-step SEO workflow that pairs with the redirect mapping CSV and weekly monitoring dashboard structure described above. Reach out through Toddstager’s contact channels for access to the mapping template and rollback checklist.

A typical migration engagement scope covers the full arc: pre-migration inventory and baselining, redirect map construction and QA, launch-day coordination with your development team, and the first 90 days of monitoring and remediation. Service businesses replatforming from an older CMS to something like WordPress or a headless setup make up the bulk of this work, precisely because they tend to have the deepest backlink and content history to protect.

Why We Recommend Separating Redesigns From Migrations

Combining a full redesign with a domain or platform move multiplies your risk without multiplying your budget or timeline. When a ranking drops after launch, you need to know whether it moved because the URL changed, the content changed, or the page structure changed. Bundle all three and you lose that diagnostic clarity entirely, which is exactly the pattern reflected in Google’s own community guidance on handling redesigns and moves together.

Sometimes combining them is unavoidable, usually because of a hard business deadline. When that’s the case, we tighten the checkpoints: freeze content changes on any page carrying meaningful traffic, and shorten the weekly review cycle to catch problems faster. We also set explicit checkpoint SLAs with clients before launch, spelling out exactly what gets reviewed at week two, week six, and day 90, so nobody is guessing whether a dip is expected or a red flag.

— TODD

Get Hands-On Help With Your Website Migration

Toddstager runs full-scope migration support for service businesses that need the redirect map, launch coordination, and 90-day monitoring handled by someone who’s already made every mistake on this checklist once. That’s the concrete advantage over piecing it together internally: you get the inventory, the page-level redirect plan, and the weekly dashboard built before launch day, not improvised after a ranking drop.

This work fits agriculture operations, automotive dealers, real estate teams, home builders, and restaurant groups replatforming from an outdated CMS, especially when the backlink profile and content history run deep enough that a domain-level redirect would genuinely hurt. If your business falls into one of those categories, Toddstager’s SEO for Agriculture Businesses page and similar vertical pages outline what a full engagement covers and the outcomes past clients have set as goals. Start with a consultation before your launch date is locked, since redirect mapping takes real lead time and rushing it is how the mistakes covered above happen in the first place.

Where to Verify Migration Guidance and Tools

Cross-check your own plan against Google Search Central’s site-move documentation, which covers the Change of Address tool for domain moves and the official redirect requirements. Use archive.org to pull historical copies of pages you’re rebuilding or verifying, and run any updated structured data through the schema.org validator before launch. For crawling and diagnostics, Screaming Frog and Google’s Lighthouse remain the standard pairing for catching broken links, redirect chains, and Core Web Vitals regressions before they reach production.

Sources

• Site moves and migrations | Google Search Central
• The Complete Website Migration Checklist SEO-Friendly

Recommended

• Technical SEO checklist 2026: boost small business visibility
• SEO-Friendly URL Checklist: 2026 Best Practices Guide
• SEO Checklist for 2026: Small Business Growth Guide
• SEO Maintenance Tasks List for Small Businesses 2026