Website migrations: how to move a site without losing its search traffic

A website migration is any change that alters how search engines find, crawl or understand a site that already ranks. Some are mundane, such as moving to a new host. Others change almost everything at once: the domain, the platform, the URL structure and the templates. Search engines have spent years learning the old site, and a migration asks them to relearn it. The work is about making that relearning quick and unambiguous.

This guide covers each type of move and its risk, the planning that should start months before launch, redirect mapping, staging, the launch itself and what to watch afterwards. If you are moving an online shop between platforms, read it alongside the ecommerce SEO guide, because catalogues add their own problems. (If Shopify is on either side of the move, I have written up what changes when you migrate to or from Shopify.) If the move touches country or language sites, the international SEO guide covers the structure decisions.

Risk depends on how many things a search engine has to re-establish. If the URLs stay the same, Google mostly has to notice that the same pages are now served from somewhere else. If the URLs change, every ranking page has to be recrawled, its redirect followed, and its signals consolidated onto a new address. If the content and templates change too, Google is also re-evaluating the pages themselves.

Most real projects combine several of these. A replatform nearly always changes URLs and templates, and businesses often add a redesign and a content rewrite because "we are rebuilding anyway". The safer plan is the opposite: make the changes one after the other, not all at the same time.² I agree with that where the business allows it. If a combined move goes badly, you cannot tell whether the redirects, the templates or the content caused it, and that slows recovery.

Google publishes two separate guides, and Bing has its own tool. Start by working out which Google guide applies to you.

• Moves without URL changes, such as switching hosting provider or moving to a CDN. The steps are to lower the DNS TTL to a few hours at least a week in advance, check the new infrastructure does not block Googlebot, and only shut down the old hosting once traffic to it reaches zero.¹
• Moves with URL changes, which covers protocol, domain and path changes. This is the guide most migrations need. It covers URL mapping, permanent server-side redirects, updating internal links and annotations, sitemaps, Search Console verification of both sites, and monitoring.²
• For Bing, Bing Webmaster Tools has a Site Move tool for announcing the move. A migration guide on Bing’s webmaster blog, written by Fili Wiese of SearchBrothers, also covers 301 redirects, keeping them live on the old domain for at least one to two years, and expecting some fluctuation in visibility even after a well-planned move.³

Google’s guides are short. Read them in full before planning starts, because most of the timing claims quoted about migrations come from them.

You cannot judge a migration without a record of the site before it moved, and once the old site is gone most of this data is impossible or tedious to recreate. Capture it early, and capture it again in the week before launch.

• A full crawl of the old site, saved and exportable: every URL, status code, title, meta description, canonical, hreflang, word count, internal link count and structured data type. This becomes the checklist the new site is compared against.
• Search Console performance data by page and query, exported at the longest window available. Search Console only keeps a limited history, and you will want the old URLs’ numbers months after launch.
• Organic traffic and conversions by template or section (category pages, product pages, articles, location pages), not only as a site total. A migration that holds the total but loses one template is still a failure, and the total will hide it.
• Rankings for a representative set of queries per template, if you track rankings.
• Backlinks to deep URLs. Links to the homepage usually survive any migration. The value at risk is in links pointing to articles, products and tools several levels down, because those are the URLs most likely to be missed in a redirect map.
• Current indexing state from the Page indexing report, so you know which problems existed before launch and do not blame them on the move.⁵
• Server logs, if you can get them, showing which URLs Googlebot requests and how often. They show URLs no crawler or analytics tool will surface.

The redirect map is only as good as the list of old URLs it starts from, and no single source has them all. A crawler only finds URLs that are linked internally. Analytics only knows URLs that received visits. Search Console only reports URLs Google has seen. Orphaned pages, retired campaigns and old PDFs with good backlinks fall through the gaps, and they are often the URLs that matter.

Combine them into one list, normalise the URLs (protocol, trailing slash, case, parameters), and remove duplicates. Then tag each URL with its traffic, links and template so you can prioritise. On a large site you will not hand-check every row, but you should hand-check every URL that carries meaningful traffic or links.

The core of the move is a mapping from each current URL to its new equivalent, served as permanent server-side redirects.² In the HTTP standard, a permanent redirect means the resource has a new permanent URI and future references ought to use it.⁶ For Google, redirects are one of the strongest signals for picking a canonical URL, alongside rel="canonical".⁷ So a clean redirect map does most of the work of carrying rankings across. I have written up how to build the redirect map step by step, from the spreadsheet columns to testing it on staging.

