How Do You Tell Google You Have Moved to a New Domain?

You have moved to a new domain. What do you actually tell Google?

You tell it twice. Once through server-side permanent redirects from every old URL to its new equivalent, and once through the Change of Address tool in Search Console. The redirects do the real work, and the tool is how you declare the relationship between the two properties so Google can migrate your results.

Most of the damage I see from domain moves comes from doing only one of those, or from doing them in the wrong order. A change of address with no redirects is a claim with no evidence, and redirects with no declaration leave Google to work it out slowly on its own.

Here is the sequence, using only Search Console and your own hosting, with the rules Google publishes for each step.

When do you actually need the Change of Address tool?

Only when the domain or subdomain itself changes. Google says to use the tool when you move your website from one domain or subdomain to another, and that it helps migrate your Google Search results from your old site to your new site. If the hostname is staying the same, this tool is not your step.

Google is specific about the cases it does not cover. Do not use it for changing address from http to https, for moving some pages from one location to another within your site, for moving between www and non-www on the same domain, or for moving a site without any user-visible URL changes.

That last exclusion catches people out. If you are re-platforming but keeping every URL identical, there is nothing to declare and nothing to redirect, and the correct action is to change nothing in Search Console and watch your logs instead.

What do you need in place before you use it?

Verified ownership of both properties and the right property type. Google states that you must be an owner of both the old and new properties in Search Console, and that the tool works only on properties at the domain level, not at the path level such as a subfolder on an existing domain.

Get the verification done early, because it is the step most likely to stall you. Verifying a domain property usually means a DNS record, which means whoever controls your DNS needs to be available on the day, and that person is rarely the person planning the migration.

One more detail worth knowing before you start. Google says the tool moves all protocols of your source property. You are declaring the move for the whole property rather than for a particular version of it, which is convenient and also means you should be certain before you submit.

How do you set up the redirects Google expects?

Server-side permanent redirects from the old URLs to the new URLs, pointing straight at the final destination. Google's site move guidance is explicit that you should redirect to the final destination directly rather than through intermediate hops, and that guidance is the difference between a clean move and a slow one.

Chains are the common failure. Google says Googlebot can follow up to 10 hops in a redirect chain, and in the same breath advises keeping chains to no more than three and fewer than five. Read the second part as the instruction and the first as the tolerance. Just because something is survivable does not make it a plan.

Chains usually appear by accident rather than by design, when an old redirect rule from a previous change is still live and your new rule lands on top of it. Test a sample of real old URLs and follow them all the way through before you declare anything, which is exactly why you want the redirect map built before you migrate rather than after.

How long do you keep the old redirects live?

At least a year. Google says to keep redirects active for at least one year so that it can transfer all signals to the new URLs. That is a longer commitment than most migration plans budget for, and it has a real consequence, because it means you cannot let the old domain lapse.

I would treat the domain renewal as part of the migration checklist rather than as a separate administrative task. A domain that expires eight months after a move takes every redirect with it, and the signals that were still in transit stop arriving with no notification anywhere.

In practice I keep them longer than a year when the cost is only a domain renewal. There is no benefit to switching them off on the anniversary, and there is a real cost if anything was still pointing at an old URL, including links in other people's published articles that nobody will ever update.

What do you do with your sitemaps?

Submit the new sitemap in Search Console once your redirects are active. Google describes the expected pattern afterwards, where the new sitemap initially shows zero indexed pages while the old one shows many, and over time the number of pages indexed from the old URLs sitemap drops to zero.

That description is genuinely useful because it tells you what a healthy migration looks like while it is happening. The two curves crossing is the signal you are watching for. If the old count stays flat and the new count stays at zero, something is wrong with your redirects rather than with Google.

Keeping the old sitemap submitted during the transition is what makes this observable. It gives Google a list of the old URLs to recheck, and it gives you a counter that tells you how far through the move you are, which is otherwise very hard to see. It is also the cleanest cross-check you will get on whether your sitemap and your index coverage agree.

How long does the migration actually take?

Longer than a week and it depends on size. Google's estimate is that a small to medium-sized website can take a few weeks for most pages to move, and that larger sites take longer. That is deliberately unspecific, and it is still more useful than the reassurance you will get anywhere else.

Plan your reporting around that window rather than fighting it. Expect a dip, expect it to be uneven across page types, and do not make any other significant change during the move, because you will lose the ability to attribute anything that happens to any particular cause.

How fast your pages get revisited also depends on how much Google crawls your site in the first place, which is a separate mechanism worth understanding before you panic about week two. I have written about how Google decides how often to recrawl your pages, and a large archive on a modest server will simply take a while.

What happens after 180 days?

The declared relationship expires. Google says it recognises the relationship between the two properties for 180 days after you start migration in Search Console, and that after this period it does not recognise any relationship between the old and new sites.

This is the single most important number in the whole process and almost nobody knows it. It does not mean your redirects stop working, and it does not mean your rankings reset. It means the explicit declaration has done its job and expired, while the redirects continue doing theirs for the full year and beyond.

The practical takeaway is that the 180 day window is your period of active supervision. Check progress inside it, fix problems inside it, and do not assume you can revisit the declaration later, because the tool will no longer be holding the two properties together.

How do you cancel a move that went wrong?

You can, within the same window. Google says you can cancel a change of address request for 180 days after it was made, by removing the redirects, adding reverse redirects, and clicking Cancel Move in the tool. Note the order, because the redirect work comes first.

Cancelling is genuinely rare and it is good to know it exists, particularly if you are the person who has to sign off on the migration. A reversible decision is much easier to make than an irreversible one, and this one is reversible for six months.

That said, reversing a move is not free. You will have spent the intervening period training Google on the new URLs, and you are now asking it to unlearn that. Treat cancellation as a genuine emergency measure rather than as a reason to be casual about the original decision.

What should you do next?

Before anything else, verify both properties in Search Console at the domain level and confirm you are an owner of each. That single prerequisite blocks the whole process, and discovering it on migration day is the most common way these projects slip a week.

Then test twenty real old URLs, chosen from your highest traffic pages rather than at random, and follow each redirect to its final destination counting the hops. If any of them chain, fix that before you submit anything. Setting up Search Console properly on the new site is worth doing at the same time rather than afterwards.

Finally, put two dates in your calendar. One at 180 days, when the declared relationship expires, and one at a year, when your redirects have served their stated minimum and you can decide whether to keep them anyway. If you are planning a domain move and want someone to check the redirect map before you pull the trigger, reach out.