The SEO Migration Checklist: 47 Steps to Prevent Traffic Loss During a Site Move

You rebuilt your website. New design, new CMS, faster load times, better user experience. You launched it on a Friday afternoon. By Monday, organic traffic dropped 40%. By the end of the month, half of your top-ranking pages had fallen off the first page of Google. Your CEO is asking what happened. Your SEO manager is updating their resume.

Site migrations are the highest-risk SEO events a company can go through. A domain change, CMS migration, redesign, URL restructuring, or HTTPS conversion all qualify. Each one carries the potential to destroy years of accumulated search equity in a single deployment. The good news is that traffic loss during a migration is almost entirely preventable. The bad news is that it requires methodical preparation that most teams underestimate. This checklist covers 47 specific steps across seven phases, from pre-migration planning through post-migration monitoring, that prevent the mistakes responsible for 90% of migration-related traffic drops.

Types of Site Migrations and Their Risk Levels

Not all migrations carry the same risk. Understanding which type of migration you are performing determines which steps are critical and which can be simplified.

Domain change (example.com to newexample.com): Highest risk. Every URL changes. All backlinks point to the old domain. Google must re-evaluate the entire site. Expect 4-12 weeks of volatility even with perfect execution.

Protocol change (HTTP to HTTPS): Moderate risk. URLs change but the domain and path structure stay the same. Google handles HTTPS migrations fairly well, but misconfigurations can cause indexing issues.

CMS migration (WordPress to Next.js, for example): High risk. URL structures often change. Content may be reformatted. Internal linking structures may break. Templates change, affecting structured data and meta tags.

URL restructuring (changing URL patterns without changing domain or CMS): Moderate risk. The content stays the same, but Google needs to re-crawl and re-index every changed URL. Redirect accuracy is critical.

Design refresh (same URLs, same CMS, new templates): Low risk if URLs do not change. However, template changes can inadvertently remove structured data, alter heading hierarchy, or change content rendering in ways that affect rankings.

Phase 1: Pre-Migration Audit (Steps 1-10)

The pre-migration audit establishes your baseline and identifies everything that needs to be preserved. Skip this phase and you will not know what you lost until it is too late to recover it.

Step 1: Crawl the Current Site Completely

Use Screaming Frog, Sitebulb, or a similar crawler to crawl your entire current site. Export the complete list of URLs with status codes, titles, meta descriptions, H1 tags, canonical tags, word counts, and internal links. This crawl is your source of truth for the migration. Every URL in this crawl must be accounted for in the new site.

Step 2: Export Google Search Console Performance Data

Pull 16 months of performance data from Google Search Console: pages, queries, clicks, impressions, CTR, and average position. This data establishes your traffic baseline and identifies your most valuable pages. Export it and store it permanently because GSC only retains 16 months of data. After a migration, you need this historical data to measure impact.

Step 3: Identify Top-Performing Pages

From the GSC data, identify your top 100 pages by organic traffic. These pages get extra scrutiny during the migration. Every element that contributes to their rankings (title tag, meta description, heading structure, content, internal links, backlinks, structured data) must be preserved exactly in the new site. A single change to a top-performing page's title tag can drop it from position 3 to position 15.

Step 4: Audit Current Backlink Profile

Export your complete backlink profile from Ahrefs, Moz, or SEMrush. Identify every page that receives external backlinks. These pages need 301 redirects to their new URLs or must maintain the same URL. Backlinks are the hardest SEO asset to rebuild if lost, and a migration without redirect coverage for linked pages forfeits all of that equity.

Step 5: Document Current Structured Data

Crawl the site and extract all structured data (JSON-LD, microdata, RDFa). Document which pages have which types of structured data: Article, Product, FAQ, HowTo, BreadcrumbList, Organization, LocalBusiness. New templates must implement the same structured data. Missing structured data after migration can cause rich snippet loss, which directly reduces click-through rates.

Step 6: Capture Current Internal Linking Structure

Use your crawl data to map the internal linking structure. Which pages link to which other pages? What is the average internal link depth for top-performing pages? What are the most linked-to internal pages? The new site's navigation and internal linking must provide at least the same level of internal link equity to your important pages.

Step 7: Document Current Robots.txt and Sitemap

