How to Move a Website to a New Domain Without Losing Traffic

The move in four phases

Google's guide to site moves with URL changes covers any move where page addresses change: a new domain, a switch to https, or new paths on the same site. This guide is about the biggest of these, a new domain. The work falls into four phases:

Before the move: list every old URL, decide where each one goes, and set up the new domain so it is ready to be crawled.
Move day: turn on the redirects, update everything on the new site that still names old URLs, and tell Google and Bing.
The following weeks: watch crawling, indexing and traffic, and fix what the reports show.
The following year: keep the redirects and the old domain, and update the links you can reach.

Google's general advice for any move applies here too: split a large move into smaller steps if that makes sense for your site, and plan your changes "one after the other, not everything at the same time." If you also want a redesign, a new CMS or new URL paths, a domain change on its own is easier to debug than all of them on one day. The guide adds that you should time the move for a period of lower traffic if you can.

Before the move: map every old URL

The redirect list is the heart of the move, and it is only as good as the list of old URLs behind it. Google suggests collecting them from several places, because none is complete on its own:

your current sitemaps,
the URLs with the most traffic, from your server logs or analytics,
the pages other sites link to, from the Links report in Search Console,
your content management system, which can usually export every page,
recent server logs, for URLs that none of the above show.

Google's list also names images, videos, JavaScript and CSS files. A PDF that ranks or an image other sites embed is a URL like any other.

Then give every old URL a target. Google says to store the mapping in a database or as rewrite rules on the server. A spreadsheet with two columns works for small sites. Here is what a mapping looks like; the domains and paths are example values, not a real site:

Old URL on old-shop.example	New URL on new-shop.example	Why
/	/	Home page to home page
/about-us.html	/about/	Same page, new path
/blog/2024/winter-tips	/blog/winter-tips/	Same post, shorter path
/products?id=17	/products/garden-hose/	Parameter URL to a clean URL
/spring-sale	/sale/	Two old pages merged into one
/summer-sale	/sale/	Two old pages merged into one
/old-catalog.pdf	/catalog.pdf	Files count too
/discontinued-item	(404 or 410)	No replacement, so no redirect

Three rules from Google decide the right column. Each old page goes to its matching new page. Several old pages that were merged into one may all point at that one page. And an old page with no replacement should not be redirected at all: Google says such URLs should "correctly return an HTTP 404 or 410 error response code on the new site." What Google warns against is the shortcut: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site."

Once the list is done, paste the two columns into the redirect generator. It turns them into rules for the common servers and hosts and explains the status codes and how to avoid chains and loops, so this guide does not repeat that.

Before the move: get the new domain ready

Verify both domains in Search Console

Google's move guide asks you to verify the old and the new site in Search Console, and to "verify all variants of both the old and new sites": www and non-www, and http and https. Google also asks you to keep the Search Console verification files and meta tags in place when you copy the site over, so no property loses its verification during the move. If you upload a disavow file for the old site, Google recommends uploading it again in the new site's Search Console account.

If the new domain had an earlier owner, check its Search Console property before you move anything onto it. Google says to address any manual actions listed there, and to make sure no URL removals are left over from the previous owner, "especially a site-wide URL removal." The WHOIS lookup shows when a domain was first registered, which tells you whether it has a history worth checking.

Prepare robots.txt and the sitemap

Many sites are built behind a crawl block. Google notes that "some site owners block all crawling while in development," and asks you to prepare what the new site's robots.txt should look like once the move starts. Write that file ahead of time with the robots.txt generator, and write down which pages carry a noindex that has to come off on move day. The guide robots.txt vs noindex vs canonical explains why those two are not the same switch.

Build the sitemap of new URLs now as well, from the right column of your mapping, with the XML sitemap generator. Google's list for this phase also includes setting up the CMS, moving images and downloads, and setting up the TLS certificate for https on the new domain.

Update the new site before it goes live

Everything on the new site that still names an old URL is a signal pointing the wrong way. Google lists three things to change:

Canonicals. Each new page gets a rel="canonical" link to its own new URL.
Hreflang. If you have language or country versions, update the annotations to the new URLs. The hreflang tag generator writes the full set.
Internal links. Change links between your own pages from the old URLs to the new ones, so visitors and crawlers do not pass through a redirect on every click.

Save one more list: the sites that link to your old URLs. You will need it after the move. Google also points out that Googlebot crawls a new site more heavily than usual after a migration, so make sure the new server can handle the extra load.

Keep the old domain

