SEO Migration Checklist: How to Move Your Website Without Losing Rankings

Website migrations are one of the highest-risk activities in digital marketing. Change your domain, restructure your URLs, switch CMS platforms, or move to HTTPS---and you can watch years of organic search equity evaporate in days if the migration is handled poorly.

The stakes are real. Google's own documentation on site moves with URL changes acknowledges that "a medium-sized website can take a few weeks for most pages to move" and warns against common mistakes like forgotten noindex tags, incorrect redirect destinations, and insufficient server resources during the transition.

Yet migrations are often necessary. Platform upgrades, rebrands, domain consolidations, security improvements (HTTP to HTTPS), and structural overhauls all require some form of URL change. The question isn't whether to migrate---it's how to do it without giving back the organic traffic you've spent years building.

This SEO migration checklist walks through every phase---from pre-migration audit to 90-day post-launch monitoring---with the specific technical steps that protect your rankings. At Sunrise Digital Labs, we handle website migration services for clients who can't afford to lose their search presence, and this checklist reflects what we've learned from real migrations.

What Counts as an SEO Migration?

Not every website change qualifies as a migration. An SEO migration specifically involves changes that affect how search engines discover, crawl, and index your content. Common migration types include:

• Domain change: Moving from oldsite.com to newsite.com (rebrands, acquisitions)
• Protocol change: HTTP to HTTPS (security upgrade)
• URL restructure: Changing URL patterns (e.g., /blog/2024/post-title to /resources/post-title)
• CMS migration: Switching platforms (WordPress to Next.js, Shopify to custom, etc.)
• Site architecture overhaul: Reorganizing navigation, merging sections, or splitting a site
• Subdomain to subfolder: Moving blog.example.com to example.com/blog
• International expansion: Adding hreflang tags, country-specific subdomains, or subdirectories

Each type carries different risk levels, but all require the same fundamental approach: map every URL change, implement proper redirects, and monitor recovery metrics.

Phase 1: Pre-Migration Audit (4--6 Weeks Before Launch)

The pre-migration phase determines whether your migration succeeds or fails. Rushing this phase is the single most common cause of migration disasters.

1.1 Complete Site Crawl and URL Inventory

Before you change anything, you need a complete inventory of every URL on your current site. This isn't just your sitemap---it's every page Google knows about.

Data sources to combine:

• Crawl data: Use a crawler like Screaming Frog SEO Spider to crawl your entire site. Export all 200-status URLs, including response codes, canonical tags, meta robots directives, page titles, and H1s.
• Google Search Console: Export the full list of indexed pages from the "Pages" report. This catches pages your crawler might miss (orphan pages, pages blocked by internal linking gaps).
• Google Analytics: Pull a 12-month report of all pages that received organic traffic. Pages with zero traffic in 12 months may not need redirects, but pages with any organic visits need to be mapped.
• XML sitemaps: Download your current sitemaps and compare against crawl data. Discrepancies indicate sitemap maintenance issues that should be fixed pre-migration.
• Backlink data: Export your top pages by referring domains from any backlink tool. These high-authority pages are your highest-priority redirect targets.

Deliverable: A master URL spreadsheet with columns for current URL, HTTP status, canonical URL, organic traffic (12 months), referring domains, and priority level (high/medium/low).

1.2 Benchmark Current Performance

You need a pre-migration performance baseline to measure recovery against. Capture these metrics at least 4 weeks before migration:

• Organic traffic: Total sessions and users from organic search (weekly granularity)
• Keyword rankings: Track your top 100--500 keywords by position
• Indexed pages: Total pages indexed in Google Search Console
• Core Web Vitals: LCP, FID/INP, and CLS scores from Google Search Console
• Crawl stats: Pages crawled per day, average response time, crawl errors
• Top landing pages: Your 50 highest-traffic organic landing pages and their traffic trends
• Conversion rates: Organic conversion rates by page or section

Store these benchmarks in a format you can compare against post-migration. You'll reference them for at least 90 days after launch.

1.3 Identify Technical SEO Elements to Preserve

During migration, it's easy to lose technical SEO elements that took months to implement. Audit and document:

