Website Migration SEO Checklist (2026)

Website migrations are the highest-risk SEO events most sites will ever face. A domain change, CMS switch, major redesign, or even an HTTPS upgrade can destroy years of organic traffic if handled incorrectly. The difference between a successful migration and a disaster comes down to preparation, redirect accuracy, and post-migration monitoring.

Key takeaway: Map every URL before you migrate, implement 301 redirects for every changed URL, and monitor intensively for 90 days after launch. There are no shortcuts. Every skipped step is a potential traffic leak.

What Are the Different Types of Website Migrations?

Not all migrations carry the same risk level. Understanding your migration type helps you allocate the right resources and set appropriate expectations. (We explore this further in On-Page SEO Checklist 2026: 25 Essential Optimizations.)

The rule of thumb: the more things you change simultaneously, the higher the risk. If you’re changing CMS and domain and URL structure and design at the same time, the compounding risk is enormous. Where possible, phase changes so you can isolate issues.

The golden rule: If you can keep the same URLs, do it. URL changes are the primary source of migration traffic loss. A CMS migration that preserves URL structure is dramatically safer than one that introduces new URLs.

What Should You Do Before the Migration Begins?

Pre-migration preparation is where successful migrations are won or lost. This phase takes longer than the migration itself — and that’s exactly right.

Step 1: Comprehensive URL inventory.

Crawl your current site completely using Screaming Frog, Sitebulb, or a similar tool. Export every URL that returns a 200 status. This is your master list.

Supplement with:

• All URLs indexed in Google (Search Console → Pages → Indexed)
• All URLs with backlinks (Ahrefs/SEMrush backlink data)
• All URLs in your sitemap
• All URLs with organic traffic in the past 12 months (Google Analytics)

Merge and deduplicate. This final list is every URL that matters — either because it has ranking equity, backlinks, traffic, or all three.

Step 2: URL mapping.

For every URL that will change, create a 1:1 mapping from old URL to new URL. This is tedious but non-negotiable.

Old URL → New URL
/blog/2024/03/seo-tips → /blog/seo-tips
/products/cat1/widget-blue → /shop/widgets/blue-widget
/about-us.html → /about

Rules for mapping:

• Map to the most relevant equivalent page. Don’t redirect everything to the homepage.
• If a page is being removed, redirect to the closest relevant page.
• If an entire section is being restructured, map each individual URL — don’t redirect a whole directory to a single page.
• Document the mapping in a spreadsheet for reference during QA.

Step 3: Benchmark current performance.

Record these metrics before migration so you can measure impact afterward: This relates closely to what we cover in Why JavaScript Kills Your AI Visibility.

• Organic traffic by page (top 100 pages minimum)
• Keyword rankings for target keywords (top 200-500)
• Core Web Vitals scores
• Crawl stats from Search Console
• Indexed page count
• Backlink profile (total referring domains, top linked pages)

Export and save this data. You’ll need it during the post-migration monitoring phase.

Step 4: Backup everything.

Full database backup, file backup, server configuration backup. If the migration goes catastrophically wrong, you need the ability to revert completely within hours.

How Do You Handle Redirects During a Migration?

Redirects are the backbone of any migration. Every old URL that changes must 301 redirect to its new equivalent. No exceptions.

301 redirect implementation:

For Apache servers (.htaccess):

Redirect 301 /old-page /new-page
RedirectMatch 301 ^/blog/2024/(.*)$ /blog/$1

For Nginx:

location = /old-page {
    return 301 /new-page;
}
location ~ ^/blog/2024/(.*)$ {
    return 301 /blog/$1;
}

For Vercel/Next.js (vercel.json or next.config.js):

{
  "redirects": [
    { "source": "/old-page", "destination": "/new-page", "permanent": true }
  ]
}

Redirect rules to follow:

1. Use 301 (permanent) redirects for all migration redirects. Google treats 301s and 302s the same for PageRank passing, but 301s signal permanence to other systems.
2. No redirect chains. If A already redirects to B, and B is moving to C, update A to redirect directly to C.
3. Include all URL variations — with/without trailing slash, www/non-www, HTTP/HTTPS.
4. Redirect at the page level first, then patterns. Individual page redirects are more accurate than regex patterns. Use patterns only for predictable bulk changes.
5. Test every redirect before launch. Use a tool like Screaming Frog in “List Mode” — feed it all your old URLs and verify each one 301s to the correct new URL.