The old domain is not finished on move day; it is where every redirect lives. Check its expiry date with the WHOIS lookup and renew it well past the move. Google's Change of Address page recommends "continuing to pay for the old domain for at least a year." If the old site is served over https, keep a valid certificate on it too: under the HTTP standard, RFC 9110, a client checks the certificate for the host it asked for before it accepts any response, so a browser shows a security warning instead of following the redirect.

Move day

Turn on the redirects. Server-side permanent redirects, page to page, from every old URL in your mapping. Google recommends server-side permanent redirects such as 301 or 308 and calls client-side redirects a fallback for when no server-side setup is possible. For a domain move, 301 is the safe choice, because the Change of Address tool asks for 301 redirects.
Open the new site to crawlers. Put the prepared robots.txt live and remove the noindex rules that were only there for the migration. Google lists leftover noindex and robots.txt blocks first among the problems to check.
Do not block the old domain. A robots.txt file tells crawlers which URLs they may access. Google says that to consider a move complete, "Googlebot will have to visit every URL on your old and new site at least once." A Disallow rule on the old domain stops Googlebot from fetching the old URLs, so it never sees the redirects. Leave the old domain crawlable; it only needs to answer with redirects.
Check canonicals once more. On the live site, the canonical links must point at the new URLs, not at the old domain or at the staging host.
Test the redirects. Open a sample of old URLs, including deep pages and files, and check that each lands on its own new page in one step. The HTTP header checker shows every hop and its status code; Google suggests the URL Inspection tool in Search Console as well.
Submit the new sitemap in the new Search Console property.
Tell Google and Bing with their move tools, described next.

Google's guide says small and medium sites can move all at once. Large sites can move section by section, starting with a part of the site that changes less often.

The Change of Address tool

Redirects alone do the job eventually. The Change of Address tool in Search Console tells Google about the move directly; according to the help page, it tells Google "to emphasize crawling and indexing your new site over crawling your old site."

Requirements

Ownership. You must be an owner of both the old and the new property in Search Console.
Redirects first. The old home page has to redirect to the new one with a 301, and ideally the canonical pages too. The tool runs a few checks before it sends the request: it confirms you own both sites and checks for 301 redirects on a few pages. A failed critical check blocks the request; a failed non-critical check gives a warning you can proceed past.
Domain level. The tool works on a whole domain, not on single paths. It does not move subdomains below the domain you name, and that includes www. That is why Google's move guide says to submit a Change of Address for all verified variants of the old domain, even ones you do not use.
One move at a time. The help page asks you not to chain moves, such as A to B and then B to C, and to avoid moving several sites into one at once.

What it is not for

The help page lists the cases the tool does not handle: switching from http to https, moving between www and non-www in the same domain, moving pages within your site, and moves without user-visible URL changes, such as a new host or CDN. For those, the redirects and updated signals are enough.

The 180 days

Once you submit, the move takes effect for 180 days. During that time all the sites involved show a notification in Search Console that a move is in progress, and you can cancel within the same window. To cancel, you remove the redirects, redirect the new site back to the old one and click Cancel Move in the old property. After the 180 days, Google "does not recognize any relationship between the old and new sites," and treats the old site, if still present and crawlable, as unrelated.

Bing

Bing has its own Site Move tool in Bing Webmaster Tools. A migration post on the official Bing Webmaster blog says the move should be reported there once the redirects are live, and that this step requires verified ownership of the site in Bing Webmaster Tools. Add and verify the new domain there as well.

After the move: what to watch

Google is clear about what to expect: "Expect temporary fluctuation in site ranking during the move." For a medium-sized site, it can take "a few weeks or more" for Google to show the new URLs instead of the old ones, and larger sites take longer. Google also says that 301 and other permanent redirects don't cause a loss in PageRank. So a dip in the first weeks is normal; a dip that does not recover points to a problem you can find.

In Search Console

Sitemaps. Watch how many URLs from the new sitemap get indexed. If you keep the old sitemap for a while, Search Console may warn that its URLs redirect. Google calls this normal: "you are, in fact, moving to new URLs after all." Once the new sitemap is in, you can remove the old one.
Page indexing. In the old property, old URLs should move into the status "Page with redirect," which the help page defines as a non-canonical URL that redirects to another page. In the new property, the indexed count should rise.
Search queries. Google's move guide suggests watching the queries in the new property for search traffic shifting over.

On the server and in analytics

Check the server logs on both domains for Googlebot visits and for unexpected error codes, especially a spike in 404s on the new domain or redirects that lead to pages that do not exist. In your analytics, traffic to the old domain should fall while traffic to the new one rises. If a group of old pages keeps its traffic, their redirects are missing or broken.