• Structured data (schema markup): List every page with schema markup and the type used (Article, Product, FAQ, LocalBusiness, etc.)
• Canonical tags: Document which pages use canonical tags and where they point
• Hreflang annotations: If you have international versions, map all hreflang relationships
• Meta robots directives: Note any pages with noindex, nofollow, or other directives
• Internal linking structure: Document your key internal link paths, especially pillar-cluster relationships
• Robots.txt rules: Save a copy of your current robots.txt
• XML sitemap structure: Document your sitemap hierarchy (index sitemap, sub-sitemaps)

1.4 Content Audit

Migration is the right time to prune, consolidate, and improve content---but do it deliberately, not accidentally.

• Identify thin or duplicate content: Pages with fewer than 300 words, near-duplicate pages, or outdated content can be consolidated or removed during migration.
• Map content to new structure: If your site architecture is changing, map every existing piece of content to its new location. Content that doesn't fit the new structure should be consciously deprecated (with redirects) rather than silently dropped.
• Preserve high-performing content: Any page generating organic traffic or earning backlinks must maintain its content quality through the migration. Don't "refresh" high-performing content during migration---that introduces an uncontrolled variable.

Phase 2: Redirect Mapping (3--4 Weeks Before Launch)

Redirects are the backbone of any SEO migration. Get them right, and you preserve most of your search equity. Get them wrong, and rankings can take months or years to recover.

2.1 The Redirect Strategy

Google's redirect documentation is clear on the preferred approach: "use a permanent server-side redirect whenever possible. This is the best way to ensure that Google Search and people are directed to the correct page."

Key principles:

• Use 301 (permanent) redirects for all migration URL changes. Google treats 301 and 308 redirects as permanent signals that link equity should transfer to the new URL.
• Avoid redirect chains: Google can follow up to 10 hops, but each hop introduces latency and risks signal loss. Redirect directly to the final destination URL.
• Keep redirects live for at least 180 days: Google's Change of Address documentation recommends maintaining redirects for 180 days minimum, and longer if you still see traffic from Google Search hitting old URLs.
• No 302s for permanent moves: Temporary redirects (302, 307) tell Google the move might be reversed. For migrations, always use permanent redirects (301, 308).

2.2 Building the Redirect Map

Your redirect map is a 1:1 mapping of every old URL to its corresponding new URL. This is tedious but non-negotiable.

Mapping rules:

1. Exact match first: Map each old URL to the most relevant new URL. The new page should serve the same topic, intent, and audience as the old page.
2. Category-level fallback: If an old page has no direct equivalent, redirect to the most relevant category or parent page.
3. Homepage as last resort: Only redirect to the homepage when there is genuinely no relevant page on the new site. Google treats mass homepage redirects as soft 404s.
4. Pattern-based redirects: For large sites with predictable URL patterns (e.g., /blog/YYYY/MM/slug to /blog/slug), use regex-based redirect rules. Test these extensively---regex errors cascade across thousands of URLs.
5. Parameter handling: Document how URL parameters (UTM codes, session IDs, filter parameters) should be handled. Most should be stripped during redirect.

2.3 Auditing Redirects Before Launch

Once your redirect map is built, validate it before it goes live. The Screaming Frog redirect audit tutorial provides a detailed methodology:

1. Upload your list of old URLs into Screaming Frog's List Mode.
2. Enable "Always Follow Redirects" in the spider configuration.
3. Run the crawl and let it complete to 100%.
4. Export the "All Redirects" report, which shows the full redirect chain for each URL, number of hops, final destination, and final HTTP status code.

This catches common problems before they affect users:

• Redirect loops: URL A redirects to URL B, which redirects back to URL A.
• Chain redirects: URL A redirects to URL B, which redirects to URL C. Should be A directly to C.
• Wrong targets: Old product page redirects to an unrelated blog post instead of the equivalent product page.
• 404 destinations: Redirect targets that don't exist on the new site.
• Mixed protocol: Old HTTP URLs redirect to HTTP (not HTTPS) versions of new URLs.

Phase 3: Staging Environment Testing (2--3 Weeks Before Launch)