Common redirect mistakes:

• Redirecting everything to the homepage — This is a soft 404 in Google’s eyes. It provides no value and wastes the equity of the redirected pages.
• Missing trailing slash variants — /blog/post and /blog/post/ may be treated as different URLs. Redirect both.
• Not handling query parameters — /search?q=test should redirect appropriately, not 404.
• Removing redirects too early — Keep redirects in place for at least 12 months. Ideally, keep them permanently. The performance cost is negligible.

What Changes Need to Happen on Launch Day?

Migration launch should be a coordinated event with a clear checklist.

Pre-launch verification (staging):

Before pushing to production, verify on staging:

• All redirect rules are in place and tested
• Robots.txt allows crawling (no leftover Disallow: / from staging)
• XML sitemap contains only new URLs, all returning 200
• Canonical tags point to new URLs
• Internal links updated to new URLs (not relying on redirects)
• Structured data updated with new URLs
• hreflang tags updated (if applicable)
• Analytics tracking code installed and firing
• Search Console verified for new domain (if domain change)

Launch day actions:

1. Deploy the new site
2. Verify redirects are working in production (test 50 random URLs)
3. Submit new sitemap to Google Search Console
4. If domain change: use Search Console’s Change of Address tool
5. Request indexing for your top 20 pages via URL Inspection
6. Verify robots.txt is correct in production
7. Check that no staging noindex tags leaked to production
8. Monitor server logs for 5xx errors and redirect loops
9. Test site on mobile devices
10. Verify Core Web Vitals on key pages using PageSpeed Insights

The first 24 hours:

Watch your server logs and analytics closely. Common launch-day issues:

• Redirect loops (URL A → B → A) causing 5xx errors
• Missing redirects causing spikes in 404 errors
• Server overload from redirect processing on large sites
• CDN caching old versions of pages
• Mixed content warnings on HTTPS migrations

How Do You Monitor SEO Performance After Migration?

Post-migration monitoring is a 90-day process. The first week is critical, but issues can surface weeks later.

Week 1 monitoring (daily):

If you see a sudden spike in 404 errors, check your redirect mapping immediately. Missing redirects are the most common post-migration issue. For more on this, see our guide to AI Citation Benchmarks by Industry (2026).

Week 2-4 monitoring (every 2-3 days):

• Track keyword ranking changes for your top 100 target keywords
• Monitor organic traffic trends — compare to pre-migration baseline
• Check Search Console for any manual actions or security issues
• Verify that Google is indexing new URLs (not still showing old ones)
• Monitor Core Web Vitals for any degradation

Month 2-3 monitoring (weekly):

• Compare organic traffic month-over-month
• Check backlink profile — are links pointing to new URLs?
• Verify redirect chains haven’t accumulated
• Monitor for crawl budget issues on large sites
• Review AI crawler activity in server logs

Recovery timeline expectations:

Healthy migration recovery follows a pattern:

• Days 1-7: Traffic drops 10-30% as Google reprocesses URLs
• Days 7-14: Traffic begins stabilizing, some keywords recover
• Days 14-30: Most keywords return to pre-migration positions
• Days 30-60: Traffic should reach or exceed pre-migration levels
• Days 60-90: Full stabilization, any remaining issues are likely unrelated to migration

If you’re still seeing significant traffic loss after 90 days, investigate:

• Missing redirects (check for 404 spikes)
• Content differences between old and new pages
• Technical issues on the new site (slow loading, rendering problems)
• Lost structured data or schema markup
• Canonical tag errors

How Do Migrations Affect AI Search Visibility?

AI search engines have their own crawl schedules and caching behavior, which means migrations affect AI visibility differently than traditional search.

AI citation lag:

When AI systems like Perplexity, ChatGPT, or Google AI Overviews cite your content, they reference specific URLs. After a migration, these cached references point to your old URLs. The lag time for AI systems to update their references varies:

• Google AI Overviews: 2-4 weeks (tied to Google’s crawl cycle)
• Perplexity: 1-4 weeks (active web crawling)
• ChatGPT: Variable (depends on retrieval system and training data updates)

