Loading...

SEO Website Migration Checklist

An SEO website migration checklist is a systematic action plan that protects your organic rankings during any site change, covering pre-launch audit, 301 redirects, technical QA, and post-launch monitoring to prevent ranking loss. Miss a step and you can lose months of SEO work in a week. Get it right and your rankings will not even flinch. This guide walks you through every step, from capturing your baseline data before you touch anything to tracking down backlinks that still point to the old site.

What Is an SEO Website Migration?

An SEO website migration is any change to your site that affects how search engines crawl, index, or rank your pages. That sounds broad because it is. Switching your CMS counts. Moving to a new domain counts. Even a redesign can count if it changes your URL structure or page speed.

Types of Website Migrations

  • Domain migration. You are moving from one domain to another say, oldbrand.com to newbrand.com. This is the riskiest type because every bit of link equity and every indexed URL has to transfer through 301 redirects. Nothing carries over automatically.
  • CMS migration. Switching platforms like WordPress to Webflow, or Magento to Shopify. The problem is these moves usually change URL structures, page templates, and load times all at once.
  • Protocol migration. Moving from HTTP to HTTPS. Lower risk than a domain move, but a misconfigured SSL cert or mixed content errors can still knock rankings.
  • Structural migration. Changing your URL slugs, reorganizing sections, or merging parts of the site. Even if you stay on the same domain, restructured URLs without redirects break your internal link equity and create crawl errors.
  • Redesign migration. Updating your design and templates. People underestimate this one; a template change can quietly break your heading structure, schema markup, and Core Web Vitals without anyone touching a single URL.

Why SEO Matters During a Migration

Google has your existing URLs indexed with years of signals attached, backlinks, and click history, crawl patterns, content structure. When you move the site and those signals be disrupted, rankings drop. The main risks are 404 errors on pages that should redirect, duplicate content from old and new URLs both resolving, deindexing from a misconfigured robots.txt, and broken link equity from chains or missing redirects. A proper checklist makes sure none of those happens by accident.

Pre-Migration SEO Checklist

Most ranking losses are prevented here, before anyone touches the live site. You cannot know what you have lost if you did not measure what you had.

Benchmark Current Performance

Before you touch anything, grab this data:

  • Download your organic traffic by page from GA4, full 12 months. Keep seasonal trends in mind. A traffic drop after migration looks like a crisis if you do not remember it happened every Q4 anyway.
  • Before migration, note your rankings for the 50–100 terms you are targeting. Search Console works fine for this, export a CSV with the URL, keyword, position, and search volume and keep it somewhere you will not lose it.
  • Download your full backlink profile from Ahrefs or Majestic, linking domains, anchor text, and target URLs. You will need this later when you are hunting down links that still point to old pages.
  • Note your Core Web Vitals scores and crawl stats from Search Console. These are your comparison point after launch.

Crawl and Audit the Existing Site

Run a technical, structural, and content audit with Screaming Frog, Sitebulb, or similar before you build anything new. You want to document:

  • Every indexed URL; this becomes your migration scope.
  • Existing 301 and 302 redirects (chains you will need to flatten).
  • Pages with real traffic, backlinks, or conversions; these are your priority URLs.
  • Canonical tags, hreflang attributes any Meta robots rules already in place.
  • Broken internal links and existing 404s, fix these before migration, not after.

Export the crawl to a spreadsheet. This is the input for your redirect map.

Build the 301 Redirect Map

The redirect map is the most important thing you will produce in this whole project. For every URL that is changing, you need a clear old URL → new URL mapping.

A few rules:

  • Always map to the closest topically equivalent new URL. Never redirect a bunch of pages to the homepage just to “cover” them.
  • No chains. Old URL → middle URL → new URL is two hops and Google loses a bit of link equity at each one. Flatten everything to a single-step redirect.
  • Prioritize pages that have backlinks, traffic, or ranking keywords. A page with no links and no traffic is the last thing you need to worry about.
  • Include query string and trailing slash variants if your server treats them as separate URLs.

Prioritize URLs by SEO Value