Links you can still change

Now use the list of linking sites you saved. Google suggests contacting those sites, starting with the links that send the most visits, and updating the links you control yourself: your social media profiles and your ad campaigns, which should point straight to the new landing pages. Each updated link is one less visitor who has to go through a redirect.

For the general launch checks that apply to any new domain, such as indexing, titles, structured data and mobile, work through the technical SEO checklist on the new site.

How long to keep the redirects and the old domain

Google gives two numbers in two places. The site move guide: "Keep the redirects for as long as possible, generally at least 1 year." It explains that this allows Google to transfer all signals to the new URLs, including recrawling and reassigning the links on other sites that point to the old ones. The Change of Address page sets a lower floor: "Maintain the redirects for at least 180 days," longer if you still see traffic to them from Google Search. A guest post on the Bing Webmaster blog goes further, with at least 1 to 2 years.

Here is what that means for a move on an example date:

Date	Days after	What happens
March 1, 2027	0	Redirects go live, Change of Address submitted, new sitemap submitted
August 28, 2027	180	Change of Address period ends; Google's minimum for keeping the redirects
March 1, 2028	366	Google's general minimum for redirects and for paying for the old domain

In practice, the cheapest choice is to never turn the redirects off. They cost almost nothing to keep, and old links on other sites, in emails and in bookmarks do not expire after a year. Before you remove them, check the old domain's logs: if people or crawlers still arrive there, the redirects still have work to do.

The parts that are not about search

A domain carries more than the website, and these break quietly on move day. Check each one with the DNS lookup on both domains:

Email. If mail runs on the old domain, its MX records must stay in place for as long as anyone still writes to those addresses. If mail moves to the new domain, it needs its own MX records.
Sender checks. A new sending domain needs its own SPF, DKIM and DMARC records; the old records only cover the old domain. The guide SPF vs DKIM vs DMARC explains what each one checks and sets them up in order.
Other records. Subdomains for a shop, a help desk or a mail service, and verification records for third-party services, have to be recreated on the new domain if you want them there.
Everything with the address printed on it. Email signatures, invoices, business cards, app store listings and business profiles.

The move on one page

List every old URL, including files, and map each one to its new page; 404 or 410 for pages with no replacement.
Verify all variants of both domains in Search Console, and the new one in Bing Webmaster Tools.
Prepare the new robots.txt, the new sitemap, self-referencing canonicals, hreflang and internal links.
Renew the old domain for at least a year, and keep its certificate valid.
On move day, switch on 301 redirects page to page, open the new site to crawlers, leave the old one crawlable, and test.
Submit the new sitemap and a Change of Address for every verified variant of the old domain, and use Bing's Site Move tool.
Watch sitemaps, page indexing, logs and traffic for the following weeks; update the links you can reach.
Keep the redirects for at least a year, and better for good.

Frequently asked questions

Will I lose rankings when I move to a new domain?

Expect a dip, not a loss. Google's site move guide says to expect temporary fluctuation in site ranking during the move, and that for medium-sized sites it can take a few weeks or more for Google to start showing the new URLs instead of the old ones, longer for larger sites. It also says that 301 and other permanent redirects don't cause a loss in PageRank. Lasting losses usually come from missing or wrong redirects, not from the move itself.

Can I redirect every old page to the new home page?

No. Google's site move guide says not to redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. Redirect each old page to its matching new page. Where several old pages were merged into one, redirecting them all to that one page is fine. Old pages with no replacement should return 404 or 410.

How long should I keep the redirects after a domain change?

Google says to keep them for as long as possible, generally at least 1 year, so it can transfer all signals to the new URLs. The Change of Address help page gives a lower floor of 180 days, longer if the old URLs still get traffic from Google Search. Plan for at least a year, and keep paying for the old domain for at least as long; Google recommends that too.

Do I need the Change of Address tool to switch from http to https?

No. The Search Console help page lists changing from http to https, moving between www and non-www in the same domain, moving pages within one site and moves without user-visible URL changes as cases the tool does not handle. For those, redirects and updated canonicals, links and sitemaps are enough. The tool is for moving a domain or subdomain to a new one.

Can I let the old domain expire after the move?

Not soon. Google recommends continuing to pay for the old domain for at least a year, and the redirects only work while you control it. Every old link, bookmark and printed address keeps pointing at it. If someone else registers it later, they get that traffic. The WHOIS lookup shows the expiry date so you can renew in time.

Sources

Written by Tobias. Updated October 22, 2026.