During this lag period, your 301 redirects serve as a bridge. AI-referred visitors clicking on old URLs will be redirected to your new pages. This is why keeping redirects permanent is even more important in the AI search era.

Structured data continuity:

AI engines heavily rely on structured data for content understanding. During migration, ensure all schema markup is updated to reference new URLs, especially:

• @id and url properties in JSON-LD
• SameAs references
• Breadcrumb URLs
• Article canonical URLs

Content parity for AI:

AI systems may compare your old content with your new content. If significant content was removed or substantially changed during migration, AI systems may stop citing those specific points. Maintain content parity — if a page was being cited for a specific fact or methodology, keep that content on the new version.

Proactive steps for AI search:

1. After migration, check if AI engines are still citing your content using tools like Ahrefs Content Explorer or manual AI search queries
2. Update any external references to your content (guest posts, directories, social profiles) with new URLs
3. Submit your new sitemap to search engines promptly — AI crawlers often use sitemap data for discovery
4. Ensure new pages load fast and render server-side so AI crawlers can access content immediately

What Are the Biggest Migration Mistakes That Destroy Rankings?

Mistake 1: No redirect mapping.

The single most destructive migration mistake. Without 1:1 redirect mapping, hundreds or thousands of URLs return 404. All accumulated link equity, rankings, and AI citations for those pages are lost instantly. Our GEO for Local Businesses: Getting AI to Recommend You guide covers this in detail.

Every migration needs a complete URL mapping. No exceptions. If the task seems too large, it means you need to start planning earlier — not skip the mapping.

Mistake 2: Launching on Friday.

Migration issues surface within hours. If you launch on Friday afternoon, your team isn’t available to fix critical issues over the weekend. Search engines don’t take weekends off — Googlebot may crawl your broken redirects on Saturday and devalue your pages before Monday.

Always launch early in the week (Monday or Tuesday) when your full team is available.

Mistake 3: Changing content and URLs simultaneously.

If you change your URLs and rewrite your content at the same time, you can’t tell whether ranking changes are from the migration or the content changes. Google may treat dramatically different content at a new URL as a completely new page rather than a moved page — losing all historical equity. As we discuss in AI Citations Have Almost No Correlation with Web Traffic, this is a critical factor.

Migrate first (same content, new URLs). Wait for recovery. Then update content.

Mistake 4: Not updating internal links.

After redirects are in place, many teams call it done. But internal links still pointing to old URLs create unnecessary redirect hops. Every internal link should point directly to the new URL — not rely on the redirect. This improves crawl efficiency and user experience.

Run a full crawl post-migration and fix every internal link that triggers a redirect.

Mistake 5: Removing redirects after a few months.

Some teams remove redirects after 3-6 months, thinking Google has “processed” them. This creates instant 404s for any external links still pointing to old URLs — and there will always be some. Keep redirects permanently. The server resource cost is trivial compared to the link equity cost of removing them.

What’s the Complete Migration Timeline?

8 weeks before launch:

• Define migration scope and type
• Begin comprehensive URL audit
• Start URL mapping
• Set up staging environment

6 weeks before:

• Complete URL mapping
• Begin implementing redirects in staging
• Benchmark current performance
• Set up monitoring dashboards

4 weeks before:

• Test all redirects in staging
• QA new site for technical SEO issues
• Update all structured data and schema
• Prepare updated sitemaps

2 weeks before:

• Final redirect testing
• Pre-launch SEO audit of staging site
• Update Search Console verification (domain changes)
• Brief all stakeholders on timeline and expectations

1 week before:

• Freeze content changes on old site
• Final backup
• Confirm launch team availability
• Prepare rollback plan

Launch day:

• Deploy, verify, monitor (see launch day checklist above)

Post-launch:

• Week 1: Daily monitoring
• Weeks 2-4: Every-other-day monitoring
• Months 2-3: Weekly monitoring
• Ongoing: Monthly spot checks for 12 months

This timeline assumes a medium-complexity migration. Simple HTTPS upgrades can compress to 2-3 weeks. Enterprise domain changes may need 12-16 weeks of preparation.

The investment in planning always pays off. A migration done right is invisible to users and barely noticeable in your analytics. A migration done wrong can set your organic growth back by years.