Not every URL needs the same level of attention. Sort them into tiers:

  • Tier 1 — Critical: Pages with active backlinks, rankings in positions 1–20, or meaningful organic traffic. These have to redirect correctly on day one, no exceptions.
  • Tier 2 — important: Pages with some traffic or indexed content but nothing linking to them. Still redirect, but you can QA these in the first week after launch.
  • Tier 3 — Low value: Thin content, parameter URLs, pages with zero traffic and no links. Redirect to the nearest equivalent or let those 404 if nothing logical exists.

Technical Migration Checklist

This is where implementation happens, and where mistakes cause deindexing, duplicate content, and ranking drops, often before you see any warning in analytics.

Staging Environment Setup

Never run a migration on the live site. Test everything on staging first:

  • Block the staging site from being indexed. Use Disallow: / in robots.txt or put it behind HTTP authentication. A staging site that is indexed before launch creates duplicate content problems at scale.
  • Match your staging environment to production exactly; same server config, CDN rules, and redirect logic.
  • Test every 301 redirect on staging with a crawl tool before you go live. Every Tier 1 URL should return a 301, not a 302, to the right destination.
  • Confirm canonical tags on the new site point to new URLs, not the old domain.

XML Sitemap and Robots.txt Update

Google reads these two files almost immediately after launch. Do not get them wrong:

  • Generate a new XML sitemap for the new URL structure. Only include canonical, indexable URLs. Cut old URLs, unnecessary pagination, and filtered navigation pages.
  • Submit the new sitemap in Google Search Console and Bing Webmaster Tools right after launch.
  • Update robots.txt to allow crawling of everything that matters. In addition, double-check that the staging Disallow: / block is gone before you go live; this is one of the most common and most painful migration errors.
  • If you run a CDN or multiple subdomains, verify robots.txt is serving correctly from every origin.

Schema Markup Migration

Structured data breaks quietly during migrations because it lives in templates that are rebuilt. Stay on top of it:

  • List every schema type on your current site, Organization, Product, Article, FAQ, Breadcrumb List, and LocalBusiness.
  • Check that schema is working in the new templates and validates cleanly in Google’s Rich Results Test.
  • Make sure all schema references (URLs, image paths, canonical links) point to the new domain, not the old one.
  • For e-commerce, product schema with pricing and availability matters for shopping results. Treat it as Tier 1.

Core Web Vitals and Page Speed Check

New templates usually affect page speed. Check before launch, not after:

  • Run Lighthouse and Page Speed Insights on your main page types, homepage, category, product or service pages, blog, in the staging environment.
  • Compare results to your pre-migration baselines. Moving from a lightweight theme to a heavy page builder can double your load time.
  • Check LCP, CLS, and INP. All three affect rankings.
  • Confirm image formats (Web or AVIF), lazy loading, and caching headers are set up correctly on the new stack.

Canonical Tags and Hreflang (International Sites)

Most migration checklists skip or skim this section. Do not:

  • Canonical tags: Every page on the new site needs a self-referencing canonical pointing to the new URL. If you are moving from HTTP to HTTPS, make sure canonicals update from http:// to https://. Mixed canonicals across old and new domains send duplicate content signals.
  • Hreflang: If your site serves multiple languages or regions, every hreflang attribute needs to be updated to the new URLs across all alternate versions. A broken hreflang cluster sends the wrong language version to the wrong country. Recovery takes weeks.
  • After staging setup, crawl the hreflang implementation. Each language version should reference all others, including itself with the updated URLs.

AI Search and Answer Engine Migration Checklist

Most migration guides do not cover this at all. That is a problem, because AI search engines like ChatGPT, Perplexity, and Google’s AI Overviews are real traffic sources now and a migration can break your visibility in all of them.

Ensuring AI Crawlers Aren’t Blocked

AI search engines have their own crawl bots, and sites block them by accident all the time during migrations:

  • GPTBot (OpenAI/ChatGPT): Check your robots.txt for User-agent: GPTBot with Disallow: /. If you copied robots.txt from the old site, your GPTBot rules came with it make sure they are what you actually want.
  • ClaudeBot (Anthropic): Same check. User-agent: ClaudeBot with Disallow: / stops Anthropic from indexing your content for citations.
  • PerplexityBot: Perplexity crawls for real-time answers. Block it and your content disappears from Perplexity results.
  • Google-Extended: This one controls whether Google uses your content for AI training and Gemini responses, separate from standard Googlebot access.

