Website Migration SEO Checklist: 47 Things to Do Before You Launch

Website migrations are where SEO goes to die. Platform changes, redesigns, domain moves — each one is an opportunity to lose months or years of ranking progress in a single deployment.

The difference between a migration that gains traffic and one that craters is almost always preparation. Here’s the checklist we use internally. It’s not theoretical — it’s battle-tested across dozens of migrations.

Pre-Migration: Before Development Starts

These steps happen before anyone writes a line of code for the new site. Skip them and you’re building on quicksand.

1. Crawl the Existing Site Completely

Use Screaming Frog, Sitebulb, or Ahrefs Site Audit to get a complete inventory of every URL on your current site. Not just the pages in your CMS — every URL that returns a 200 status code.

Export:

All live URLs (200 status)
All existing redirects (301/302)
All 404 pages
All pages with canonical tags
All pages in XML sitemaps

This is your baseline. Everything maps from here.

2. Identify High-Value Pages

Not all pages matter equally. Pull data from Google Analytics and Search Console to identify:

Top traffic pages — pages receiving the most organic visits
Top revenue pages — pages in conversion paths
Top ranking pages — pages holding position 1-10 for valuable keywords
Top linked pages — pages with the most external backlinks (check Ahrefs or Moz)

These pages get priority protection. If you have to choose between getting a redirect right on a page with 5,000 monthly visits versus one with 5, the choice is obvious.

3. Export All Keyword Rankings

Take a snapshot of every keyword you currently rank for. Use Ahrefs, SEMrush, or your preferred rank tracker. You need this to measure post-migration impact.

Export: keyword, current position, URL ranking, monthly volume, traffic estimate.

4. Export All Backlinks

Your backlink profile is one of your most valuable SEO assets. Map which pages receive external links:

Export all referring domains and the specific URLs they link to
Identify pages with the most link equity (high DR/DA linking domains)
Note any links pointing to already-redirected URLs (these need chain cleanup)

If a page receiving links from 50 high-authority sites gets migrated to the wrong URL — or worse, returns a 404 — you lose that authority permanently.

5. Document Current Technical SEO State

Before migration, know your baseline:

Core Web Vitals scores (LCP, FID/INP, CLS)
Index coverage in Search Console (indexed, excluded, errors)
Crawl stats (pages crawled per day, average response time)
Current robots.txt rules
Current XML sitemap(s) structure
Schema markup in use
Hreflang tags (if multi-language)

6. Design the New URL Structure

This is a strategic decision, not a development afterthought.

Map out the new URL structure considering:

Will URLs change? If not, you’re in a much better position.
If they do change, is the new structure flatter or deeper?
Are you changing slugs, categories, or both?
What about parameter URLs from faceted navigation?

Rule of thumb: keep URLs the same wherever possible. Every changed URL is a redirect that needs mapping. The fewer redirects, the less risk.

7. Build the Redirect Map

This is the most critical document in any migration. It maps every old URL to its new destination.

For each old URL, determine:

Same content, new URL → 301 redirect to new URL
Content merged into another page → 301 to the merged page
Content removed, no equivalent → 301 to the most relevant parent category
Never had traffic or links → Consider letting it 404 (don’t redirect everything to the homepage)

The redirect map should be a spreadsheet: old_url | new_url | status_code | priority | notes.

8. Handle Redirect Chains

If your current site already has redirects (A → B), and the migration changes B to C, you need A → C directly. Not A → B → C. Redirect chains dilute PageRank and slow crawling.

Audit all existing redirects and flatten chains before migration.

9. Plan Content Parity

For every page that ranks, the new version needs to maintain or improve the signals that earned those rankings:

Same or better heading structure (H1, H2s)
Same or more comprehensive content
Same target keywords in title tags and body content
Updated meta descriptions
Preserved or improved internal linking

Redesigns often strip content for “clean” layouts. Make sure the SEO team reviews content changes before they’re finalised.

10. Prepare Updated Sitemaps

Have your new XML sitemaps ready to submit immediately on launch day. They should include only canonical, indexable URLs on the new site.

During Development: QA Before Launch

11. Test Redirects on Staging

Implement all redirects on the staging environment and test them. Every. Single. One.

Automated tools can verify redirect maps at scale. Don’t rely on spot-checking 10 URLs out of 500.

12. Check Robots.txt on Staging

A common disaster: staging sites use Disallow: / in robots.txt (correct for staging) and this accidentally gets deployed to production. Verify your production robots.txt is ready and doesn’t block critical paths.