Map one to one wherever an equivalent exists

Each old URL should redirect to the single new URL that best matches its content and intent. A product redirects to the same product. A category redirects to the same category, even if it has been renamed. Where two old pages have been merged, both redirect to the merged page. Pattern rules (for example, every /blog/yyyy/mm/slug to /articles/slug) are fine for templates with a clean pattern, but test them against the full inventory, because exceptions are where pattern rules break.

Never send everything to the homepage

Redirecting large numbers of old URLs to the homepage, or to any single irrelevant page, is the shortcut that costs the most. Google might treat such redirects as soft 404s,² and in practice that means the old URL’s signals are not passed on. If a page has no equivalent on the new site, let it return a 404 or 410.² A 410 is the more specific of the two: the HTTP standard defines it as a resource that is no longer available, with the condition likely to be permanent.⁶ A redirect to the nearest relevant parent (a discontinued product to its category, for example) is a reasonable middle ground when the parent serves the same need.

Avoid redirect chains

Sites that have been migrated before usually carry old redirects. Add a new migration on top and an old URL can hop three or four times before it lands. Googlebot can follow up to 10 hops, but redirecting straight to the final destination is the safer setup.²⁸ Search Console’s Page indexing report shows a chain that is too long, or a loop, as a redirect error.⁵ Before launch, flatten every existing redirect so it points at the final new URL, and include those legacy URLs in your test list.

Choosing between 301, 308, 302 and 307

To change how a URL appears in search results, use a permanent server-side redirect wherever possible. JavaScript redirects are the last resort, for when server-side and meta refresh redirects are not available.⁹ HTTP redirects also run first in browsers, before any page loads, and MDN advises against keeping meta refresh redirects alongside them, because the two can drift apart and cause loops.¹¹ Some platforms and plugins default to temporary redirects, so check the status code the server returns. The setting in the admin screen can be wrong.

Keep redirects for as long as possible, and generally at least one year.² Google’s John Mueller gave the reason in a 2021 Ask Googlebot video: its systems need to see a redirect a few times to record the change, and recrawling takes time.¹² The migration guide on Bing’s blog goes further, at least one to two years and preferably longer.³ Treat a year as a minimum. Backlinks, bookmarks, old emails and printed material keep sending people to old URLs for years, and a redirect costs almost nothing to keep. I would only remove a migration redirect when the old URL has had no meaningful requests in the logs for a long period, and even then I would question why it is worth the effort.

For a domain change, keep control of the old domain. Letting it lapse removes every redirect at once, and someone else can register it.

The Change of Address tool

Search Console’s Change of Address tool tells Google that a whole site has moved from one domain or subdomain to another.¹³ It only applies to that kind of move. It is not for HTTP to HTTPS changes, path changes within a domain, www to non-www changes, or hosting changes where the URLs stay the same.¹³

• You must be an owner of both the old and new properties in Search Console, using the same Google account.¹³
• The old homepage must 301 redirect to the new one, and the tool works on domain-level properties, not path-level ones.¹³
• The tool’s effect lasts 180 days, and Search Console asks you to keep the redirects for at least that long.¹³ Read that alongside the one year guidance above, and keep them longer.

Whether or not the tool applies, verify both the old and new sites in Search Console, including all their variants.² Add both to Bing Webmaster Tools as well, which is where Bing’s Site Move tool lives.³ Do this before launch so the old properties have data for comparison.

A staging site has to be kept out of search, and the way most teams do it causes the most common launch failure. The two usual tools behave differently, and the difference matters at both ends of the project.

• robots.txt controls crawling, not indexing. The standard itself says its rules are not a form of access authorisation,¹⁴ and a URL blocked by robots.txt can still be indexed without a description if other pages link to it.¹⁵
• A noindex directive keeps a page out of the index, but only if Google can crawl the page and see it. If robots.txt blocks the page, the noindex is never read.¹⁶
• Password protection or IP allow-listing keeps everything out, including crawlers. Password protection is one of the documented ways to keep a page out of Google.¹⁵ This is the method I would use for staging, because it cannot be accidentally inherited as a search directive.

Staging also matters for testing. If it is password protected, your crawler needs credentials to crawl it, and you should crawl staging in full before launch: every old URL through the redirect rules, every new template for status codes, canonicals and directives.

Redirects carry signals from old URLs to new ones. The new pages still have to deserve the rankings they inherit, and every internal signal on the new site has to agree on which URLs are canonical. Updating internal links, canonicals and hreflang is part of the move itself.²