After migration, go through your new robots.txt line by line for these user agents. If you want AI visibility, make sure none of them is blocked. If you want to opt out, fine but do it on purpose, not because you copied a staging file.

Preserving Content Structure for AI Citations

AI engines do not just crawl pages; they pull structured answers from them. If you are content structure breaks during migration, you stop being cited:

  • Keep your heading hierarchy clean H1, then H2, then H3. AI models parse document structure to extract answers. A page with no clear headings is ignored.
  • Keep definition-first paragraphs. “X is [definition]” at the top of a section is exactly what AI engines pull for answer boxes.
  • Do not migrate FAQ content into JavaScript accordions without server-side rendering. If the FAQ text is not in the initial HTML, AI crawlers and Google’s mobile-first crawler will not see it.
  • Do not cut supporting paragraphs to “clean up” pages during migration. That word count exists for a reason, it signals topical depth.

Does Migration Affect ChatGPT/Perplexity Visibility?

Yes, at least temporarily, ChatGPT’s knowledge base has a training cutoff, so domain changes will not show up there right away. Perplexity is different, it crawls in near real-time and will pick up your new URLs within days. If you block PerplexityBot, return 404s on migrated pages, or significantly thin out your content, your citation rate drops fast. Google’s AI Overviews are tied to Googlebot indexing, so if your pages are not indexed after launch, which happens when robots.txt is misconfigured, they will not appear in AI Overviews either. Treat AI crawler access as a first-class migration task, not something to check later.

Post-Migration SEO Checklist

Launch day is the start of monitoring, not the finish line. Most migration-related ranking drops show up 2–6 weeks after go-live, not immediately.

Search Console and Bing Webmaster Tools Change of Address

For domain migrations, the Change of Address tool tells Google to formally transfer signals from the old domain to the new one:

  • Verify both the old and new domain in Search Console before you submit anything.
  • Go into the old domain’s Search Console property and submit the change of address pointing to the new domain.
  • Do it within 24 hours of launch. Processing typically takes 6–12 weeks for established sites.
  • Do the same in Bing Webmaster Tools, it has its own site move notification and it is separate from Google’s.

Monitoring Rankings and Organic Traffic

Get tracking set up before launch so you have data from day one:

  • Make Search Console a daily habit for the first two weeks after launch. Keep watching impressions, clicks, average position, and indexing. Any sudden shift needs a closer look right away.
  • Compare organic sessions week-over-week in GA4 against the same period last year. A 10–15% swing is normal post-migration. Beyond that, something needs investigating.
  • Keep a daily eye on your Tier 1 keywords. Any term sliding 5+ positions is a red flag — jump straight into your redirects and Search Console indexing report.
  • Watch crawl stats in Search Console. A spike in crawl errors or a drop in pages crawled means something in your redirect map or robots.txt is not working.

Tracking 404 Errors in GA4

404 errors tell you exactly where your redirect map has gaps:

  • In GA4, build an exploration report filtering for page paths where the page title contains “404” or “not found.”
  • Match those URLs against your redirect map. Every 404 that shows up is a missing or broken redirect.
  • Prioritize any 404s that appear in your backlink profile. Those are direct link equity leaks.
  • Set up a Search Console filter for “Not found (404)” under Coverage so you can see what Google is hitting too.

Backlink Profile Recovery

Redirects transfer most link equity, but a direct link to the new URL is always stronger:

  • Pull your full backlink profile from Ahrefs or Majestic again 2–4 weeks after launch.
  • Find high-authority referring domains (DA 50+) that still link to old URLs. Reach out and ask for a link update to the new URL.
  • Disavow any toxic links that transferred from the old domain. Migration is a good time to clean that up.

How Long Does an SEO Migration Take?

It depends on site size, but here is a realistic range:

  • Small site (under 200 pages), CMS or redesign migration: 4–8 weeks. Two to three weeks of prep, one week of staging QA, a few weeks of post-launch monitoring.
  • Medium site (200–5,000 pages), structural or domain migration: 3–5 months. The redirect map alone can take 2–4 weeks to do properly, and you should monitor for 8–12 weeks after launch.
  • Large site (5,000+ pages), full domain migration: 6–12 months start to finish. Enterprise migrations have multiple stakeholders, phased rollouts, and long monitoring periods.

