The Ultimate SEO Website Migration Guide [Free Checklist]

Website migrations are a big deal. The result can be incredibly exciting and help take your business to its next level.

Get it right, and you come out stronger. Get it wrong, and you’re spending the next year trying to claw back traffic you didn’t need to lose.

Most of the horror stories come from poorly planned migrations and those done without any SEO involvement. With the right planning and process, a migration doesn’t have to mean a traffic drop at all.

We’ve run migrations for publishers, SaaS companies, ecommerce brands, and lead generation sites. Based on hundreds of projects completed, this is the step-by-step SEO migration checklist we follow on every single one.

What Is a Website Migration?

A site migration is any large-scale change to your website that could affect how search engines crawl, index, and rank your pages. It’s not just “moving a website.” The term covers a range of scenarios, and some carry more SEO risk than others.

Types of Website Migration

Domain change occurs when you move from one domain name to another, typically during a rebrand. This is the highest-risk migration type because you’re essentially asking Google to transfer all of your ranking signals to a completely new address.

CMS migration involves switching from one content management system to another, like moving from WordPress to Webflow, or from a custom-built platform to Shopify. Even when the domain stays the same, the underlying URL structure, templates, and technical setup almost always change.

Structural changes include reorganising your URL hierarchy, consolidating subdomains, or redesigning how content is categorised across the site.

Redesign with URL changes covers situations where the visual overhaul also touches the information architecture, page templates, and URL patterns.

Server or hosting change is the simplest migration type from an SEO perspective. If the URLs, content, and structure stay the same, the risk is minimal. But server speed, uptime, and geographic location still matter.

The risk level scales with how much changes. A hosting swap with identical URLs is low risk. A full domain change combined with a CMS switch and a new URL structure? That’s the kind of migration that needs serious planning.

Why Do Website Migrations Impact SEO?

Most migration failures come down to one thing: SEO wasn’t part of the conversation early enough.

The development team builds the new site, everyone gets excited about the new design, and then someone remembers to ask about redirects two days before launch.

By that point, it’s too late to do it properly.

“If we want to get very specific, the number one reason migrations fail isn’t technical: it’s organisational. It’s surprising how much of the time SEO isn’t part of the discussion during the planning phase. The reasons for that are varied, from poor development partners to a simple lack of knowledge.”

Filip Ruprich, Head of Technical SEO

Here are some common causes why traffic drops after a site migration:

Missing or Broken Redirects

The most common culprit. If your old URLs aren’t properly redirected to their equivalents on the new site, you lose the link equity those pages accumulated over months or years. Worse, visitors and search engines both land on 404 pages.

Blanket Redirects to the Homepage

This happens when someone takes a shortcut and points every old URL to the homepage instead of mapping each page to its closest equivalent. Search engines treat this as a soft 404, and you’ll lose rankings for all of those pages.

Noindex Tags Left on the New Site

A painfully common mistake. During development, the staging site has noindex tags to keep it out of Google. If those aren’t removed before launch, Google starts deindexing your entire site.

Content Changes that Weren’t Evaluated for SEO Impact

The new site launches with rewritten copy, consolidated pages, or removed content that was actually driving traffic. If nobody checked which pages had organic value, that value disappears.

Broken Internal Linking

The internal link structure doesn’t get updated to reflect the new URL patterns, creating chains of redirects or dead links throughout the site.

All of these problems are preventable with proper planning. That’s where the checklist comes in. You can download it by clicking on the button below, and also learn about each of the action items from list in more detail below. We break our migration process into four stages.

Stage 1: Build the Plan Before You Touch Anything

Before anyone touches code or design files, you need a clear plan. This stage is about understanding the scope of the migration, defining roles, and building the roadmap that will guide the rest of the project.

Define the Migration Type and Scope

Get specific about what’s actually changing. Is it just the CMS? The domain? The URL structure? All three? The answer determines how much work is ahead and what level of risk you’re dealing with.

• Will the domain name change?
• Will the URL structure change?
• Is the CMS changing?
• Are content changes planned?
• Who is handling implementation, your team or an external partner?
• What’s the target timeline?

