Changing your domain name: step by step without losing SEO.

To keep search visibility when changing a domain name, every address on the old domain is redirected one by one with a 301 to its counterpart on the new domain, both domains are verified in Search Console, and the move is reported with Google’s Change of Address tool. The old domain and its redirects are kept running for at least one year.

A domain change comes up for several reasons: the company’s name or brand changes, a business switches from .com to .com.tr or the other way round, two companies merge, a new domain is bought for a foreign market. Whatever the reason, from Google’s point of view the same thing happens: every address it knows is moving somewhere else. This is the most extensive form of a site redesign, because not a single page stays at its old address. Within the scope of website redesign and migration, a domain change stands as a separate work item.

What happens in Google when the domain changes?

To Google, the new domain is at first a new site with no history. The signals the old domain has accumulated — links from other sites, knowledge of which page answers which question — do not move on their own. What carries them is the redirect: when the old address permanently points to the new address, Google eventually accepts the new address as the primary one. Google’s site move documentation states that on a medium-sized site this process can take a few weeks or longer, and that rankings may fluctuate in the meantime.

How do you change a domain name step by step?

• Compile a list of all addresses on the old domain: sitemap, Search Console and a crawl of the site itself. If the list is incomplete, your map will be incomplete too (URL inventory).
• Write down the counterpart of every old address on the new domain. If the paths stay the same, a single rule is enough; if the path structure also changes, you need a line-by-line map.
• Prepare and test the site on the new domain: every page should declare its own new address as canonical, and on a multilingual site hreflang links should point to the new domain.
• Add and verify the new domain in Search Console. The old domain’s property must also stay open and verified.
• Activate the redirects. Every old address should go to its counterpart on the new domain with a 301 redirect and in a single step; not a mass redirect to the homepage.
• Run the Change of Address tool from the old property’s settings in Search Console.
• Submit the new domain’s sitemap.
• Update internal links, social media profiles, email signatures, ad accounts and the address on printed material; even though these pass through the redirect, a direct link is shorter.
• Monitor both properties in Search Console for weeks: indexed pages should rise in the new property, impressions should fall in the old one.

If the paths are preserved exactly on the new domain, a single server rule is enough for the whole site: every request to the old domain is sent to the new domain with its path and query unchanged. The lines below are the Nginx version of this; the domains are examples, and the old domain’s HTTPS certificate must also remain valid, otherwise a visitor arriving via https sees a security warning before ever reaching the redirect.

1. server {
2. listen 80;
3. listen 443 ssl;
4. server_name example.net www.example.net;
5. return 301 https://www.example.com$request_uri;
6. }

What does Google’s Change of Address tool do?

The Change of Address tool in Search Console tells Google directly that the site has moved to another domain. According to the Search Console help page, the tool makes Google prioritize indexing the new site and transfer the signals from the old site to the new one; its effect lasts 180 days, and during this time a notice that the move is in progress appears in both properties.

The tool’s requirements are strict. You must own both properties and manage both with the same Google account. It works only on domain-level properties; it cannot be used for a subpath property such as example.com/magaza/. Before running the tool, a 301 must already be in place from the old homepage to the new homepage. The tool does not replace redirects; it only speeds up what they say.

When is the Change of Address tool not used?

The help page explicitly excludes three cases. Moving from http to https is not a domain change; the tool is not used. Neither is moving from the www address to the non-www address or vice versa; a redirect and the canonical address are enough. Moving pages within the same domain does not require the tool either; redirects and an up-to-date sitemap are sufficient. The first two are explained in the HTTPS and www redirect guide.

How long should you keep the old domain?

The redirects run on the old domain; if the domain registration lapses, the redirects lapse with it. The Search Console help page says redirects should be kept for at least 180 days, and longer if traffic still arrives from Google Search; Google’s site move documentation generally recommends at least one year. In practice, go by the longer one: the old domain should stay registered and redirecting for at least one year, and much longer for a site with external links. Letting the old domain go means someone else can buy it and pull your links to their own site.

What are the most common mistakes when changing a domain name?

• Sending all old addresses to the new homepage. Google does not see this as an equivalent page; it may treat these addresses like error pages (soft 404).
• Deleting the old Search Console property. The progress of the move and errors on old addresses show up there.
• Changing the domain, the address structure and the content all on the same day. If possible, first the domain, then the structure; when a problem arises, it is easier to isolate the cause.
• Doing the redirect on the old domain with JavaScript or a delayed page refresh. Use a server-side 301.
• Not putting the old domain’s renewal date in the calendar.

What did we see on this site?

This site’s domain did not change, so we are not describing a domain move case here. But we have experienced the two halves of a domain change separately. The first was two forms of the same domain: on 21 August 2026 the non-www address returned 200 instead of 301, meaning the same content was served from two separate addresses and looked like two separate sites to Google. A 301 was written on the server that sends every non-www request to the www address with its path unchanged. This is the small-scale counterpart of a domain change: the same page, two addresses, one decision.

The second is what the side taking over a domain sees. Another site was previously live on this domain. In September 2026, 70 addresses appeared as 404 in Search Console’s list of non-indexed pages, and every sample we tested on the live site was left over from that previous site: addresses beginning with /yazi/, posts under /en/writing/, the /ru/ and /fr/ language roots. Seven of them were also among the addresses receiving impressions in the performance report for the last 28 days. In other words, Google remembers the addresses of a site that has gone offline, recrawls them and keeps trying to show them in search results. This is the most concrete reason why the side changing its domain should not remove the redirects early.

Google does not forget a moved address; you only need to tell it where to go.

Which report to read how often in the weeks after the move is covered in the post-migration monitoring guide. A domain change is never made with a guarantee that rankings will be preserved exactly; a properly built move eliminates the losses that are in your hands and leaves the rest to Google’s recrawling.

If you don’t want to lose traffic while relaunching your site, website redesign and migration inventories the old addresses, builds a chain-free 301 map and monitors the site for 90 days after the move.