Save copies of your current robots.txt file and XML sitemaps. The new site needs equivalent (but updated) versions. A common migration mistake is deploying with a staging robots.txt that blocks all crawlers, or deploying without a sitemap.

Step 8: Inventory All Meta Tags

Export title tags and meta descriptions for every page. These should be migrated 1:1 to the new site. New templates sometimes auto-generate meta tags from content, overwriting carefully optimized tags. Verify that existing meta tags are preserved, not replaced by template defaults.

Step 9: Check Existing Redirects

Your current site likely has existing redirect rules from previous URL changes or content consolidation. Export all current redirects. These must be carried forward to the new site. If old redirects point to URLs that are also changing, update them to point to the final destination to avoid redirect chains.

Step 10: Benchmark Performance Metrics

Record Core Web Vitals (LCP, FID/INP, CLS), page load times, and crawl stats from GSC for the current site. These become your performance baseline. The new site should meet or exceed these metrics. A faster site can actually gain traffic post-migration if it improves user experience signals.

Phase 2: URL Mapping (Steps 11-17)

URL mapping is the most critical and most tedious phase of any migration. Every old URL must map to a corresponding new URL. There are no shortcuts. Automated mapping tools can help with bulk changes, but every mapping must be verified because a single wrong redirect can orphan a page that generates thousands of monthly visits.

Step 11: Create a Complete URL Mapping Spreadsheet

Build a spreadsheet with four columns: old URL, new URL, old page traffic (from GSC), and old page backlinks (from backlink audit). Sort by traffic descending. The highest-traffic pages get mapped first and get the most verification. Low-traffic pages with zero backlinks can be mapped with regex rules, but high-value pages need manual verification.

Step 12: Map URL Pattern Changes

If your URL structure is changing systematically (e.g., /blog/post-name to /resources/articles/post-name), document the pattern rules. These rules can be implemented as regex redirects. But test every regex rule against your URL list to ensure no edge cases produce incorrect redirects.

Step 13: Handle Consolidated Pages

If you are merging multiple old pages into a single new page, redirect all old URLs to the consolidated page. Document which pages were merged and why. The consolidated page should contain the best content from all merged pages to preserve topical coverage.

Step 14: Plan for Removed Pages

Some pages may not have equivalents in the new site. For pages with traffic or backlinks, either keep them or redirect to the most relevant alternative. For pages with no traffic and no backlinks, a 410 (Gone) response is appropriate. Never return a 404 for a page that has backlinks unless you are comfortable losing that equity.

Step 15: Verify Query Parameter Handling

If the old site uses query parameters for pagination, filtering, or tracking (e.g., ?page=2, ?category=analytics, ?utm_source=google), ensure the new site handles these correctly. Google may have indexed parameterized URLs. Redirect them to the appropriate new URLs or implement canonical tags.

Step 16: Check for Case Sensitivity Issues

URLs are case-sensitive. If the old site served /About-Us and the new site serves /about-us, that is a different URL and needs a redirect. Check your URL mapping for case mismatches. CMS migrations frequently introduce case changes that break URLs.

Step 17: Handle Trailing Slashes Consistently

Decide whether the new site uses trailing slashes (/blog/post/) or not (/blog/post) and enforce it consistently. If the old site used one convention and the new site uses another, implement redirects. Mixed trailing slash behavior creates duplicate content issues.

Phase 3: Redirect Implementation (Steps 18-24)

Step 18: Use 301 Redirects, Not 302

Permanent moves require 301 (permanent) redirects. A 302 (temporary) redirect tells Google the old URL might come back, so it keeps the old URL indexed and does not transfer full equity to the new URL. This is the single most common redirect mistake in migrations.

Step 19: Implement Redirects at the Server Level

Implement redirects in the web server configuration (nginx, Apache) or at the CDN level (Vercel, Cloudflare, Netlify). JavaScript redirects and meta refresh redirects are not followed reliably by search engines. Server-level redirects are the fastest and most reliably processed.

Step 20: Avoid Redirect Chains

A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each hop in the chain loses a small amount of link equity and adds latency. Review your redirect map for chains and collapse them so every old URL points directly to its final destination. If old redirects from previous migrations exist, update them to point to the new final URLs.

Step 21: Test Every Redirect Before Launch

Use a redirect testing tool or script to verify every redirect in your mapping. Test for: correct status code (301), correct destination URL, no redirect chains, no redirect loops, and proper handling of query parameters. Test at least 100% of high-traffic page redirects and a random 20% sample of remaining redirects.

