Website Migration SEO Checklist: How to Move a Site Without Losing Traffic

A website migration is one of the few projects that can wipe out years of search traffic in a single afternoon. Not because migrations are inherently dangerous, but because they change hundreds of things at once: URLs, templates, redirects, server config, tracking code. Miss one of them and Google notices before you do.

The good news is that almost every migration disaster comes from the same short list of mistakes. This guide covers the types of migration and how risky each one is, a complete three phase SEO checklist (before, during and after launch), the mistakes that cause most traffic losses, and how long recovery really takes according to Google.

What is a website migration?#

A website migration is any significant change to a site's location, structure, platform or technology that can affect how search engines crawl, index and rank it. In SEO terms, the question is simple: will the URLs, the content or the signals Google relies on change? If the answer is yes, you're doing a migration and you need a plan.

Google splits site moves into two kinds:

• Moves with URL changes: a new domain, HTTP to HTTPS, a new URL structure. Every old URL needs a permanent redirect to its new address.
• Moves without URL changes: a new host or CDN. Visitors see the same URLs, but the infrastructure behind them changes.

Types of website migration and their SEO risk#

If you can, avoid combining migrations. Google's own documentation says it's fine to move a site in sections, and changing one thing at a time makes problems far easier to diagnose. If you're only changing the design and keeping your URLs, our guide on how to redesign a website without losing SEO covers that project in detail. This article focuses on migrations where URLs, domains or platforms change.

Phase 1: Before the migration#

Most of the work in a successful migration happens before launch day.

1. Crawl the current site and save everything#

Crawl the live site and export every URL with its status code, title, meta description, canonical, robots meta, H1 and word count. This crawl is your source of truth. After launch, you'll compare against it.

Also export:

• Every URL in your XML sitemaps.
• Your top landing pages from Google Search Console (last 12 months).
• Pages with backlinks, from Search Console's Links report or a backlink tool.
• Your current robots.txt file.
• A list of tracking scripts on key pages: analytics, Tag Manager, ad pixels, chat widgets.

2. Benchmark traffic and rankings#

Record organic sessions, clicks, impressions and conversions per page for at least the last three months. Note your top queries and their positions. Without a benchmark, you can't tell a normal post migration wobble from a real loss.

3. Build the URL map#

Map every old URL to its new URL in a spreadsheet. The rules are simple:

• Every old URL that has traffic, backlinks or a purpose gets a new URL.
• Map one to one wherever possible: old product page to new product page, old article to new article.
• Only map to a broader page (like a category) when there is no equivalent.
• Deliberately retired pages with no replacement can return 404 or 410.

4. Turn the URL map into a redirect map#

Every row in your URL map becomes a 301 (permanent) redirect from the old URL to the new one. Google confirms that 301 and other permanent redirects don't cause a loss in PageRank. A 302 tells Google the move is temporary, which is the wrong message for a migration. Our 301 vs 302 redirect guide explains the difference.

Check the map for chains before launch. If an old URL already redirects to another URL, point it straight at the final destination.

5. Build and protect the staging site#

Build the new site on a staging environment and password protect it. Many teams add a sitewide noindex or a robots.txt Disallow: / to staging instead. That keeps staging out of Google, but it's also the single most common way migrations fail, because those settings get copied to production. Write down every place you blocked indexing so you can remove each one at launch.

6. Test the new site against the old crawl#

Crawl staging and compare it to your saved crawl. Titles, descriptions, canonicals, H1s, structured data and internal links should all carry over. Pay special attention to templates: one broken template can affect thousands of pages.

Phase 2: During the migration (launch day)#

A few notes on these steps:

• The Change of Address tool in Search Console is only for moving from one domain or subdomain to another. Google says you don't need it for HTTP to HTTPS moves, switching between www and non-www, or moving paths within the same domain.
• Keep the old domain. Your redirects only work while you control the old domain, so renew it.
• Submit the new sitemap in Search Console. Google says submitting a sitemap can make discovery quicker.

Test a sample of redirects the moment they go live. The free Redirect Chain Checker shows every hop between an old URL and its final destination, so you can confirm each redirect is a single 301 to the right page.