Submitting a sitemap of the old URLs alongside the new one after launch helps Google discover the redirects sooner, and lets you watch indexing shift from one to the other over time.² Remove the old URL sitemap once most of those URLs have dropped out of the index. Leaving it in place indefinitely lists URLs you do not want in search, which contradicts the guidance on sitemap contents.

Platform changes increasingly mean a move to a JavaScript framework or a headless front end. That changes how Google gets the content. Google crawls, renders and indexes in separate phases, with rendering done by a headless Chromium that executes the page’s JavaScript.²⁰ Content and links that exist only after rendering depend on that step working.

• Server-side rendering or pre-rendering is still worth having, partly because not all bots can run JavaScript.²⁰ Research by Vercel and MERJ, published in December 2024 from crawler traffic on Vercel’s network, found that none of the major AI crawlers it measured rendered JavaScript, including those from OpenAI and Anthropic.²¹ The AI search guide covers what that means for visibility in assistants.
• Links need to be real <a> elements with href attributes. Those are what Google can reliably follow, and the History API is the supported way to handle client-side routing, not URL fragments.²⁰
• Single-page applications must return meaningful status codes. A "not found" view served with a 200 is a soft 404.²⁰
• Do not ship a noindex in the initial HTML and rely on JavaScript to remove it. Google may skip rendering when it sees noindex in the HTML, so the JavaScript never runs.²⁰
• Canonicals should be in the server HTML, and JavaScript should not change a canonical to a different URL from the one in the HTML.²⁰

To test it, compare the raw HTML response of each new template with the old one: titles, canonicals, body copy, internal links and structured data. Then inspect a sample of rendered pages with the URL Inspection tool in Search Console. If the raw HTML of the new site is much thinner than the old one, treat that as a launch blocker.

Launch in a quiet trading period with the developers who built the redirects available for at least the following week. Google crawls a moved site more heavily than usual for a while, so make sure the servers can take it.²

Any significant change can bring ranking fluctuations while Google recrawls and reindexes, and on a medium-sized site it can take a few weeks or more for new URLs to replace old ones in results, longer for large sites.² That is the only timeline Google gives, and it describes URLs being swapped in results. Traffic is a separate question. SALT.agency’s 2026 study of 1,052 domain migrations, some its own and the rest crowdsourced from other SEOs, measured how long the new domain took to match the old domain’s pre-migration monthly organic traffic. The median was 304 days and the mean 489, and roughly one in four recovered within 90 days.²³ It covers domain changes only and, by its own account, does not analyse which migration practices made the difference, so read it as a range of outcomes, not a forecast. Nobody can tell you in advance how long your site will take. What you can do is check whether the mechanics are working, which is a better early indicator than traffic. There is a day by day version of this in what to check in the first month after a migration.

What to watch in Search Console

• Page indexing report: old URLs should move steadily into "Page with redirect", and new URLs should move into indexed. A rise in "Not found (404)", "Soft 404", "Redirect error", "Blocked by robots.txt" or "Excluded by noindex" points at a specific fault.⁵
• Sitemaps report: compare indexed counts for the old URL sitemap and the new one over time.²
• Crawl Stats report: total requests, the response code breakdown and host status. Most responses should be 200 or similar, but during a site move a high share of 301 or 308 responses is expected.²⁴ It is only available for root-level properties.²⁴
• Performance report by page: whether impressions are transferring from old URLs to new ones, template by template against the benchmark.

What to watch in server logs

Logs show which URLs Googlebot requests. In the first weeks you want to see Googlebot fetching old URLs and receiving 301s, then fetching the new URLs and receiving 200s. Watch for 5xx responses in particular. Server errors make Google’s crawlers slow down, and indexed URLs that keep returning errors are eventually dropped.⁸ The migration guide on Bing’s blog recommends checking the logs daily for at least three months after the move starts.³ A server that buckles under the post-launch crawl can do more damage than any mapping mistake.

Rolling back is rarely the right answer, because it forces Google through a second move in the opposite direction and resets the clock. The migration guide on Bing’s blog names attempted roll-backs as one of the most problematic reasons migrations fail.³ Most post-launch problems are fixed faster by correcting the fault on the new site. Plan for it anyway, and keep the old site deployable for at least the first few weeks.

If you do roll back, reverse the redirects so the new URLs point at the old ones, restore the old sitemaps and withdraw any Change of Address request. Then work out what failed before you try again. The second attempt carries more risk than the first, because Google has now seen two moves in a short period.