Step 22: Implement Wildcard Redirects as Fallbacks

After implementing 1:1 redirects for all mapped URLs, add wildcard redirect rules as fallbacks for URLs you might have missed. For example, redirect all old blog URLs that do not have a specific mapping to the new blog index page. This is a safety net, not a replacement for proper mapping.

Step 23: Handle Image and Asset Redirects

Images, PDFs, and other assets that were indexed or linked externally need redirects too. If your image URLs change (common in CMS migrations), redirect old image URLs to new ones. Google Image Search traffic and hotlinked images depend on these redirects.

Step 24: Set Up Redirect Monitoring

After launch, monitor redirect performance. Track 404 errors in GSC, server logs, and analytics. Any 404 on a URL that should have a redirect indicates a gap in your mapping. Set up alerts for spikes in 404 errors so you can fix them quickly.

Phase 4: Technical SEO Setup (Steps 25-32)

Step 25: Verify Robots.txt on the New Site

Check that the new site's robots.txt allows crawling of all important sections. Staging robots.txt files that block all bots are a common cause of post-migration deindexing. Verify the file at yourdomain.com/robots.txt immediately after launch.

Step 26: Submit Updated XML Sitemaps

Generate new XML sitemaps with all new URLs. Submit them through GSC. Keep the old sitemaps active temporarily (with the old URLs still listed) to help Google discover the redirects. After Google has processed the redirects (check GSC coverage reports), you can remove the old sitemaps.

Step 27: Update Canonical Tags

Every page on the new site must have a self-referencing canonical tag with the new URL. Check that no pages carry over canonical tags pointing to old URLs. Incorrect canonicals after migration cause Google to ignore the new URLs and try to index the old ones, which return redirects.

Step 28: Verify Hreflang Tags (If International)

If you have multi-language or multi-region pages, update all hreflang annotations to use the new URLs. Hreflang tags pointing to old URLs create signals that conflict with your redirects and confuse Google about which version to serve in each market.

Step 29: Implement Structured Data on New Templates

Re-implement all structured data from the audit (Step 5) on the new templates. Test with Google's Rich Results Test. Missing structured data after migration is one of the most common oversights and directly impacts CTR from search results.

Step 30: Check Internal Links

Crawl the new site and verify all internal links use new URLs directly, not old URLs that redirect. Internal links through redirects work but waste crawl budget and dilute equity. Update all internal links in content, navigation, footer, and sitemaps to point to new URLs.

Step 31: Verify Core Web Vitals

Run Lighthouse and PageSpeed Insights on the top 20 pages of the new site. Compare against the baseline from Step 10. If any Core Web Vital is significantly worse, fix it before launch. A migration that degrades performance can trigger ranking drops from both the migration disruption and the performance decline.

Step 32: Test Mobile Rendering

Google uses mobile-first indexing. Test the new site's mobile rendering for all page types. Check that content is not hidden behind tabs, accordions, or JavaScript that fails to render on mobile. Use Google's Mobile-Friendly Test and manual testing on actual devices.

Phase 5: Content Verification (Steps 33-38)

Step 33: Verify All Content Migrated

Cross-reference your crawl from Step 1 against the new site. Every page should either exist on the new site or have a redirect. Use a script or spreadsheet to compare URL lists. Any URL in the old crawl that is not in the new site and does not have a redirect is a gap that will cause traffic loss.

Step 34: Compare Content on Top Pages

For your top 50 pages, manually compare old and new versions. Check that content is complete (nothing truncated during migration), heading hierarchy is preserved, images are present and loading, and no content was accidentally altered. CMS migrations often introduce encoding issues, missing images, or broken formatting.

Step 35: Verify Title Tags and Meta Descriptions

Compare the title tags and meta descriptions from your Step 8 inventory against the new site. Any mismatches need to be corrected before launch. Template-generated meta tags are a common source of regressions.

Step 36: Check Heading Structure

Verify that each page has a single H1 and a logical heading hierarchy. New templates sometimes introduce multiple H1 tags or skip heading levels. While heading structure is not a strong ranking factor in isolation, combined with other on-page changes during a migration, it can contribute to ranking shifts.

Step 37: Verify Image Alt Text

