How Do You Migrate a Website Without Losing Rankings?

You migrate without losing rankings by benchmarking first, mapping every old URL to a new one, redirecting with server-side 301s, keeping those redirects for at least a year and monitoring Search Console closely. Google says some fluctuation is normal, so the realistic goal is a short, shallow dip.

Most migration disasters aren’t Google’s fault. They come from missing redirects, a leftover noindex tag or a team that changed the design, the URLs and the content in one weekend.

This guide follows Google’s own documentation, and flags where its pages disagree. Where a step is our working practice and not Google’s instruction, we say so.

What Counts as a Site Migration, and Which Google Guide Applies?

Google splits migrations in two: moves that change URLs, and moves that only change infrastructure.

The first needs redirects and a URL map. The second needs careful DNS and hosting work.

Type of move	Google guide	Redirects	Change of Address tool
New domain name	Move a site with URL changes	Yes, permanent, URL by URL	Yes, for every verified variant of the old domain
One subdomain to another	Move a site with URL changes	Yes	Yes
HTTP to HTTPS	Move a site with URL changes	Yes	Not needed per the guide; “don’t use” per the tool’s help
www to non-www	Move a site with URL changes	Yes	No: use canonical tags and redirects
New URL paths on the same domain	Move a site with URL changes	Yes	No: add redirects and update sitemaps
Hosting provider or CDN, URLs unchanged	Changing your hosting	No URL redirects; DNS change	No

Moves that change URLs

Google’s examples are changing from HTTP to HTTPS, changing domain name, merging domains or hostnames, and changing URL paths, such as example.com/page.php?id=1 to example.com/widget. Its overview has five steps: review best practice, prepare and test the new site, create a URL mapping, set up redirects and monitor traffic on both sites.

Moves that don’t change URLs

For a hosting or CDN change where the visible URLs stay the same, Google has a separate guide called Changing your hosting. It covers preparing the new infrastructure, switching DNS, monitoring both servers and shutting the old one down once its traffic reaches zero.

What about a redesign or a new CMS?

If the URLs change, you’re in the first group, whatever the reason. If the URLs stay identical, the second guide applies, though a new template can still change what Google sees on each page.

When design and URLs change together, your web design team and your SEO need to agree the URL structure early.

Google says to change only one thing at a time. Its example is to move to a new domain first and change the layout afterwards, not both at once.

Related: What Are Core Web Vitals?

Can Rankings Survive a Migration?

Yes, with a dip. Google says visibility may fluctuate temporarily during a move and rankings settle down over time, and that 301 and other permanent redirects don’t cause a loss in PageRank.

What Google says to expect

Google’s site move guide, last updated on 20 August 2026, says that for medium-sized sites it can take a few weeks or more for the new URLs to gradually replace the old ones in results. Larger sites take longer, and the speed depends on the number of URLs and your server speed.

It also says a move counts as complete only when Googlebot has visited every URL on the old and new site at least once. The move happens on a per-URL basis, and there are no fixed crawl frequencies.

Redirects and link credit

Google’s wording is “Don’t worry about link credit”: permanent redirects don’t cause a loss in PageRank. The risk is in the redirects you forget, break or point at the wrong place, not in the redirect itself.

That matters for the links already pointing at your site. Our guide on whether backlinks are still important explains why preserving them is worth the effort.

Where the real losses come from

Google’s own advice points to a short list: blocks left over from testing, wrong redirect targets, crawl errors, a server that can’t cope with the extra crawling and sitemaps that were never updated. Google’s tool help adds a quieter one: combining a move with a redesign of your content and URL structure will probably cost some traffic, because Google may need to relearn and reassess the individual pages.

What Should You Benchmark Before Migrating?

Record everything you’d want to compare afterwards: rankings, organic traffic, conversions, indexed pages and a full crawl of the live site.

Google’s guidance doesn’t prescribe a benchmark list, so this section is our working practice.

Benchmark	Where it comes from	Why you need it
Queries and pages	Search Console performance data	Shows what to protect
Priority keyword rankings	Your rank tracker	Detects drops before traffic does
Organic sessions and conversions	Analytics	Proves the business impact
Status codes, titles, canonicals, structured data	Full crawl of the live site	The baseline for the new site’s crawl
Linked pages	Search Console links report, backlink tool	Tells you which URLs earn links
Core Web Vitals	Search Console, PageSpeed Insights	Spots speed regressions on the new build

