SEO Migration Checklist: How to Avoid Traffic Loss During Website Redesign

Website migration is one of the most risky SEO activities in your SEO calendar. Done right, it can boost rankings, improve the user experience and earn the site its authority. But done wrong, it can cost you a lot of traffic for six to eighteen months to come.

The harsh reality is that most traffic declines associated with website redesigns are completely avoidable due to forgetting about SEO altogether before the redesign launches.

The following seo migration checklist will help you avoid the most common problems and make the website migration a success.

Why Website Migrations Kill Organic Traffic

Let’s take a quick look at the mechanics behind traffic losses after the migration. The most frequent culprits are:

• Changes in URL structure: When the URL changes (for example, /services/seo becomes /seo-services/), the links leading to it result in 404 error, unless the old URL is redirected. And it takes time for Google to recrawl and re-index the new URL.
• Indexation loss: In most redesigns, some pages get either removed or are accidentally tagged as noindex. Every missing page from Google’s index equals lost ranking opportunities.
• Degraded internal linking structure: Many migrations start from rebuilding navigation from scratch. In case the new structure doesn’t improve the old one, there will be degradation in link equity distribution.
• Regression in page speed: With new design framework, heavier images and unoptimised JavaScript, your Core Web Vitals can become really bad, resulting in ranking penalties.
• Overwriting of metadata: Years of optimized title tags and meta descriptions, carefully built over time, become default or even blank in template-generated content.
• Schema markup loss: The rich data implemented on the old website won’t automatically migrate to the new one unless you explicitly recreate it.

All those problems are completely avoidable with appropriate actions before, during and after migration. Here’s how to do it.

Pre-Migration: The Foundation Phase

Everything you do before going live defines how you handle the migration. It’s the phase where most companies underinvest.

1. Crawl and Audit the Existing Site Completely:

Using Screaming Frog, Sitebulb or Semrush Site Audit tools, crawl your whole website. Export and save the following:

• A full list of all your indexed URLs (compare against Google Search Console Coverage report)
• Current page titles, meta descriptions, H1S
• Internal links on your website (source URL → target URL)
• Structured data markup implemented
• Canonical tags
• HREFLANG tags, if multilingual
• Current Core Web Vitals score on your top 20 pages via Google PageSpeed Insights

This snapshot serves as a baseline for you. You’ll use it as a basis for comparison after your migration.

2. Download Google Search Console and Google Analytics data

Export full-year information on:

• Performance report from Google Search Console, containing all queries, pages, clicks, impressions, CTR, positions
• Coverage report from GSC, containing all indexed URLs, crawl errors, excluded pages
• Organic landing pages report from GA4, showing top organic traffic-generating pages by sessions and goal completions
• Conversion paths from GA4 to identify the pages involved in assisted conversions, not only the last click pages

This data tells you what pages absolutely cannot be broken, redirected incorrectly or deleted during the migration.

3. Identify Your High-Value URL Inventory

Based on the GSC and GA4 data, compile the list of URLs prioritized by:

• Tier 1: Your top organic traffic pages (your top 20% of URLs driving 80% of organic sessions)
• Tier 2: Higher-ranking pages (positions 1–10) regardless of the traffic volume
• Tier 3: Highest-converting pages
• Tier 4: Pages with significant backlink profile (use Ahrefs or Semrush for identification)

Tier 1 and Tier 4 pages are non-negotiable. Any changes in URL for such pages require careful 301 redirect.

4. Build a redirect map for every URL change

Create a complete redirect map in a spreadsheet before changing any URLs during the migartion process:

Your rules for the redirect map are:

• For every old URL you provide a destination; no 404s after URL changes allowed
• Use 301 permanent redirects, not 302 temporary
• Do not use redirect chains (A -> B -> C). One hop redirect is max.
• Check redirect loop existence (A -> B -> A)
• Permanent URL deletions should be 301 redirected to the most relevant live page, not the homepage

5. Document All Existing On-Page SEO Elements

Document for every Tier 1 and Tier 2 page:

• Title tag (full text)
• Meta description (full text)
• H1, H2, H3 structure
• Primary keyword and its placement
• Structured data types implemented