Check that image alt text migrated correctly. CMS migrations sometimes strip alt attributes or replace them with filenames. Alt text contributes to image search rankings and accessibility compliance.

Step 38: Test All Forms and Interactive Elements

Ensure all forms, calculators, embedded tools, and interactive content work on the new site. Broken conversion elements do not directly affect SEO rankings but destroy the business value of organic traffic.

Phase 6: Launch Day (Steps 39-43)

Step 39: Launch During Low-Traffic Hours

Deploy during your lowest-traffic window (usually Tuesday or Wednesday at 2-4 AM in your primary market). This minimizes user impact if issues arise and gives you business hours to monitor and fix problems before traffic peaks.

Step 40: Verify Redirects Are Active

Immediately after deployment, test a sample of 50-100 redirects manually. Spot-check high-traffic pages, pages with backlinks, and random pages from each URL pattern. Verify status codes are 301 and destinations are correct.

Step 41: Submit Sitemaps and Request Indexing

Submit new sitemaps through GSC. Use the URL Inspection tool to request indexing of your top 20-30 pages. This accelerates Google's discovery of the new URL structure. For domain changes, use GSC's Change of Address tool.

Step 42: Verify Analytics Tracking

Confirm that Google Analytics, conversion tracking, and any other analytics tools are firing correctly on the new site. Use real-time reports to verify data is flowing. A migration that breaks analytics tracking creates a data gap that makes post-migration analysis impossible.

Step 43: Monitor Server Logs

Watch server logs for the first 24-48 hours. Look for spikes in 404 errors, 500 errors, or unusual crawler behavior. Googlebot will start hitting redirects and crawling new URLs within hours of launch. Any errors in logs need immediate attention.

Phase 7: Post-Migration Monitoring (Steps 44-47)

Step 44: Daily Ranking Monitoring for 30 Days

Track rankings for your top 100 keywords daily for the first 30 days. Some volatility is expected. Rankings may dip temporarily as Google processes redirects and re-evaluates the site. However, a sustained decline (more than 5 positions for more than 7 days) on important keywords indicates a problem that needs investigation.

Step 45: Monitor GSC Coverage Report Weekly

Check the GSC Coverage report weekly. Watch for increases in "Excluded" or "Error" pages. GSC will show you which URLs are being redirected, which are returning errors, and which are being indexed. The transition from old URLs to new URLs should be visible in this report over 2-4 weeks.

Step 46: Compare Organic Traffic Weekly for 90 Days

Compare weekly organic traffic against your pre-migration baseline. Account for seasonality by comparing to the same period in the previous year. A well-executed migration should show stable or increasing traffic within 4-6 weeks. If traffic has not recovered by week 8, there is likely a systematic issue that needs diagnosis.

Step 47: Audit Backlink Equity Transfer

After 60-90 days, check your backlink profile in Ahrefs or SEMrush. Compare the Domain Rating (or Domain Authority) against pre-migration levels. Verify that major backlinks now point to the new URLs (either directly or through redirects). If backlink equity has dropped significantly, investigate whether redirects are working correctly for linked pages.

Emergency Response: When Traffic Drops Post-Migration

If you followed this checklist and still see a traffic drop, here is the diagnostic sequence. First, check for missing redirects by crawling old URLs and verifying they return 301s. Second, check for noindex tags or robots.txt blocks that might be preventing indexing. Third, verify that canonical tags point to the correct new URLs. Fourth, check if content has changed significantly on top pages. Fifth, verify that server response times have not degraded. Sixth, check for duplicate content issues caused by both old and new URLs being accessible.

Most migration-related traffic drops have a single root cause. The diagnostic challenge is finding it among hundreds of URLs and thousands of redirects. Work systematically through the diagnostic sequence, starting with the most common causes (missing redirects, blocking rules) before investigating less common ones (content changes, performance issues).

Site migrations do not have to be traumatic. The teams that experience devastating traffic drops are almost always the ones that treated SEO as a post-launch concern rather than a pre-migration discipline. Every step in this checklist exists because someone, somewhere, skipped it and lost traffic as a result. The checklist is the accumulated wisdom of migration failures. Following it is not complicated. It is tedious, detail-oriented work that does not feel productive until you compare your outcome against the alternative. A clean migration with zero traffic loss is not exciting. But a 40% traffic drop that takes six months to recover is the kind of exciting nobody wants.