Rankings and traffic

Export Search Console performance data for queries and pages, and save organic sessions and conversions from analytics. Use a date range that covers seasonal swings, so a quiet month isn’t mistaken for a migration problem.

Crawl the live site

A crawl captures every live URL with its status code, title, heading, canonical and internal links. Include structured data in the crawl, because markup is easy to lose in a template rebuild.

Crawl the staging site too and compare the two. Any important page missing from staging is a redirect or content gap waiting to happen.

Prioritise the URLs that matter

Google says to start with your important URLs. Find them in your sitemaps, in server logs or analytics for the pages that get the most traffic, and in the Search Console links feature for pages that have internal and external links.

Those pages get extra testing before and after launch. Losing a spare tag archive is annoyance, while losing the page your best links point to is a real cost.

How Do 301 Redirects and URL Mapping Work?

A redirect map pairs each old URL with its closest new equivalent, and a server-side permanent redirect (301 or 308) tells Google the new URL should be canonical.

Building the map

Google says old URLs can come from your sitemaps, server logs, analytics and the Search Console links report, or from a list your CMS can export. It adds that images, videos, JavaScript and CSS files need moving in the same way as other content.

In a simple domain move you may not need a list at all, because a wildcard server-side redirect can cover it. For anything more complex, store the mapping in a spreadsheet, database or set of rewrite rules.

Redirect types and what Google does with them

According to Google’s redirects documentation, permanent redirects show the new target in results, while temporary ones show the source page. The table is ordered by how likely Google is to interpret each method correctly.

Redirect type	How Google treats it	When to use it
301 or 308, server-side	Permanent: a signal that the target should be canonical	Default for any permanent move
Instant meta refresh or HTTP refresh (0 seconds)	Read as permanent	If server-side isn’t possible
JavaScript location	Permanent, but Google might never see it if rendering fails	Last resort
302, 303, 307	Temporary: the source page stays in results	Short-term changes only
Delayed meta refresh (more than 0 seconds)	Read as temporary	Not for a migration

Redirect rules that matter

Redirect directly to the final destination. Googlebot can follow up to 10 hops, but the site move guide advises against chains, and says that if you can’t avoid them, to keep them to no more than 3 and fewer than 5.

Check your redirects before launch with command line tools or scripts for volume, and the URL Inspection tool for individual URLs.

Pages that don’t carry over

Don’t send hundreds of old URLs to the homepage or one irrelevant page. Google says this can confuse users and might be treated as a soft 404.

If you’ve consolidated several pages into one, redirecting the old URLs to the consolidated page is fine. If content has been deleted and has no equivalent, those URLs should return a 404 or 410 on the new site.

Planning a rebuild or domain change? Talk to us about web design before the new URLs are decided.

How Do You Prepare the New Site Before Launch?

Get the new site ready for traffic before you flip anything: correct canonicals, updated internal links, a robots plan, verified Search Console properties and enough server capacity.

Google lists each of these in its preparation steps.

Update the pages themselves

Each new URL should have a self-referencing rel=“canonical” tag. If you use hreflang annotations for multilingual or multinational pages, update them to the new URLs too.

Change internal links on the new site from old URLs to new ones, using the mapping to find them. Save a sitemap of the new URLs and a list of the sites that link to your old URLs for the final move.

Staging, robots.txt and noindex

Many teams block crawling or add noindex rules while a site is in development. Google says to prepare what the robots.txt file should look like once the move starts, and a list of URLs from which to remove noindex rules.

Those robots rules are also the place where you decide what AI crawlers can reach, which we cover in our guide on whether to block AI crawlers. Treat that as a decision to make on purpose, not a default carried over from staging.

Search Console, analytics and servers

Verify both the old and new sites in Search Console, including every variant such as www and non-www, and HTTP and HTTPS. Use web analytics to compare traffic on both sites, and consider a new profile if you want clean separation in your reports.

After a migration Google temporarily crawls the new site more heavily than usual, because crawls of the old URLs get redirected to the new ones as well. If your site is particularly large, Google suggests telling your hosting provider in advance.