This documentation will be used as the brief for the new site development and allows preserving on-page SEO. Otherwise, the on-page SEO accumulated over the years gets rewritten with CMS defaults.

6. Set up a staging environment

Before going live, make sure that all your migration tasks are tested on staging. The staging site must:

• Be blocked from search engines’ crawlers (robots.txt or password protection)
• Match the production environment as much as possible
• Be accessible to everyone on your QA team

7. Check Your Core Web Vitals

Using Google PageSpeed Insights and CrUX data in Google Search Console, check the scores of your LCP, CLS, INP for your top 20 pages. After the launch, those metrics must remain at least at the same level.
During Development: Build Phase

8. Preserve URL Structure Where Possible

Restrict the changes to Tier 3 and lower if you need to change them for user experience. The best migration doesn’t change URLs at all.

9. Transfer all on-page SEO elements to new pages

Make sure for every page listed in the redirect map and Tier 1, 2 and 3 URL inventory that:

• Optimized title tags have been transferred to the new pages, not auto-generated by CMS
• Meta descriptions have been transferred
• H1 tags are present, unique and match the keywords
• Body content is fully transferred
• Image alt tags are preserved and transferred
• Internal links are preserved

Create the QA checklist for every page and assign an owner to sign it before going live.

10. Re-Implement All Structured Data

All schema markup needs to be rebuilt from scratch in the new site. Use Google’s Rich Results Test tool to validate the implementation of the following rich data types:

• Article/BlogPosting schema on blog pages
• FAQ schema on service and content pages
• BreadcrumbList schema on relevant pages
• Organization schema on homepage and About page
• LocalBusiness schema on homepage and About page
• Product schema on e-commerce pages
• Service schema on service pages

11. Test the Full Redirect Map on Staging

Before going live, test every redirect listed in the redirect map using a tool like Screaming Frog Redirect Checker or httpstatus.io. Make sure that:

• Every old URL redirects with 301 HTTP code
• Every redirect ends up with correct destination URL
• There are no redirect chains (one hop redirect is max)
• There are no redirect loops

This QA step is mandatory. Finding out about redirect errors on the live site means losing Google crawl budget and time for recovery.

12. Verify XML sitemap and robots.txt on staging

• Your XML sitemap must include all the new URLs you want to get indexed while excluding utility pages, thank-you pages and duplicates
• Robots.txt configuration is correct and does not block Googlebot crawling of the new site (it happens more often than not)
• Canonical tag on all pages point to the correct canonical version

13. Audit page speed on staging

Using Google PageSpeed Insights and Core Web Vitals, check your site’s speed before the launch. If the performance of your new design is worse than on the current site, fix the issues before going live instead of planning to do that later.
Launch Day: The Go-Live Phase

14. Go live in low-traffic hours

Plan for going live Tuesday-Thursday from 10 pm to 2 am local time. Don’t schedule for Friday or Monday.

15. Immediately unblock your crawlers

Right after you go live, make sure that:

• Crawlers aren’t blocked by robots.txt file
• No noindex meta tags appear on the live pages if not supposed to be there
• Staging URL is blocked (this is important to prevent duplicate content issues)

16. Submit XML sitemap to Google Search Console

Right after the launch, submit your XML sitemap to Google Search Console (Settings > Sitemaps) to make Google recrawl your new site.

17. Request indexing for Tier 1 pages

Right after the launch, request indexing for key Tier 1 pages in Google Search Console to speed up the process of crawling and indexing and to understand the situation better. It’s not guaranteed to act immediately.

18. Verify Google Analytics 4 and conversion tracking

Within two hours after going live, confirm that Google Analytics 4 records sessions and goal completions correctly.

Also, optimize triggers of Google Tag Manager on the new site and Google Ads conversion tracking (if applicable).

Post-Migration: The Monitoring Phase

19. Monitor Google Search Console daily for 30 days

Check for:

• Coverage errors: look for errors that spiked in 404 and indicate your missed redirects. Fix them immediately.
• Impressions and clicks drop: after the launch, some temporary decline is expected. 40%+ drop in impressions and clicks sustained over two weeks after the launch requires deeper investigation.
• Manual actions: rare but possible if the new site has some quality issues.
• Crawl stats: check for Googlebot crawling your new site actively and not producing errors

20. Crawl live site within 48 hours

After you’ve launched your website, run Screaming Frog full crawl on it to check for the following issues comparing to your pre-migration snapshot:

• Any URLs returning 404 that should be live
• Broken internal links on the new site
• Missing title tags or meta descriptions across pages
• Incorrect canonical tags
• Any pages accidentally set to noindex

21. Monitor Organic Traffic Trends in GA4

For your new site, you can set up a weekly comparison report to check:

• Organic sessions: current week vs same week prior year.
• Landing page performance to analyse which pages are gaining and losing organic traffic on the site.
• Conversion rate by landing page to understand how the redesign hasn’t introduced UX regressions that hurt conversions.

A 10–20% temporary dip in the first two to four weeks is common as Google recrawls and re-evaluates your site. When your website traffic doesn’t recover to pre-migration levels within 60–90 days of the redesign, it signals a structural SEO problem requiring investigation.

22. Update External Backlinks Where Possible

Contact the domains with the highest-authority backlinks pointing to changed URLs and request link updates to the new canonical URLs. While your 301 redirects will pass the majority of link equity, direct links to the live URL are marginally stronger and high-authority links are worth the outreach effort.

SEO Migration Checklist Summary

Pre-Migration: Before Development Starts, keep the list of:

•  Full site crawl and export
•  GSC and GA4 data export
•  High-value URL inventory (Tier 1–4)
•  Complete redirect map built
•  All on-page SEO elements documented
•  Staging environment configured (blocked from crawlers)
•  Core Web Vitals baseline recorded

During the Website Development

•  URL structure preserved where possible
•  All metadata migrated to new pages
•  All structured data re-implemented
•  Full redirect map tested on staging
•  XML sitemap and robots.txt verified
•  Page speed benchmarked on staging

Launch Day

•  Go-live scheduled for low-traffic hours
•  Crawler blocks removed immediately after launch
•  Updated sitemap submitted to GSC
•  Tier 1 pages submitted for indexing
•  GA4 and conversion tracking verified

Post-Launch Monitoring (First 90 Days)

•  GSC monitored daily for 30 days
•  Full crawl run within 48 hours
•  Weekly organic traffic comparison reports
•  High-authority backlinks updated where possible

A successful SEO migration requires careful preparation, thorough QA, and ongoing post-launch monitoring to ensure your website maintains the traffic and stays across the search engines. Teams that skip this checklist often spend the next six months recovering the lost traffic without any structure.

If your organisation is planning a website redesign in the next six months, start the SEO migration planning now, not when the new design mockups are approved.

Frequently Asked Questions

1. How long does it take to recover SEO traffic after a website migration? 

With a properly executed migration, SEO-optimised and well-established sites recover within four to twelve weeks. Sites where redirects were missed, and the new site has technical issues, may take six to eighteen months to fully recover.

2. Should I change my URL structure during a redesign? 

Only if there’s a strong business or UX reason to do so, and only with a complete redirect map in place. Changing URL structures for cosmetic reasons is rarely worth the risk. If your existing URL structure is logical and SEO-friendly, preserving it during a redesign removes one of the largest sources of migration-related traffic loss.

3. What’s the most common SEO mistake during a website migration? 

Launching with a robots.txt file that blocks Googlebot. This happens more often than you’d expect: developers use robots.txt to block crawlers on the staging site, and the staging configuration accidentally makes it to production. The result is Google being unable to crawl the new site at all, causing rankings to drop to zero within days.

4. Do 301 redirects pass full link equity?

Google states that 301 redirects retain most link equity, but redirect chains dilute value, so use single-hop redirects whenever possible.

5. How do I audit whether my migration caused SEO damage? 

Compare your Google Search Console performance data from the 30 days before and after the migration. Focus on the total impressions, total clicks, and average position for your most important queries. A sustained drop in impressions may indicate an indexing or crawling problem, not just a ranking fluctuation.