SEO Migration Checklist: The Complete Guide to Moving Without Losing Traffic
A site migration is one of the highest-risk operations in SEO. Done poorly, it can wipe out years of ranking authority in a matter of days. Done well, it preserves your traffic, passes link equity cleanly, and sometimes even improves rankings. The difference between the two outcomes almost always comes down to preparation — specifically, how thoroughly you followed an SEO migration checklist before, during, and after launch.
This guide covers every phase in detail: from crawling your current site to post-migration monitoring over the first four weeks. Use it whether you are changing domains, switching CMS platforms, moving from HTTP to HTTPS, or restructuring your URL hierarchy.
Why Site Migrations Kill Rankings
Google evaluates URLs, not websites. When a URL changes, Googlebot must discover the new URL, follow any redirect, reprocess the content, and re-evaluate signals before it will rank the new URL similarly to the old one. That re-evaluation takes time — typically weeks to months — and every additional error compounds the delay.
The most common migration killers work together in destructive ways. A missing 301 redirect means the old URL returns a 404, destroying any link equity pointing to it. A 302 temporary redirect instead of a 301 tells Google to keep the old URL in its index rather than transfer ranking signals to the new one. A redirect chain — where /old-url redirects to /interim-url which redirects to /new-url — dilutes equity at each hop and slows crawling. And if the staging environment leaks noindex tags onto the live domain, or the production robots.txt mistakenly blocks Googlebot, rankings can collapse within days of launch.
Industry data consistently shows that major migrations with poor SEO preparation lose 20 to 50 percent of organic traffic in the first month. Many never fully recover. The migrations that emerge unscathed share one characteristic: they treated SEO as a pre-migration engineering requirement, not a post-launch cleanup task.
What Counts as an SEO Migration
Not every website change is a migration, but far more qualify than most teams expect. Any of the following triggers an SEO migration protocol:
- Domain change — moving from example.com to newbrand.com, including rebrands
- Protocol change — moving from HTTP to HTTPS (even if the domain stays identical)
- Subdomain consolidation or split — merging blog.example.com into example.com/blog, or the reverse
- URL structure changes — adding or removing /category/, changing slug formats, flattening or deepening hierarchy
- CMS platform migration — moving from WordPress to Webflow, or Shopify to a custom stack, even if the domain stays the same
- Staging to production launch — a common overlooked case where staging errors survive into live deployment
- Redesign with URL restructuring — even partial URL changes require redirect mapping for the changed pages
If even one of the above applies, you need this checklist. Partial migrations are still migrations — the SEO impact of missing 50 redirects is the same whether you changed 50 URLs or 50,000.
Pre-Migration Checklist: Baseline and Audit
Before you change a single URL, document everything about your current site. This baseline is your insurance policy — if something breaks post-migration, you need to know what "normal" looked like.
Start with a full site crawl using Screaming Frog, Ahrefs Site Audit, or a similar crawler. Export the complete URL inventory: every URL, its status code, title tag, canonical URL, meta robots directive, and internal link count. Save this file. You will reference it dozens of times during redirect mapping and post-launch verification.
Then pull your current performance data from Google Search Console. Export the full Search Analytics report (last 16 months if available) filtered by page. This gives you a ranked list of your most valuable pages by clicks, impressions, and average position. These are your highest-priority pages for redirect mapping and post-migration monitoring.
Export your backlink profile from Ahrefs or GSC Links report. Focus on which URLs receive external links from high-authority domains — these pages carry the most link equity and must have airtight 301 redirects. Screenshot the current GSC Index Coverage report so you have a visual baseline for the error/valid split before migration.
Finally, document all redirects currently in place on the live site. These existing redirects need to be migrated to the new server configuration and validated — a redirect that worked on your old Apache server may behave differently on your new Nginx setup.
Pre-Migration: Redirect Mapping
Redirect mapping is the most labor-intensive part of SEO migration preparation and the most important. A redirect map is a spreadsheet with two columns: old URL, new URL. Every URL that is changing needs an entry. Every URL that is disappearing needs an entry pointing to the most relevant surviving page.
Build your map in priority order. Start with the pages that drive the most organic traffic — your GSC export tells you exactly which these are. Then add pages with the most external backlinks. Then add the remaining pages from your crawl export. For a site with thousands of URLs, you may need to use URL pattern matching to create redirect rules (e.g., /blog/[year]/[month]/[slug]/ redirects to /blog/[slug]/) rather than mapping every URL individually.
Pay particular attention to structural URLs: category pages (/category/[name]/), tag pages (/tag/[name]/), paginated pages (/page/2/), author archives, and date archives. These are frequently orphaned in migrations and rarely catch the attention of the team because they drive modest traffic individually — but collectively they hold significant crawl equity and internal linking structure.
Once your redirect map is complete, implement it in staging and run your crawler again against staging. Verify that every old URL returns a 301 to its mapped destination, that no redirect chains exist (A redirects to B which redirects to C), and that no redirect loops exist (A redirects to B which redirects to A). Fix all issues before go-live.
Pre-Migration: Staging Environment SEO
Your staging environment must be completely invisible to search engines. If Googlebot crawls and indexes staging URLs before migration, you can end up with duplicate content issues and diluted rankings. If staging URLs appear in the index after migration, you have a canonicalization problem that can take months to clean up.
Use one of two methods — ideally both together. First, block the staging environment at the robots.txt level:
# robots.txt for staging environment User-agent: * Disallow: / # Block all crawlers from indexing staging
Second, add a noindex meta tag to every page template on staging. Using only robots.txt is insufficient because Googlebot can still discover and attempt to index staging URLs from external links — the noindex tag provides a second layer of protection. Together they ensure staging content never pollutes the live index.
Do not submit a staging sitemap to Google Search Console under any circumstance. If the staging domain was ever accidentally added to GSC, remove it before go-live. Also verify that no staging URLs have been shared publicly in blog posts, social media, or documentation — external links to staging can pull Googlebot there regardless of your robots.txt.
Pre-Migration: Technical Checks on the New Site
Before go-live, run through every technical SEO element on the new site in staging. These checks catch the configuration errors that most commonly cause post-migration ranking drops:
Canonical tags: every page's canonical tag must point to its new URL on the new domain. If you copied templates from the old site, canonical tags may still reference old domain URLs — a systematic error that will prevent Google from consolidating ranking signals to the new site.
Hreflang: if you have a multilingual site, every hreflang annotation must be updated to the new URL pattern. Hreflang errors cause international traffic to drop and can trigger incorrect-page-in-SERP issues in non-English markets.
Internal links: crawl the new site and verify that no internal links still reference old-domain URLs. Every internal link should resolve natively without triggering a redirect — internal redirect chains slow crawling and dilute PageRank unnecessarily.
XML sitemap: generate a fresh sitemap from the new site and verify it contains only new URLs returning 200 status codes. No redirect URLs, no noindex URLs, no 404 URLs should appear in the sitemap.
Structured data: any schema markup referencing the old domain's URL (in url, mainEntityOfPage, or sameAs fields) must be updated. Run your new pages through Google's Rich Results Test to verify structured data validates correctly.
Page speed: run Core Web Vitals testing on the new site before launch. Migrations often involve new hosting infrastructure — a new server, CDN configuration, or rendering stack can introduce performance regressions that hurt rankings independently of the URL changes.
Go-Live Day: Migration Execution
The sequence of deployment steps on go-live day matters. Deploy in the wrong order and you create a window where users and Googlebot hit 404 errors or reach an unredirected old URL. The correct sequence is: redirects first, then content.
Before flipping DNS or deploying new content, push your entire redirect map to the server. This ensures that even if a user or crawler hits an old URL during the transition window, they get a 301 rather than a 404. Then deploy the new site, verify it is live, and immediately check that the production robots.txt is not blocking crawlers — this is the single most catastrophic go-live error and it happens more often than you would expect.
Submit your new sitemap to Google Search Console within the first hour of launch. Use the GSC URL Inspection tool on your five highest-priority pages to verify Googlebot can access and index them. If URL Inspection returns a crawl error or soft 404, investigate immediately — do not wait for the weekly crawl report.
Enable server log monitoring if your infrastructure supports it. Watching real-time Googlebot requests on go-live day lets you catch crawl errors, unexpected 404 patterns, and redirect failures as they happen rather than days later in GSC reports.
Post-Migration: First 48 Hours
The first 48 hours after go-live are the highest-alert period. Most critical errors surface quickly — Googlebot typically starts crawling a newly launched site within hours of sitemap submission.
Open GSC and monitor the Index Coverage report continuously. Any sudden spike in "Excluded" or "Error" URLs is a signal that redirects are missing, pages are returning unexpected status codes, or a robots.txt or noindex problem has survived into production. The most dangerous error to see here is "Blocked by robots.txt" — that means your production robots.txt is blocking Googlebot and must be fixed within minutes, not hours.
Spot-check your redirect map by testing 20 to 30 old URLs manually. Confirm they return HTTP 301 (not 302, not 307) and resolve to the correct new URL in a single hop with no chains. A tool like Redirect Checker or your crawler of choice can batch-verify this. Pay particular attention to your top 10 traffic pages and top 10 backlinked pages — these are where errors are most costly.
Check organic traffic in GA4 every few hours on go-live day and the day after. Some fluctuation is expected as Google re-processes URLs, but a drop of more than 30 percent within 24 hours is a red flag that something is systemically wrong — typically a robots.txt block, a mass noindex issue, or a redirect deployment failure.
Post-Migration: First Four Weeks
Most of the post-migration monitoring work happens in the four weeks following go-live. This is the window during which Google is actively re-evaluating your new URLs and deciding which signals transfer from the old ones.
Resubmit your sitemap to GSC weekly for the first month. Use the URL Inspection > Request Indexing feature for your highest-priority pages — priority pages are those with the most traffic and backlinks, which you identified in pre-migration baselining. Don't request indexing for every page; focus on the 20 to 50 pages that matter most for revenue and traffic.
Monitor GSC Search Analytics weekly and compare to your pre-migration baseline export. Look for individual pages that have dropped significantly in impressions or clicks — these are candidates for redirect investigation. A page that had 1,000 weekly impressions pre-migration and now shows zero is almost certainly hitting a redirect or indexation problem.
Check your backlink profile in Ahrefs or a similar tool. External backlinks to old URLs should now pass through 301 redirects to new URLs. If high-DR domains are linking to old URLs that currently 404, you are losing significant link equity — contact those sites and request a direct link update to the new URL, as 301s pass equity with some loss compared to a direct link.
Update all external profiles that reference your old URLs: Google Business Profile, social media bios, directory listings, partner sites, and any press mentions where you have editorial access. Each direct link update converts a redirect-mediated link into a clean link that passes full equity.
Common Migration Mistakes and How to Avoid Them
Even experienced SEO teams make predictable mistakes during migrations. Here are the five most damaging ones and how to prevent each:
Temporary redirects (302) instead of permanent (301). A 302 tells Google the move is temporary and to keep ranking the old URL. Use 301s exclusively for permanent URL changes. If your server configuration file accidentally defaults to 302, your ranking signals will not transfer. Verify redirect type with a header-checking tool after deployment.
Forgetting to update internal links. Internal links to old URLs that now 301 to new URLs add unnecessary redirect hops to every crawl path. Update internal links to point directly to new URLs — your CMS search-and-replace or a crawler-assisted link audit can handle this at scale.
Noindex surviving on the live site. If a noindex meta tag or X-Robots-Tag was applied during staging and was not removed for production, pages will be excluded from the index silently. Always run a post-launch crawl specifically checking for meta robots directives on every page.
Missing hreflang updates. On multilingual sites, hreflang annotations in the old domain format — or pointing to staging URLs — cause Googlebot to serve the wrong language variant in international SERPs. Audit hreflang tags as a separate check after launch.
Stopping monitoring too soon. Many teams check GSC for a week, see things stabilizing, and move on. Migration impacts can surface four to six weeks post-launch as Google's crawl queue processes the full site. Commit to at least a four-week monitoring cadence before declaring the migration complete.
SEO Migration Checklist Summary
Use this master checklist across all three migration phases. Check off each item before proceeding to the next phase.
Pre-Migration
- Crawl current site and export full URL inventory with status codes
- Document all canonical URLs on current site
- Export GSC Search Analytics (last 16 months) by page
- Export backlink targets from Ahrefs or GSC Links report
- Screenshot current GSC Index Coverage report as baseline
- Document all existing redirects on live site
- Build complete redirect map (old URL to new URL) for every changed URL
- Test redirect map in staging — verify 301s, no chains, no loops
- Block staging with robots.txt Disallow: / AND noindex meta tag
- Verify staging sitemap has NOT been submitted to GSC
- Update all canonical tags to new domain/URL structure
- Update all hreflang annotations to new URLs
- Update all internal links to new URLs directly
- Generate and validate new XML sitemap (200s only)
- Update structured data URLs and validate in Rich Results Test
- Run Core Web Vitals test on new site
Go-Live
- Deploy redirect map to production before content goes live
- Verify production robots.txt allows crawling (Disallow: removed)
- Submit new sitemap to Google Search Console within one hour of launch
- Run URL Inspection on top 5 priority pages in GSC
Post-Migration
- Check GSC Index Coverage for error spikes within 24 hours
- Verify redirects return 301 (not 302) and have no chains
- Monitor GA4 organic traffic daily for first two weeks
- Resubmit sitemap and request indexing for priority pages weekly
- Compare GSC Search Analytics weekly against pre-migration baseline
- Verify backlinks now resolve to new URLs via Ahrefs audit
- Update external profiles and directory listings to new URLs
- Continue monitoring for full four weeks post-launch