Benchmark Current Performance

You cannot measure the success of a migration without knowing where you started. Before anything else, document:

• Your current organic traffic levels (Google Analytics and Search Console). 
• Keyword rankings for your priority terms. 
• Backlink profile (total referring domains and pages with the most inbound links). 
• Page-level performance, including which pages drive the most traffic, conversions, and revenue. 
• Core Web Vitals scores.
• Current indexed page count.

Export all of this data and save it somewhere safe. You’ll reference it constantly during and after the migration.

Identify Priority Pages

Not every page on your site carries equal weight. Some pages drive 80% of your traffic and conversions. These are the ones that absolutely cannot break during migration.

Pull a list of pages that have the highest organic traffic, generate the most conversions or revenue, have the most referring domains (backlinks), and rank for your most important keywords.

These pages get extra attention at every stage: redirect mapping, content review, pre-launch testing, and post-launch monitoring.

Secure Access to Everything

Your SEO team needs access to Google Analytics, Google Search Console, Google Tag Manager, the staging or development environment, and the CMS for both the old and new sites. Without this, the team is working blind.

Build a Migration Roadmap

Create a detailed timeline with milestones for each stage of the process. Include who’s responsible for what, and build in time for review cycles. Migrations always take longer than expected, so pad the timeline accordingly.

Stage 2: Audit Everything and Map Your Redirects

This is the heavy-lifting stage. You’re auditing the current site, auditing the new site, and building the redirect map. Most of the SEO work happens here.

Crawl and Document the Current Site

Run a full crawl of your existing site using a tool like Screaming Frog, Sitebulb, or Ahrefs. Export everything: URLs, title tags, meta descriptions, H1s, canonical tags, structured data, internal links, and images.

This crawl becomes your master reference document. Every URL on the current site needs to be accounted for in the migration plan.

Audit the New Site

Before the new site goes live, crawl the staging environment and review it thoroughly. This audit should cover:

URL structure. Are the new URLs clean, descriptive, and logically organised? If the URL patterns are changing, does the new structure make sense for both users and search engines?

Content parity. Is the content on the new site at least as well-optimised as the current site? Have any high-performing pages been removed, merged, or altered?

Title tags and meta descriptions. Check that every page has unique, optimised meta tags. It’s common for new CMS setups to have template-generated meta tags that are either blank or duplicated across pages.

Internal links. Are internal links pointing to the correct new URLs, or are they still referencing old URLs that will need to redirect?

Image optimisation. Check alt tags, file names, and file sizes. A new design often introduces larger, unoptimised images that slow the site down.

Structured data. If your current site uses schema markup (product, article, FAQ, organisation), verify that it’s properly implemented on the new site. Structured data matters not just for rich results but for visibility in AI-generated search answers.

Mobile experience. Test the new site across multiple devices. Google uses mobile-first indexing, so what Googlebot sees on mobile is what counts.

XML sitemap. Confirm the new site generates a valid XML sitemap with correct, up-to-date URLs.

Robots.txt. Make sure the staging site’s robots.txt is blocking crawlers, but have a production-ready version prepared that opens everything back up at launch.

Custom 404 page. Verify that the 404 page works properly and helps users find their way back to useful content.

Site speed and Core Web Vitals. Test the staging site’s performance. If it’s slower than the current site, flag it now. Don’t wait until after launch.

Tracking setup. Confirm that Google Analytics 4, Google Tag Manager, and any other tracking tools are correctly implemented on the new site.

Create the Redirect Map

This is arguably the most important deliverable in the entire migration process. The redirect map is a spreadsheet that matches every old URL to its corresponding new URL.

For each URL, document the old URL path, the new URL path, and the redirect type (almost always 301, or permanent). Prioritise pages with the most traffic, backlinks, and keyword rankings.

A few rules for redirect mapping:

1. Every page that received organic traffic or has external backlinks should redirect to the closest equivalent page. If there’s no direct equivalent, redirect to the next most relevant parent category page. Never redirect everything to the homepage.
2. Use 301 redirects, not 302s. 302 redirects signal a temporary move, and search engines may not transfer ranking signals. 
3. Avoid redirect chains. If page A already redirects to page B, and now page B needs to redirect to page C, update the redirect so A goes directly to C.