When Should You Use the Change of Address Tool?

Use it only when you move from one domain or subdomain to another, and only after the move and redirects are in place.

For HTTP to HTTPS, Google’s two pages word it slightly differently, and the difference is worth knowing.

When it applies

Google’s Change of Address tool help says to use the tool when you move from one domain or subdomain to another, such as example.com to example.org. It says to use it after you’ve moved and redirected your site.

If you’re moving to a new domain, submit a request for every verified variant of the old domain, including subdomains and www or non-www versions, even if you’re not actively using them.

What Google’s two pages say about HTTP to HTTPS

The site move guide says you only need the tool when moving between domains or subdomains, and that you don’t need it for HTTP to HTTPS moves, switching between www and non-www, or moving paths within the same domain. The tool’s help is firmer: it says not to use the tool for an HTTP to HTTPS move, and that Google will figure out your changes for you.

Topic	Site move guide (updated 20 August 2026)	Change of Address tool help
HTTP to HTTPS	Tool not needed	Don’t use the tool; follow the site move guide
www to non-www	Tool not needed	Don’t use the tool; use canonical tags and redirects
Paths within a domain	Tool not needed	Don’t use the tool; add redirects and update sitemaps
How long to keep redirects	As long as possible, generally at least 1 year	At least 180 days, longer if traffic still arrives

The practical reading is the same either way: for HTTP to HTTPS, use redirects and the normal site move steps, and leave the tool alone.

Requirements and what the tool does

You must own both properties in Search Console and use the same Google account. The tool works at the domain level and doesn’t move subdomains below the domain you specify, including www.

When you file a request, it tells Google to emphasise crawling and indexing the new site, forwards signals from the old site and prefers the new site when choosing canonical pages. These actions continue for 180 days.

Cancelling a request

You can cancel for 180 days after you make it. Remove the 301 redirects on the old site, add redirects from the new site back to the old one, then choose Cancel Move in the tool on the old site.

After 180 days Google doesn’t recognise any relationship between the old and new sites. The tool’s help also says not to chain site moves, so you can’t immediately submit a second move from B to C.

How Long Should You Keep Redirects?

Google’s site move guide says to keep redirects for as long as possible, generally at least one year.

The Change of Address tool’s help gives a shorter figure of 180 days, so follow the longer one.

Why a year

The guide says the timeframe lets Google transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs. From a user’s perspective it suggests considering redirects indefinitely.

The 180 days in the tool’s help appears to relate to the tool’s own window, and it adds “longer if you still see any traffic to them from Google Search”. Keeping the redirects for a year covers both.

Keep the old domain too

For a domain move, the tool’s help recommends continuing to pay for the old domain for at least a year. That prevents someone else buying and using your abandoned domain for malicious purposes.

Update links so fewer people hit redirects

Redirects are slow for users, so Google says to update links as soon as the move starts. That covers your internal links, links from other sites, profile links on social networks and ad campaigns.

Work through the saved list of linking sites and prioritise by inbound visits. Outreach like this is a form of link building.

What Should You Check on Launch Day?

Check redirects, canonical tags, robots rules and sitemaps in that order, because those four cause most of the avoidable losses.

Google’s “Start the site move” section lists the core steps.

Check	What to look for	Pass condition
Redirects on	Old URLs return 301 or 308 to the right new URL	Every mapped URL lands on its equivalent
Redirect testing	No chains, loops or redirects to irrelevant pages	One hop, correct target
Canonicals	Each new URL has a self-referencing canonical	No canonical pointing at the old site
Robots and noindex	Remove any migration-only blocks	URL Inspection shows pages are not blocked
Internal links	Point at new URLs, not old ones	No internal link triggers a redirect
Sitemaps	Submit the new sitemap	New sitemap accepted in Search Console
Change of Address	Submit for domain or subdomain changes only	Request accepted for each verified variant
Server capacity	Handle the heavier crawl after launch	No server errors as Googlebot crawls

Order of checks

Switch on the redirects, then check the canonicals and robots rules, because Google says to update any noindex rules added to the new site to avoid premature indexing. Then test the redirects, and file the Change of Address request if it applies.