For rankings to fully recover, meaning back to or above where you were before, expect 3–6 months on a clean migration. A messy one can take 12+ months.

How Much Does an SEO Migration Cost?

It varies a lot based on who is doing it and how big your site is:

  • In-house migrations are mostly a tools and time cost. Screaming Frog runs ~$260/year, Ahrefs or SEMrush adds $100–$500/month, and you will need developer hours for the redirects. Tool spend sits around $300–$600/year, team time is on top of that.
  • A full agency-managed migration for a mid-size site runs $5,000–$20,000 typically. Page count, redirect volume, and content scope are what push the number up or down.
  • For enterprise or large e-commerce sites, migration budgets regularly hit $50,000–$150,000+. The scale of the redirect map, content, and QA work alone justifies it.
  • Do not just budget for the migration, budget for what happens if it goes wrong. Lost traffic, lost revenue, and months of recovery work are the real cost of a migration that was not done properly.

Common SEO Migration Mistakes to Avoid

These mistakes cause the ranking drops this checklist is designed to prevent.

  • Skipping benchmarks. If you do not measure before, you cannot measure after. Always capture traffic, rankings, and backlinks first.
  • Using 302 instead of 301 redirects. A 302 is temporary, Google does not transfer link equity through it. Every migration redirect should be a 301.
  • Redirect chains. A → B → C loses equity at every hop. Flatten all chains to one-step before launch.
  • Not updating internal links. Redirects help, but internal links should point directly to new URLs. Redirected internal links slow down crawling and waste crawl budget.
  • Going live with a blocking robots.txt. Copied from staging and never updated. The result is full deindexing within days. Arguably, the single worst migration error you can make.
  • No sitemap submission after launch. Google finds new URLs faster with a sitemap. Without one, recrawling a large site can take weeks.
  • Ignoring mobile and page speed. New templates tend to be heavier. Google indexes mobile-first. A slow mobile site loses rankings no matter how clean the redirects are.
  • Skipping the Search Console change of address. For domain migrations, this is what tells Google to formally transfer ranking signals. Without it, you are waiting for Google to figure it out on its own much slower.
  • Migrating thin content as-is. If a page was thin before, it will be thin after. Migration is the right time to improve it, not carry it over unchanged.
  • Missing content cannibalization. Structural migrations sometimes combine sections that were separate, creating multiple pages chasing the same keyword. Fix cannibalization during migration, not months later.

Frequently Asked Questions (FAQs)

Does changing domains hurt SEO?

Yes, temporarily. Your backlinks and ranking signals do not automatically follow you to a new domain; they need to be transferred through 301 redirects. Google then takes time to recrawl and settle the new domain into its rankings. Volatility for 4–12 weeks is normal. Do it right and you are recovered within 3–6 months.

How long until rankings recover after migration?

Do it right and rankings are back on track within 3–6 months, stabilizing in the first 6–12 weeks. Cut corners and recovery can stretch well past 12 months — and some of those losses will not come back at all.

Can I migrate without losing rankings?

Nearly. Get your prep and redirects right and traffic loss stays under 10%; usually short-lived too. Go in without a plan and drops of 30–70% are common, with recovery taking months.

Does a redesign count as an SEO migration?

Yes, if anything under the hood changed. A redesign that shifts URLs, swaps templates, alters content, or affects page speed needs the full migration treatment. A visual-only refresh does not. When in doubt, run the checklist anyway.

Do I need to update Google Analytics during a migration?

Yes, switch your GA4 data stream, custom events, and conversion tracking over to the new domain. If you do not, the numbers you are using to monitor recovery will not be accurate.

Will local SEO rankings be affected?

Local rankings can slip if you are not careful. Update your Google Business Profile and check your citations as soon as you are live. NAP inconsistencies across directories are easy to miss and they will hurt local visibility even if your organic rankings recover without a problem.

Should I migrate and redesign at the same time?

Avoid it. If rankings drop, you will not know what caused it. Migrate first, redesign after. If you must do both, document every change and keep a rollback plan ready.

What happens to PPC campaigns during a migration?

They break if you do not update destination URLs before launch. Old URLs hit redirects or 404s and hurt quality scores. Update all ad URLs directly in Google Ads, do not rely on redirects.


You May Also Like

we are the best company giving services of UI UX designing, web developing or SEO since 2001.