Phase 3: After the migration#

Launch day isn't the finish line. The weeks after a migration are when most problems are found, and the earlier you find them, the less traffic you lose.

1. Crawl the old URLs#

Take the URL list from your pre migration crawl and request every old URL. Each one should return a single 301 to the correct new URL, and that new URL should return 200. Look for:

• Old URLs returning 404 (missing from the redirect map).
• Redirect chains (old URL to an intermediate URL to the final URL).
• Redirects that land on the homepage instead of the equivalent page.
• New URLs returning 5xx errors under real traffic.

For quick spot checks, the free Bulk URL Status Checker checks up to 20 URLs at once and shows their status codes and redirects.

2. Crawl the new site#

Run a full crawl of the new site and compare it with your benchmark crawl. Look for missing titles, changed canonicals, pages marked noindex, broken internal links and pages that dropped out of the sitemap.

3. Watch indexing in Search Console#

In the Page indexing report for the new property, watch indexed pages rise as the old property's indexed pages fall. Use URL Inspection on your most important pages to confirm Google sees the new URL as canonical. A sudden jump in "Excluded by noindex tag" or "Blocked by robots.txt" means something from staging made it to production. Our guide to detecting an accidental noindex shows how to find the cause.

4. Monitor traffic and rankings for weeks#

Compare organic clicks, impressions and conversions per page against your benchmark every week. A small, broad dip that recovers is normal. A sharp drop concentrated on a section of the site usually means a redirect, template or indexing problem in that section.

5. Keep the redirects#

Google recommends keeping redirects for as long as possible, and generally at least one year. In practice, keep them forever if you can. Backlinks to old URLs will keep arriving for years.

Common website migration mistakes#

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

Google is direct about this. Its site move documentation says to expect temporary fluctuation in rankings while Google recrawls and reindexes the site. As a general rule, a small to medium website can take a few weeks for most pages to move in Google's index, and larger sites take longer.

The move happens one URL at a time. Google says that to consider a move complete, Googlebot has to visit every URL on the old and new site at least once, and how fast that happens depends on the size of the site and how quickly your server can be crawled.

So a realistic expectation is:

• First days: some fluctuation as Google discovers the redirects.
• First few weeks: most important pages swapped to their new URLs in search results.
• One to three months: traffic back near the benchmark for a well executed migration of a small or medium site.

If traffic is still well below the benchmark after a couple of months, don't wait any longer. Something is wrong, usually missing redirects, noindexed pages or a section of the site that Google can't crawl.

Catch migration problems the day they happen#

Manual checks find most problems, but only if someone runs them, and migrations rarely end on launch day. Fixes and follow up deploys keep changing the new site for weeks.

MyKavo takes a baseline of the pages you monitor and compares every scan against it, so it works like a permanent before and after for your migration. On the pages you monitor, it alerts you when:

• A page that loaded starts returning a 4xx or 5xx error (critical).
• A page changes to noindex (critical).
• robots.txt starts blocking all crawlers with Disallow: / (critical).
• The canonical tag changes or disappears (high).
• The title tag is removed (high) or changed (medium).
• A page now resolves to a different final URL, or a new redirect appears.
• A known analytics, Tag Manager or pixel script disappears (high).
• Internal links break. Broken links are grouped into one alert, not one email per link.
• Your sitemap becomes unreachable or loses more than half of its URLs (high).

On a domain or URL change, the final URL alert on your old pages is a quick way to confirm the redirect went live. Approve it as the new baseline, and MyKavo watches the new version from then on.

The bottom line#

A website migration doesn't have to cost you traffic. Crawl and benchmark the old site, map every URL, redirect each one with a single 301, remove every staging block at launch, and then check old URLs, new pages, indexing and traffic for weeks afterward. Most losses come from a handful of preventable mistakes, and almost all of them can be caught the day they happen.

Check your redirects now with the free Redirect Chain Checker, then start free with MyKavo to baseline your key pages before you migrate and get alerted the moment anything breaks afterward.