Site Migration SEO Checklist: Moving Without Losing Your Rankings

Every year, agencies and in-house teams execute site migrations that destroy years of organic search value in a single weekend. A platform change here, a URL restructure there, a developer who “didn’t realize redirects mattered” — and suddenly traffic that took 3 years to build drops 60% in a week. I’ve seen it happen to Fortune 500 companies. I’ve seen it happen to local businesses. And almost every single time, it was preventable with proper preparation.

Site migration is one of the highest-risk technical SEO activities. Done correctly, you can change platforms, restructure your entire site, and improve performance while maintaining — even growing — your organic visibility. Done wrong, you erase ranking equity that took years to build. This checklist is the exact process we use for every migration we manage. Follow it precisely.

Phase 1: Pre-Migration Audit and Preparation (6-8 Weeks Before)

This phase is the most important — and the most commonly skipped. Teams rush to the migration itself and skip the preparation, which is exactly backward. The audit and mapping work you do before migration determines whether you keep your rankings.

Document Your Current State

Before you change anything, record exactly what you have. Export your complete Google Search Console data for the past 12 months: impressions, clicks, average position, and landing page performance. This is your benchmark — you need it to measure any impact. Export your full sitemap and your top 500 pages by organic traffic. Run a crawl with Screaming Frog (or equivalent) and save the complete export: URLs, page titles, meta descriptions, H1s, canonical tags, and status codes.

Record your top 50 ranking keywords and their current positions. Note which pages rank for which keywords. This matters because after migration, you’ll be checking whether those keyword rankings are maintained — not just whether the same pages rank, but whether the visibility for each keyword cluster is preserved.

Backlink Audit and Outreach

Your backlink profile is years of earned authority. A migration that breaks backlinks can devastate your domain authority overnight. Export your complete backlink profile from Ahrefs, Semrush, or Moz. Identify your top 50 backlinks by domain authority — these are the links most likely to drive traffic and ranking value.

For each high-value backlink, attempt to update the link to point to the new URL. This is a manual process, but it’s worth it. We’ve seen campaigns where proactive backlink outreach recovered 15-20% more link equity than passive redirect mapping alone. Reach out to webmasters with old links, offer the new URL, and track your outreach results. Document everything — you’ll want this record if rankings drop later and you need to diagnose why.

URL Mapping: The Most Critical Step

URL mapping is the process of matching every old URL to its new equivalent. This is where most migrations fail. The mapping must be complete, accurate, and tested before you go live.

For each old URL, determine: what is the new URL that should receive its traffic? Options include: direct redirect to new equivalent (preferred), redirect to relevant parent category (if the specific page doesn’t exist), or 410 status code (page intentionally removed — only if content is truly gone). Never redirect old URLs to the homepage unless there’s no better option — that destroys link equity and confuses both users and search engines.

Use a spreadsheet to document the complete mapping. Columns: Old URL, New URL, Redirect Type (301 or 302), Reason for mapping decision, Status (pending, implemented, verified). This spreadsheet is your migration roadmap and your post-migration troubleshooting guide.

Phase 2: Technical Setup and Redirect Implementation (2-4 Weeks Before)

Configure Redirect Rules in Your New Platform

Implement your URL mapping as redirect rules in your new platform. The implementation method depends on your platform: Apache (.htaccess), Nginx (nginx.conf), CDN-level redirects, or platform-specific redirect manager. Each has different syntax and capability limits. Test your redirect rules against a copy of your URL mapping spreadsheet — every old URL should redirect to exactly one new URL.

Critical redirect rules to implement: catch-all redirects for URL parameter changes, case-insensitive matching (if your old site treated /Page and /page the same), trailing slash standardization (decide whether your new site uses trailing slashes and redirect accordingly), and HTTPS enforcement (if migrating to HTTPS).

DNS and Infrastructure Preparation

If your migration involves DNS changes, plan the propagation carefully. Set TTL values to 300 seconds (5 minutes) at least 48 hours before migration. This allows you to make DNS changes quickly and roll back if needed. Never change DNS and change platform simultaneously — sequence them so you can isolate any issues.

For CDN-level changes: configure your CDN to handle redirects before switching origin servers. This prevents downtime and ensures redirects work throughout the transition. Verify CDN caching rules don’t conflict with your redirect implementation.

Canonical Tag and Meta Robot Configuration

On your new site, implement canonical tags on every page — pointing to the canonical URL you want indexed. This prevents duplicate content issues that commonly arise during migration. Also verify that your new site doesn’t have rogue meta robots tags blocking pages that should be indexed. Run a crawl of your staging/preview environment to catch any noindex or nofollow issues before they affect your live site.

Phase 3: Migration Execution (The Migration Weekend)

Pre-Launch Checklist

Before you switch traffic: verify all redirects are live and pointing correctly (test each high-traffic URL manually). Verify Google Analytics and tracking codes are firing on new URLs. Confirm XML sitemap is generated and includes all canonical URLs. Verify robots.txt allows search engine access (and that it doesn’t block critical resources). Check that hreflang tags are implemented if you have international sites. Set up Search Console property for the new domain if domain is changing.

One more thing: make sure your dev team is available for the entire migration window. Issues almost always surface during cutover — you need people who can fix them immediately, not wait until Monday morning.

Staged Rollout (Recommended for Large Sites)