For large sites, this can involve thousands of rows. Automated tools can help with the initial mapping, but every high-priority URL should be reviewed manually.

Review the New Domain History (If Applicable)

If the migration involves a new domain, check its history. Use the Wayback Machine and backlink tools to see if the domain was previously used for anything that could carry a negative reputation with search engines. 

A domain with a history of spam or penalties can drag down your new site before it even launches.

Verify All SEO Elements

Walk through the staging site page by page (or at least page type by page type) and confirm:

• title tags and meta descriptions match the plan,
• canonical tags are in place and pointing to the right URLs,
• noindex tags have been removed (this is critical),
• hreflang tags are correct (for multilingual sites),
• structured data validates without errors, 
• and internal links use the new URL structure directly.

Check Tracking and Analytics

Load the staging site and verify that Google Analytics fires correctly on every page, conversion tracking works end to end (test forms, checkout flows, phone tracking), and Google Tag Manager loads the correct container.

Run a Final Crawl

Crawl the staging site one more time. Compare the results against your original crawl of the current site and against the recommendations document. Flag anything that doesn’t match.

Coordinate Launch Timing

Don’t launch on a Friday. Don’t launch during your peak traffic period. Don’t launch the night before a major holiday. 

Pick a time when your full team is available to monitor, troubleshoot, and respond quickly if something goes wrong. A Tuesday or Wednesday morning is usually the safest bet.

Stage 3: Launch Day

Launch day is an all-hands-on-deck situation. The new site goes live, and you need to verify everything in rapid succession.

Verify Indexing Settings

This is the first thing to check. Confirm that noindex tags have been removed from all pages that should be indexed, robots.txt allows crawling of all important areas of the site, and canonical tags point to the correct live URLs (not staging URLs).

One leftover noindex tag on the staging environment can prevent your entire site from being indexed. Don’t let this be the mistake that derails your migration.

Check Redirects on the Live Site

Test your priority URLs one more time now that the site is live. Sometimes redirects work on staging but break in production due to server configuration differences. Test both on desktop and mobile.

Submit Your Updated Sitemap

Submit the new XML sitemap to Google Search Console immediately. If you’ve moved to a new domain, set up the new property in Search Console and use the Change of Address tool to notify Google of the move.

Verify Google Analytics and Tracking

Check that real-time data is flowing into Google Analytics 4. Test conversion paths by submitting a form, completing a purchase, or whatever your primary conversions are. Confirm that goals and events are tracking correctly.

Force-Index Key Pages

Use the URL Inspection tool in Google Search Console to request indexing of your most important pages. Google will get to them eventually via the sitemap, but requesting indexing speeds up the process for your highest-priority content.

Run a Crawl of the Live Site

Run a full crawl with Screaming Frog or your preferred tool. Check for 404 errors, redirect chains, missing meta tags, broken images, and any other technical issues that may have appeared during the switch.

Monitor Google Search Console

Over the next few hours and days, keep a close eye on the Coverage report (or Page Indexing report) in Search Console. You should see your new pages being indexed and your old pages gradually being deindexed. Any spike in errors or excluded pages needs immediate investigation.

Stage 4: Monitor, Measure, Fix

The work doesn’t stop at launch. The first 4 to 8 weeks after migration are critical for catching issues and tracking recovery.

Monitor Indexation

Track how quickly Google indexes your new pages. Compare the number of indexed pages in Search Console against your target. If the numbers aren’t climbing, investigate whether crawl issues, noindex tags, or canonical tag problems are holding things back.

Track Keyword Rankings

Monitor your priority keywords daily for the first few weeks, then weekly after that. Some fluctuation is normal. A temporary dip in rankings is expected as Google processes the changes. But if rankings for your top terms haven’t started recovering within 2 to 3 weeks, dig deeper.

Analyse Organic Traffic Trends

Compare post-migration traffic against your benchmarks. Use Google Analytics to segment organic traffic and watch for patterns. Are certain sections of the site underperforming? Are there pages that lost traffic disproportionately after migration?