13. Verify Canonical Tags

Every page on the new site should have a self-referencing canonical tag pointing to the correct new URL (not the old one, not the staging URL).

14. Verify Schema Markup

All structured data from the old site should be present on the new site. Check with Google’s Rich Results Test.

15. Verify Meta Tags

Title tags, meta descriptions, and OG tags should all be populated on the new site. Bonus: if the old site had weak meta tags, improve them during migration.

16. Test Internal Links

Crawl the staging site and check for broken internal links. Links should point to new URLs, not old ones that rely on redirects to work.

17. Check Core Web Vitals

Run Lighthouse and PageSpeed Insights on key pages. The new site should meet or beat the old site’s performance. Pay particular attention to LCP — new designs with larger images often regress here.

18. Verify Mobile Experience

Test the complete site on multiple mobile devices. Google uses mobile-first indexing, so the mobile version is what matters for rankings.

19. Check Hreflang (If Applicable)

Multi-language sites need correct hreflang annotations on every page. Errors here can cause the wrong language version to rank in the wrong market.

20. Test Analytics and Tracking

Verify Google Analytics (GA4), Search Console verification, and any conversion tracking are properly configured on the new site. Losing tracking data during migration is a separate disaster.

Launch Day

21. Choose the Right Day

Launch Tuesday through Thursday, morning. Never Friday (nobody wants to debug redirect issues over the weekend). Never before holidays. Never during a major Google core update rollout.

22. Deploy Redirects First

If possible, deploy redirects before or simultaneously with the new site. There should never be a window where old URLs return 404s.

23. Verify Redirects Are Live

Run your redirect map through a bulk checker immediately after deployment. Flag any that aren’t firing correctly.

24. Submit New Sitemaps to Search Console

Upload the new XML sitemaps immediately. Remove the old sitemaps if URLs have changed.

25. Request Indexing of High-Priority Pages

Use Search Console’s URL Inspection tool to request indexing of your most important pages. This doesn’t guarantee faster crawling, but it signals priority.

26. Check Robots.txt Is Correct

Verify the production robots.txt allows crawling of all important paths. Double-check that no staging-environment block rules leaked through.

27. Monitor Server Logs

Watch for 404 spikes in real-time. If Googlebot is hitting old URLs that aren’t redirecting, fix them immediately.

28. Monitor Search Console

Check the Coverage and Core Web Vitals reports within hours of launch. New errors will appear here first.

29. Verify HTTPS

If the migration involves any protocol change, verify all pages serve over HTTPS and there are no mixed content warnings.

30. Test Conversion Flows

Run through your booking, contact, or purchase flows end-to-end. A migration that preserves SEO but breaks checkout is still a disaster.

Post-Migration: 90-Day Monitoring

31-35. Week 1 Checks (Daily)

Monitor crawl errors in Search Console daily
Track keyword positions for top 50 priority terms
Compare organic traffic day-over-day vs. pre-migration baseline
Check server logs for persistent 404 patterns
Verify new pages are being indexed (use site: operator and Coverage report)

36-40. Week 2-4 Checks (Every Few Days)

Review full index coverage report — are pages being dropped?
Compare backlink status — are referring domains still resolving to live pages?
Check for crawl budget issues (Crawl Stats in Search Console)
Monitor Core Web Vitals for regressions
Fix any redirect issues discovered by users or crawlers

41-45. Month 2-3 Checks (Weekly)

Full keyword ranking comparison vs. pre-migration snapshot
Organic traffic trend analysis by landing page
Page-level comparison for high-priority pages
Identify any pages that lost rankings and diagnose cause
Continue fixing edge cases (old URLs found in external links, etc.)

46. Update External Links Where Possible

If you have profiles on directories, social media, partner sites, etc. that link to old URLs, update them to point directly to the new URLs. This reduces redirect dependency.

47. Final Migration Report

At 90 days, compile a full comparison:

Traffic: pre vs post
Rankings: position changes for priority keywords
Index coverage: pages indexed pre vs post
Technical health: Core Web Vitals, crawl errors
Revenue impact: conversion rate and revenue from organic

This closes the migration project and establishes the new baseline.

The One Thing That Saves Every Migration

If you take nothing else from this checklist: build the redirect map early, test it thoroughly, and deploy it correctly. Redirects are the bridge between your old site and your new one. If the bridge has holes, traffic falls through.

Need help planning or executing a migration? See how we handle SEO migrations — we’ve done this enough times to know where the landmines are buried.