Also check that your Search Console verification file or tag made it onto the new site. Google reminds you not to leave the current verification file out of the new copy.

Sitemaps: one point where Google’s guide pulls two ways

The launch section says to submit the new sitemap and that you can then remove the old one. The monitoring section says to submit both saved sitemaps, so you can watch indexing of the old URLs fall to zero as the new ones rise.

Keeping both for the monitoring period is harmless, and it gives you a chart that shows the move working.

What Should You Monitor Afterwards?

Watch the Sitemaps report, indexing reports and Search Console queries on both sites. Google says ideally traffic on the old site goes down while traffic on the new site goes up.

What a healthy first few weeks look like

Over time the number of pages indexed from the old sitemap should drop to zero, with a matching rise for the new URLs. Search Console may warn that URLs in the old sitemap are redirecting, which Google says is normal and can be ignored.

As new pages are indexed and start to rank, the queries report should show the new site gaining impressions and clicks. Keep an eye on server access and error logs for Googlebot crawling and unexpected error codes.

A working timeline

Google gives no schedule, so the table below is our own working view of a typical project. Adjust it for the size of your site.

When	What happens
4 to 8 weeks before	Benchmark, crawl the live site, start the URL map, agree who signs off
2 to 4 weeks before	Build on staging, test redirects there, plan the robots and noindex changes, verify Search Console variants
Launch day	Redirects on, blocks removed, canonicals and sitemaps checked, Change of Address filed if needed
Days 1 to 7	Daily checks of coverage, 404s, logs and key page indexing
Weeks 2 to 6	Weekly comparison against the benchmark, fixes for gaps
Months 2 to 12	Redirects stay on, external links get updated, quarterly review

When to worry

If key pages aren’t being indexed after a couple of weeks, test them with the URL Inspection tool before blaming Google. Look for stray noindex tags, robots blocks and redirects to the wrong place.

A spike in “Not found” errors can mean redirects point to URLs that don’t exist on the new site. Google says it frequently sees people redirect to the wrong, non-existent URLs.

Related: How Long Does SEO Take to Work?

What Changes if You Only Move Hosting or a CDN?

If the visible URLs stay the same, you need no redirects, but you do need careful DNS work.

Google’s Changing your hosting guide treats moving to a CDN as the same kind of change.

Prepare and test

Upload a copy of your site to the new infrastructure and test every part of it, including pages, images, forms and downloads. A temporary hostname such as beta.example.com lets you test whether Googlebot can reach the site, and a noindex rule stops the test copy being indexed.

Check that your firewall or denial-of-service protection doesn’t block Googlebot. Google also suggests lowering your DNS TTL to a few hours at least a week before the move, so the new settings spread faster.

Switch and monitor

Remove any temporary crawl or indexing blocks, then update the DNS records to point at the new provider. Watch the server logs on both servers, and expect traffic on the old one to fall while the new one rises.

Shut the old infrastructure down only when its traffic reaches zero and you’re confident everyone, including Googlebot, gets correct content from the new one.

Moving platform or host as part of a rebuild? Speak to our web design team early.

What Commonly Goes Wrong in a Migration?

Most losses trace back to a short list of avoidable mistakes, and Google’s troubleshooting section names nearly all of them.

Google’s list of common mistakes

• Leaving a noindex tag or robots.txt block from the test site in place.
• Redirecting to wrong, non-existent URLs on the new site.
• A spike in other crawl errors on the new site during the move.
• A server that can’t cope with the extra crawling after launch.
• Not updating the sitemaps with the new URLs.

Google adds that your robots.txt file can be absent, but if so it must return a proper 404 status.

Mistakes we’d add

These come from our working practice and aren’t in Google’s list. Metadata, structured data and internal links often get dropped in template rebuilds.

Redirect chains, 302 redirects used for permanent moves and a redesign shipped on the same day as a domain change are common too. A pre-launch SEO audit is the natural place to catch them, and ongoing SEO covers the monitoring afterwards.

Timing and expectations

If your traffic is seasonal or dips on certain weekdays, Google says it makes sense to move during the recurring dips. Fewer people are affected by problems, and more of your server can go to Googlebot.

Tell stakeholders in advance that a short wobble is normal, and agree what size of drop would trigger action.