Review Site Performance

Check page speed and Core Web Vitals on the live site under real traffic conditions. Performance issues that didn’t show up in staging may emerge once the site handles actual user load.

Check for Crawl Errors

Continue monitoring Search Console for new crawl errors, 404s, and server errors. These tend to trickle in over the first few weeks as Google recrawls different parts of the site.

Document Findings and Plan Next Steps

After 3 to 4 weeks, compile your findings into a post-migration performance review. Document what went well, what needs attention, and what the next steps are for ongoing SEO. 

Website Migrations and AI Search

Until recently, a site migration checklist was purely about protecting your traditional search rankings. That’s no longer the full picture. AI-powered search has added a completely new layer of visibility that can be disrupted during a migration, and most guides still don’t address it.

“Most migration checklists still haven’t caught up with how AI search actually works. If you’re not benchmarking your AI citations before launch and tracking them after, you’ve got a blind spot that could cost you visibility you didn’t even know you had.”

Filip Ruprich, Head of Technical SEO

Google’s AI Overviews, ChatGPT, Perplexity, and similar tools don’t just index your site. They summarise, synthesise, and cite content from across the web.

During a migration, you risk losing that AI visibility if:

• Previously cited content is removed or restructured without maintaining its topical identity. 
• Schema markup is lost or improperly implemented on the new site. 
• The topical authority signals that AI models rely on get diluted through poor redirect mapping.

To protect your AI search visibility during a migration:

1. Preserve structured data (especially Article, FAQ, Product, and Organisation schema) and make sure it validates correctly on the new site. 
2. Maintain content depth and topical clustering. If AI models have been citing your content for a specific topic, don’t dilute those pages. 
3. Verify that your most authoritative content retains its URL structure, or at a minimum redirects cleanly to its new location.

Benchmark Your AI Visibility Before Migration

This is a newer practice, but it’s becoming standard for thorough migrations. Before you launch, check whether your content currently appears in AI-generated answers.

Run your key queries through ChatGPT, Perplexity, and Google’s Gemini either manually, or by using an AI search visibility checker tool. Note which of your pages get cited and for which queries.

After the migration, run the same queries again. If your citations have dropped, you have a clear signal that something in the migration disrupted your AI visibility, and you can work backwards to identify the cause (broken schema, removed content, lost internal links, etc.).

Don’t Leave Your Rankings to Chance

A successful site migration isn’t measured by a clean launch on day one; it’s measured by your traffic levels 90 days later.

Whether you are switching CMS, rebranding, or restructuring your URL architecture, the technical debt of a botched migration can haunt your organic performance and AI search visibility for years.

By following a rigorous, data-led process – from pre-launch benchmarks to post-launch monitoring – you transform a high-risk liability into a growth opportunity.

At SUSO, we protect your digital footprint, ensuring that your authority transfers seamlessly from the old environment to the new, while optimizing for the next generation of AI-driven search.

FAQs About Site Migrations

• How long does an SEO migration take to complete?

  The hands-on SEO work for a migration typically takes anywhere from a few weeks to 3 or 4 months, depending on the site’s size and complexity. A small business site with 50 pages is a very different project from an e-commerce site with 10,000 product pages.

• How long does it take to recover traffic after a site migration?

  This varies enormously. A Search Engine Journal study of 892 domain migrations found the average recovery time was 523 days. But that average includes poorly executed migrations and sites that never recovered at all. Well-planned migrations often see traffic stabilise within 2 to 8 weeks.

• How many hours should I budget for SEO migration work?

  Based on our experience, a typical migration involves roughly 60 to 100+ hours of SEO-specific work, spread across the planning, analysis, pre-launch testing, launch day, and monitoring stages. Smaller sites fall at the lower end, while large or complex migrations push well beyond 100 hours.

• Can I make content changes at the same time as a migration?

  You can, but be careful. Every change you make at the same time as a migration makes it harder to diagnose problems if traffic drops. Where possible, keep the migration itself focused on the structural and technical move. Content changes are better handled as a separate phase after the migration has stabilised.