For sites with over 10,000 pages, we recommend a staged rollout rather than a full cutover. First, migrate a subset of high-traffic pages and verify everything works. Then migrate the full site in phases. This approach catches issues before they affect your entire portfolio. Use traffic throttling in your load balancer or DNS to gradually shift visitors to the new site over 24-48 hours.

Post-Launch Immediate Actions (First 24 Hours)

Within 24 hours of going live: verify core pages are returning correct HTTP status codes (200 for live, 301 for redirected). Test your top 50 pages by traffic manually. Submit the new XML sitemap to Google Search Console. Check Search Console for crawl errors — new errors often appear within hours of a migration. Monitor server logs for unexpected 404 errors. Verify analytics is capturing data correctly on new URLs.

Phase 4: Post-Migration Monitoring (8-12 Weeks After)

Daily Monitoring (First 2 Weeks)

Every day for the first two weeks, check: Search Console crawl report for errors, Search Console index coverage status, ranking positions for your top 50 keywords, organic traffic in Google Analytics, server error logs for unexpected 404s and 500s, and redirect chain integrity (no redirect loops or chains).

Create a daily log. If rankings dip, you need to be able to correlate the timing of any drop with specific changes made. Without this log, diagnosing issues becomes guesswork.

Common Post-Migration Issues and Fixes

Soft 404s — Pages returning 200 but no content, or thin content. Check your new platform’s error page handling. Fix by restoring content or implementing proper 404s.

Redirect loops — A→B→A→B infinitely. Usually caused by conflicting redirect rules. Use a redirect checker tool to identify the loop and fix the rules.

Indexation issues — New pages not indexed. Verify robots.txt doesn’t block them. Check canonical tags are self-referencing. Submit the specific URLs to Google for indexing.

Missing meta descriptions — Sometimes migration platforms strip meta data during import. Run a crawl and compare meta description coverage against your pre-migration data.

Link Equity Recovery Verification

4-6 weeks after migration, compare your backlink profile to your pre-migration baseline. Check: total referring domains (should be roughly maintained), domain authority / DR score (should not have dropped), and link equity distribution across pages (top pages should still have most backlinks). If you’re seeing significant drops, revisit your redirect mapping — broken backlinks from external sites often don’t redirect correctly because you don’t control them.

The Migration Scenarios That Require Extra Care

Platform-to-Platform Migration

Moving from WordPress to a headless CMS, from a custom platform to Shopify, or from one CMS to another creates the most complexity because URL structures almost always change. The URL mapping becomes critical. Additionally, platform-specific SEO elements — category pages, product pages, blog structures — often behave differently and need individual testing.

Domain Change Migration

Changing domain names is the most dangerous migration type because you’re starting fresh from a crawl and indexation perspective. The 301 redirects pass most link equity, but it takes time — often 3-6 months for full equity transfer. During this window, you’re vulnerable. Consider whether a domain change is truly necessary before proceeding.

HTTPS Migration

Migrating from HTTP to HTTPS should be done carefully. Install the SSL certificate correctly, implement 301 redirects from every HTTP URL to its HTTPS equivalent, update internal links to use HTTPS, and update all canonical tags and hreflang tags. Google treats this as a domain change — your new HTTPS site starts fresh until the signals propagate.

Frequently Asked Questions

What are the most common causes of ranking loss during site migration?

The top causes are broken redirects (missing or incorrect 301/302 redirects), URL structure changes without redirect mapping, loss of crawl access during migration, duplicate content issues from HTTPS/HTTP coexistence, and failure to transfer or update internal links. Each of these is preventable with proper planning — which is why we stress pre-migration preparation over rushing to the migration itself.

How long before a migration should I start preparing SEO?

Begin SEO preparation 6-8 weeks before migration. This includes a complete technical audit, URL mapping, backlink outreach, and Google Search Console setup. The actual migration execution should be carefully controlled, and post-migration monitoring should continue for 8-12 weeks minimum. Most sites that suffer migration damage didn’t prepare long enough.

Do 301 redirects still pass full SEO value in 2026?

Yes. Google’s official position is that 301 redirects pass approximately the same ranking value as direct links to the redirected URL. However, temporary 302 redirects do not pass full link equity — use them only for genuinely temporary redirects. Always use 301 redirects for permanent URL changes. Also avoid redirect chains (A→B→C) which can degrade equity transfer.

Should I migrate to HTTPS before or after other changes?

HTTPS migration should ideally be done as its own project if possible, not combined with other major changes. Adding HTTPS complexity to an already complex migration (platform change, URL restructure) increases the risk of ranking issues significantly and makes debugging exponentially harder. Isolate each major change and verify stability before proceeding.

How do I track ranking changes after migration?

Set up rank tracking before migration with your target keyword set. After migration, monitor daily for the first 2 weeks, then weekly for 2 months. Compare against your pre-migration baseline. Also monitor Google Search Console for crawl errors, indexation status, and search impression changes. Create a daily log of observations — correlation between changes and impacts is essential for diagnosing issues.

What should I do if rankings drop after migration?

First, verify your redirects are working correctly using a redirect checker tool. Then check Google Search Console for crawl errors and indexation issues. Common fixes: resubmit your sitemap, check for noindex tags that shouldn’t be there, verify canonical tags point to the right URLs, ensure old URLs redirect to correct new equivalents, and audit for redirect loops or chains. Most ranking drops post-migration are fixable if caught within the first 2 weeks.