Never launch a migration without testing on a staging environment first. This is where you catch issues that aren't visible in a spreadsheet.

3.1 Staging Environment Setup

Your staging environment should mirror production as closely as possible:

• Block search engines: Use robots.txt with Disallow: / and password protection. Do NOT rely solely on meta noindex tags---if Google crawls the staging site before you remove the block, you risk indexing duplicate content.
• Use real redirects: Don't simulate redirects with JavaScript. Implement the actual server-side redirect rules you'll use in production.
• Load real content: Staging should contain all pages, images, and assets from the new site. Placeholder content hides broken internal links.
• Match server configuration: Same web server (Nginx, Apache, Vercel, Netlify), same SSL certificate configuration, same CDN settings.

3.2 Technical SEO Audit on Staging

Crawl the staging site and verify:

• All pages return 200 status codes (no unexpected 404s, 500s, or redirect loops)
• Canonical tags point to the correct new URLs (not old URLs or staging URLs)
• Meta robots tags are correct (no accidental noindex on pages that should be indexed)
• Structured data validates without errors (use Google's Rich Results Test)
• Internal links point to new URLs (not old URLs that would create unnecessary redirects)
• XML sitemaps are generated correctly with new URLs
• Robots.txt will be correct for production (remember to update it post-launch)
• Hreflang tags reference new URLs across all language versions
• Page speed meets or exceeds current performance (Core Web Vitals)
• Mobile rendering works correctly on all template types
• Open Graph and social meta tags reference new URLs and images

3.3 Content Verification

Systematically check that content transferred correctly:

• Spot-check 50+ pages across different templates (homepage, category pages, blog posts, product pages, landing pages)
• Verify images and media load correctly and aren't referencing old CDN paths
• Check forms and interactive elements function properly
• Validate internal search returns relevant results for common queries
• Test navigation across all breakpoints (desktop, tablet, mobile)

Phase 4: Launch Day Checklist

Migration day is execution day, not planning day. Every action should be pre-planned and sequenced.

Pre-Launch (Morning)

• Take a final backup of the old site (database + files)
• Confirm redirect rules are ready to deploy
• Verify the new site is accessible without staging restrictions
• Notify your team that migration is starting (and set expectations for monitoring duties)
• Prepare Google Search Console for verification on the new domain/URL structure

Go-Live (Deploy Window)

• Deploy redirect rules to the production server
• Update DNS records if changing domains (and account for propagation time)
• Remove staging blocks (password protection, robots.txt Disallow)
• Deploy the new site to production
• Verify SSL certificate is active and all pages load over HTTPS

Immediate Post-Launch (First 2 Hours)

• Test redirects manually: Check 20--30 high-priority redirects by visiting old URLs in an incognito browser window. Verify they land on the correct new pages.
• Run a full crawl: Crawl the new site to catch any 404s, redirect loops, or chain redirects that weren't present on staging.
• Submit new sitemaps: Upload updated XML sitemaps to Google Search Console.
• Use the Change of Address tool: If changing domains, submit a Change of Address request in Google Search Console. This tells Google to prioritize crawling your new site and forwards signals from the old domain.
• Request indexing: Use the URL Inspection tool in Search Console to request indexing for your top 10--20 pages.
• Verify robots.txt: Confirm the production robots.txt allows crawling (remove any staging blocks).
• Check Google Tag Manager / Analytics: Verify tracking fires on the new site. Migration is useless if you can't measure recovery.
• Monitor server logs: Watch for 5xx errors, unusual crawl patterns, or server resource issues from increased Googlebot activity.

End-of-Day Checks

• Spot-check 10 high-traffic pages in Google Search results. Are the new URLs appearing, or are old URLs still showing?
• Check Search Console for any new crawl errors
• Verify Core Web Vitals haven't degraded
• Confirm all redirect rules are stable (no changes needed based on testing)

Phase 5: Post-Migration Monitoring (90 Days)

Migration doesn't end on launch day. The real work is monitoring recovery and addressing issues as they surface.

Week 1: Critical Monitoring

The first week is when most problems surface. Monitor daily:

• Crawl errors in Search Console: New 404s indicate redirect gaps or broken internal links. Fix immediately---every day a high-value page returns 404 is a day of lost equity.
• Indexing status: Check the "Pages" report in Search Console. The number of indexed pages should stabilize within the first week. A sharp drop indicates a systemic issue (accidental noindex, robots.txt blocking, redirect misconfiguration).
• Server response times: Increased Googlebot crawling after migration can stress servers. If response times spike above 500ms, investigate and increase capacity.
• Organic traffic: Expect a 10--20% traffic dip in the first week. This is normal. A drop exceeding 30% warrants immediate investigation.

Weeks 2--4: Stabilization

Traffic should begin recovering during weeks 2--4. Focus on:

• Keyword ranking recovery: Compare current rankings against pre-migration benchmarks. Individual keyword fluctuations are normal; wholesale rank drops for entire sections indicate structural issues.
• Backlink recrawling: Monitor whether referring domains are following redirects to your new URLs. If major backlink sources aren't updating, the redirect may be misconfigured for those specific URLs.
• User behavior metrics: Check bounce rates, time on page, and conversion rates on migrated pages. Significant behavior changes can indicate content differences between old and new pages.
• Google discovering new URL patterns: Check "Discovered---currently not indexed" in Search Console. If Google is discovering new URLs but not indexing them, investigate crawl budget allocation.

Weeks 5--12: Full Recovery Assessment

According to Google's documentation on site moves with URL changes, medium-sized websites can take several weeks for most pages to move. Set realistic expectations:

• Compare against pre-migration benchmarks: Overlay 12-week post-migration traffic against the equivalent pre-migration period. Account for seasonality.
• Identify pages that haven't recovered: Some pages will recover faster than others. Pages that still underperform after 8 weeks may need content improvements, additional internal linking, or backlink outreach.
• Audit redirect performance: Run a final redirect audit at the 90-day mark. Identify any remaining chain redirects, loops, or 404s that slipped through initial monitoring.
• Update backlinks where possible: For your highest-value backlinks (top referring domains), reach out to webmasters and request they update their links to your new URLs. While 301 redirects pass equity, direct links are always preferable.

Common Migration Mistakes (and How to Avoid Them)

Even with a thorough checklist, these mistakes catch teams off guard:

Mistake 1: Mass Redirecting to the Homepage

When old pages don't have a 1:1 equivalent on the new site, teams often redirect everything to the homepage. Google treats these as soft 404s---they won't pass meaningful link equity, and the pages effectively disappear from search results.

Fix: Redirect to the most topically relevant page on the new site. If no relevant page exists, consider whether the content should be recreated or whether a 410 (Gone) response is more appropriate than a misleading redirect.

Mistake 2: Forgetting About Images and Assets

URL changes don't just affect HTML pages. Images, PDFs, and other assets have their own URLs---and they may have backlinks or appear in Google Image Search results.

Fix: Include images and assets in your redirect map, especially if your asset URL structure is changing (e.g., moving from /wp-content/uploads/ to /assets/images/).

Mistake 3: Launching on a Friday

Friday launches give you the weekend for problems to compound before your team is back at full capacity on Monday.

Fix: Launch Tuesday through Thursday. This gives you weekdays on both sides of the migration for monitoring and rapid fixes.

Mistake 4: Removing Redirects Too Early

Some teams remove 301 redirects after a few weeks to "clean up" their server configuration.

Fix: Maintain redirects for at least one year. Google's Change of Address documentation recommends 180 days minimum, but external links pointing to old URLs may take much longer to update. The cost of maintaining redirects is trivially low compared to the cost of losing link equity.

Mistake 5: Not Accounting for Cached Results

After migration, Google's cache may still show old versions of pages for days or weeks. Users clicking cached results may see stale content or broken pages.

Fix: This resolves naturally as Google recrawls. Requesting indexing for high-priority pages through Search Console accelerates the process.

Mistake 6: Changing Content During Migration

Migration introduces one variable: URL changes. Simultaneously changing page content, title tags, and meta descriptions introduces multiple variables, making it impossible to diagnose ranking changes.

Fix: Migrate first, then optimize. Wait until traffic has stabilized (typically 4--8 weeks) before making content changes to migrated pages.

Migration Type-Specific Considerations

HTTP to HTTPS Migration

The simplest migration type, but still requires attention:

• Redirect every HTTP URL to its HTTPS equivalent with a 301.
• Update all internal links to HTTPS.
• Ensure mixed content warnings don't appear (HTTP assets loaded on HTTPS pages).
• Submit both HTTP and HTTPS properties in Google Search Console.
• Update your XML sitemaps with HTTPS URLs.

Domain Change (Rebrand)

The highest-risk migration type:

• Use Google's Change of Address tool in Search Console (only available for domain-level properties).
• Maintain the old domain and redirects for at least one year.
• Update all business listings, social profiles, and directory entries with the new domain.
• Consider running both domains temporarily if traffic justifies the cost.

CMS Migration (e.g., WordPress to Next.js)

CMS migrations often change URL patterns, page templates, and rendering methods simultaneously:

• Audit how the new CMS generates URLs. If default patterns differ, configure the new CMS to match old URL patterns where possible.
• Verify server-side rendering. If moving from server-rendered pages (WordPress) to client-side rendered pages (React SPA), ensure Google can still crawl and index content effectively.
• Check that the new CMS generates proper canonical tags, meta tags, and structured data.
• Test pagination, category pages, and archive pages---these are often handled differently across CMS platforms.

Subdomain to Subfolder

Moving blog.example.com to example.com/blog consolidates domain authority:

• Redirect every blog.example.com/slug to example.com/blog/slug.
• Update internal links across the main site.
• Consolidate Google Search Console properties.
• Expect positive ranking effects as link equity consolidates, but this may take 4--8 weeks to materialize.

The Migration Timeline at a Glance

Frequently Asked Questions

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

According to Google's site move documentation, a medium-sized website can take "a few weeks for most pages to move." In practice, most well-executed migrations see 80--90% traffic recovery within 4--6 weeks and full recovery within 8--12 weeks. Poor migrations (broken redirects, missing pages, content changes) can take 6--12 months to recover---or may never fully recover.

Do 301 redirects pass full link equity?

Google's redirect documentation confirms that "301, 302, and other server-side redirects don't cause a loss in PageRank." While the SEO community historically debated whether 301s pass 100% of link equity, Google has clarified that permanent redirects are treated as strong canonical signals and link equity transfers fully.

Should I redirect pages with no traffic?

Yes, if they have backlinks. A page with zero organic traffic but 15 referring domains is still passing link equity to your site's overall authority. Redirect it to the most relevant page on the new site. Pages with zero traffic AND zero backlinks can safely be left to return 404 or 410 responses.

How do I handle URL parameter changes during migration?

Strip unnecessary parameters (session IDs, tracking parameters, filter states) and redirect the clean old URL to the clean new URL. For parameters that change your page content (e.g., ?category=shoes), ensure the parameter-based URLs redirect to the correct equivalent on the new site. Document your parameter handling rules in the redirect map.

When should I hire professional SEO migration services?

Consider professional website migration services when your site has more than 500 indexed pages, when organic search drives more than 30% of your revenue, when the migration involves a domain change, or when you're changing CMS platforms with significant URL structure differences. The cost of professional migration support is typically a fraction of the revenue at risk from a botched migration.

Next Steps

Migration is one of those projects where preparation directly determines outcomes. The teams that spend 80% of their time planning and 20% executing consistently outperform teams that rush to launch.

At Sunrise Digital Labs, our migration services cover every phase outlined in this checklist---from pre-migration audit through 90-day post-launch monitoring. We also provide ongoing SEO services that ensure your organic performance doesn't just recover after migration but continues to grow. If your migration involves connecting disparate systems or platforms, our systems integration expertise ensures the technical infrastructure supports your SEO goals.

Sources

• Google Search Central: Site Moves and Migrations
• Google Search Central: Redirects and Google Search
• Google Search Console: Change of Address Tool
• Screaming Frog: How to Audit Redirects in a Site Migration
• Lumar: Website Migration Checklist for SEO
• Ahrefs: A Website Migration Takes More Than a Checklist
• Screaming Frog: Redirect Checker Tutorial