How to Use the Search Console Change of Address Tool: Step by Step

The change of address tool is the Search Console feature you use to tell Google that your site has moved from one domain to another. In this guide, we at Talha Aslan and team walk through its requirements, the exact steps, common mistakes, and how to monitor the move afterward. We cover full migration planning in a separate article; here we focus on the tool itself.

Google's official Change of Address tool help page sums it up in one line: use the tool after you've moved and redirected your site. In other words, the tool does not move anything for you. Redirects, the new server, the new sitemap, and internal links remain your job. The tool only tells Google that the move is deliberate and permanent.

The effect also has a time limit, so plan for it. According to Google, the effects of a request last 180 days from the start of the migration. During that window, Google prioritizes crawling and indexing the new site. However, Google does not remove the old site from its index. Old URLs can still appear in results if they are reachable and have no equivalent page on the new site.

If you are new to Search Console, our Google Search Console guide explains the basics. For example, terms like property, verification, and owner come up often in this article.

When should you use the change of address tool?

In short, there is one scenario. Specifically, you use the tool when you move from one domain or subdomain to another. Google's guide to site moves with URL changes states this clearly. You only need the tool for a domain or subdomain change.

For example, these situations qualify:

• Moving from example.com to example.net after a rebrand.
• Switching from a country-code domain to a generic one.
• Moving a blog subdomain, such as blog.example.com, to its own domain.
• Moving a domain into a folder on another domain, which Google supports.

The last point surprises many site owners. In fact, the help page confirms that you can move a domain to a path within another domain. The reverse does not work, though. You cannot move a single folder with the tool, because it does not run on path-level properties.

Therefore, before you open the tool, confirm that your move really is a domain change. If the answer is no, the right method is probably redirects plus a sitemap update. As a result, you save a pointless request and keeps your team's expectations realistic.

Which moves do not need the tool?

Google detects some moves on its own and asks you not to use the tool for them. Knowing this split therefore saves time. According to the official help page, these cases fall outside the tool's scope:

• HTTP to HTTPS: Google detects this change automatically. Follow the site move guidelines, but skip the tool.
• Path changes on the same site: For instance, renaming /products/ to /shop/. Add redirects and update your sitemaps instead.
• www to non-www on the same domain: Google recommends canonical tags or redirects for this.
• Moves with no visible URL change: Switching hosting providers or CDNs falls into this group.

An HTTPS switch comes with its own issues, such as certificates and mixed content. We cover those in our SSL certificate guide. For a hosting switch with the same URLs, Google has a separate guide for moves without URL changes.

So what happens if you open the tool in one of these cases anyway? In practice, the property type usually stops you before you get far. Still, an unnecessary request creates confusion inside the team. That is why we classify the scenario first and only then decide which tool to touch.

What requirements must you meet before using the tool?

The change of address tool will not let you send a request until a few basic conditions hold. Combining the official help page with our field experience, here is the short list:

1. A permanent 301 redirect points from the old homepage to the new homepage.
2. The old site's canonical pages also redirect with 301 to their new equivalents.
3. Also, you are an owner of both the old and the new property.
4. In addition, the same Google account acts as owner on both properties.
5. You open the tool in a domain-level property. Path-level properties do not support it.

Point four is where most projects get stuck. For example, the agency's account may own the old property while your account owns the new one. In that case the tool will not proceed. So check the owner list on both properties before moving day. If you need to clean up old access first, our guide on removing an old owner from Search Console helps.

Google also asks you to read its site move guides and complete the pre-move work they describe. In practice, the tool is the last link in the preparation chain, not the first one.

How should you prepare your 301 redirects?

A 301 redirect is a server response that tells browsers and search engines a page has moved permanently. Google's documentation on redirects and Google Search explains that 301 and 308 signal a permanent move. It also notes that Google treats the target as the canonical URL.

In practice, we always start with a mapping sheet. Every important old URL gets a one-to-one match on the new site. As a result, you avoid a classic mistake: dumping every old URL onto the new homepage. Our redirect mapping tool speeds up this step.

Next, make each redirect resolve in a single hop. If an old URL jumps to HTTPS, then to www, and then to the new domain, you get a chain. Google's migration guide recommends keeping chains short. We explain the problem in detail in our article on redirect chains.

Finally, test the redirects on the live site. Pick random old URLs and run them through our redirect checker. Each one should return a 301 and land on the right target. The tool itself also checks a few pages for 301 redirects before it sends your request.

How do you verify the old and new properties?

Verification is how you prove to Search Console that you own a site. The tool needs owner rights on both properties. Simple user access, however, is not enough. So add the new domain as a property and verify it before moving day.

There is one important detail here. The tool does not move subdomains below the domain you specify, and that includes www. Google asks you to run the tool for every subdomain variant of the old domain, including www and non-www. You should also verify each variant in Search Console. For example, if both example.com and www.example.com received traffic, both properties need verification.

Protocols, on the other hand, are easier. According to Google, the tool moves all protocols of the source property. So when you file a request for http://example.com, https://example.com moves as well.

Our practical advice: choose a verification method that does not depend on the old server. If you verified with an HTML file on the old host, that verification may break when the host shuts down. A DNS record, by contrast, stays in place during the move. As a result, you keep access to the old property throughout the 180-day monitoring window.

How do you use the change of address tool step by step?

Once preparation is done, using the tool takes a few minutes. Put simply, the real effort sits in the earlier sections. Here is Google's sequence from the help page, with our own practical notes:

1. Finish the pre-move work. The new site should be live, and the 301 redirects should be active and tested.
2. Confirm the requirements. Make sure the same Google account owns both properties.
3. Open the old site's domain-level property and find the change of address tool in the property settings area. Menu labels can change, so look for it under settings.
4. Select the new site from the list and follow the on-screen instructions.
5. The tool runs pre-move checks. If the critical checks pass, confirm the request.
6. Repeat the process in a separate property for each old subdomain variant, such as www.
7. Start monitoring traffic and keep your redirects in place.

When the critical checks pass, the sites involved show a notice that the move is in progress. Google says these notices appear for 180 days. On the new property, you may see a note that other sites are moving to it. As the migration progresses, Google adds traffic from the old site to the new one.

As for timing, the Search Central guide is direct. You submit the request after the redirects are live and tested, as one step in starting the move. A "heads-up before the redirects" approach does not work.

What do the pre-move checks mean?

Pre-move checks are the validations the tool runs before it sends your request to Google. The official help page splits them into two groups: critical checks and non-critical checks. However, the page does not list each check by name or quote exact error messages. So we will not invent screen text here.

If you fail a critical check, you must fix the issue before you can continue. If you fail a non-critical check, you see a warning with recommendations, but your request can still go ahead. The help page also says the tool confirms you own both sites and checks a few pages for 301 redirects.

Specifically, these are the usual reasons a check fails:

• The homepage redirects with a 302 or through JavaScript instead of a 301.
• Instead of redirecting, the old homepage still shows the old content.
• Also, the account that owns the new property differs from the one on the old property.
• The old URL points to a third, intermediate address instead of the new domain.

When you get a warning, first look at the real HTTP response. If the difference between permanent and temporary redirects is unclear, our comparison of 301, 302, 307, and 308 clears it up. That way you fix the cause instead of guessing.

How do you handle subdomains and www variants?

Subdomains are the most overlooked part of the process. According to Google, the tool does not move subdomains below the domain you specify, www included. On the other hand, all paths under that domain move. So a request for example.com covers example.com/blog/, but it does not cover shop.example.com.

Before the move, therefore, list every subdomain of the old domain that gets search traffic. For instance, if a site has the root domain, a www version, and a separate shop subdomain, each one needs its own property and its own request. Google also says that if you want to move a domain and a subdomain to different destinations, you should create a separate property for the subdomain and migrate it separately.

What about domain-level properties in general? The help page says the tool works on domain-level properties. It gives examples like example.com, m.example.com, and http://example.com. Still, the rule that subdomains do not move automatically applies. Verifying each variant separately is the safest route.

Also, avoid changing your subdomain or subfolder structure during the move. Google warns that combining a move with a redesign or URL restructuring may cause traffic loss. Keep the structure as it is, and make structural changes after the move settles.

When should you use the tool, and when not?

The table below compares Google's official guidance at a glance. For each scenario, you can see the right method and whether the change of address tool applies.

Even in the "Yes" rows, do not treat the tool as enough on its own. It works when your redirects and content mapping are right. It cannot fix a bad mapping.

What are common change of address tool mistakes?

The mistakes we see most often come from haste and poor planning, not from a lack of technical knowledge. Google's best practices on the help page address most of them directly:

• Chained moves: You cannot move site B to site C right after moving site A to site B. Google states this explicitly.
• Bulk consolidation: Instead of merging several sites into one new location at once, move them one at a time and wait for traffic to stabilize.
• Combining the move with a redesign: Keep the structure as similar as possible.
• Removing redirects too early: Keep them for at least 180 days, and longer if traffic continues.
• Letting the old domain lapse: Google recommends paying for the old domain for at least a year.
• Forgetting the www variant: Each subdomain variant needs its own request.

We would add one more: poor coordination. If one person uses the tool while another changes redirect rules on the server, the outcome becomes unpredictable. So assign one owner and a written sequence for moving day.

Above all, each of these mistakes can hurt traffic for weeks. If you want us to plan the move with you and track every step, take a look at our SEO consulting service and request a quote for your site.

How do you cancel a move request?

Sometimes a move gets reversed. A rebrand may fall through, or a legal issue may come up with the new domain. Fortunately, Google offers a cancellation path for this; you can still back out. According to the help page, you can cancel within 180 days of making the request.

The order matters, because clicking a button is not enough:

1. Remove the 301 redirect rules from your old server. Otherwise, Google may keep following them.
2. Add 301 redirects from the new site back to the old site.
3. Open the change of address tool on the old site's property and click Cancel Move.
4. Repeat this for each old site you no longer want to move.

The help page names the button Cancel Move. Interface labels can change over time, though, so look for the cancel option on the tool's screen in the old property.

Keep in mind that canceling does not magically restore rankings. Google has to process the redirects in both directions again, and that takes time. For that reason, treat cancellation as a last resort. The healthiest approach is to settle the decision before you ever open the tool.

How should you manage sitemaps after the move?

A sitemap is an XML file that lists the URLs you want Google to crawl. During a move, sitemaps help Google find new URLs faster. The Search Central guide recommends preparing two sitemaps from your URL mapping. One holds the old URLs, and the other holds the new URLs.

You submit the new sitemap in the new property. According to the guide, the new sitemap initially shows zero pages indexed, which is normal. Meanwhile, the indexed count for the old sitemap should decline over time. Redirect warnings on the old sitemap are expected, and you can ignore them.

After that, once Google uses the new sitemap, you can remove the old one. We do not rush this step. We wait until the old sitemap's count has dropped noticeably before removing it.

For a refresher on sitemap basics, see our guide on XML sitemaps. If the new property cannot read the sitemap, the cause is often an access setting on the new server.

What should you monitor in Search Console after the move?

After you use the change of address tool, the real work begins: monitoring. The Search Central guide says that ideally traffic on the old site goes down while traffic on the new site goes up. We split monitoring into these areas:

• Overall traffic: Compare the performance reports of the old and new properties side by side.
• Index status: Indexed counts should fall on the old site and rise on the new site. Check regularly for unexpected crawl errors.
• Search queries: Watch for new URLs to start earning impressions and clicks.
• Server logs: Confirm that Googlebot crawls the new site and that no URLs return unexpected error codes.
• Analytics: Real-time reports help you see user traffic quickly in the first days.

Also, do not delete the old property after the move. Traffic to old URLs, broken redirects, and crawl errors only show up there. The move notices also stay on both properties for 180 days.

If traffic drops, break it down by query and page before you panic. We walk through the method in our article on diagnosing a traffic drop in Search Console. That way you can tell whether the move caused the drop or something else did.

When does traffic recover?

There is no exact answer, and nobody should promise you a date. The Search Central guide says that for small to medium sites, it can take a few weeks or more for Google to start showing the new URLs. Larger sites can take even longer.

Still, another line in the guide matters even more. For the move to count as complete, Googlebot must visit every URL on the old and new site at least once. That means deep pages with little crawl activity settle last. Updating internal links to the new URLs is therefore one of the most practical ways to speed up crawling.

You should also expect fluctuation in search visibility during the move. Google says rankings will settle down over time. However, that is not a guarantee. Redirect errors, missing content, or structural changes can turn a temporary dip into a lasting loss.

Instead of a fixed calendar, we suggest checkpoints. For example, in the first week we watch redirects and crawl errors. In the first month we track indexed counts. In later months we look at query-level performance. This shifts the question from "when will it recover" to "where do we stand right now."

What happens after 180 days?

The change of address tool works for a limited time. According to Google's help page, after 180 days Google no longer recognizes any relationship between the two sites. If the old site is still online and crawlable, Google treats it as an unrelated site.

This also shows why redirects matter so much. After the tool's window ends, the flow of signals to the new site depends largely on your 301 redirects. The help page recommends keeping redirects for at least 180 days, or longer if search traffic continues. The Search Central migration guide goes further. It advises keeping redirects as long as possible, generally at least one year.

In short, the safe choice is to keep redirects for at least a year, and ideally longer. Our article on how long 301 redirects should stay helps you make that call.

Likewise, letting the old domain go is a separate risk. Google recommends paying for it for at least a year. We usually advise keeping it longer. If someone else registers your old domain, your old backlinks start working for them instead of you.

Example scenario: how does a move from example.com to example.net unfold?

The scenario in this section is purely an example. It does not describe a real client or real numbers. A service business decides to move from example.com to example.net after a rebrand. The www version of the site also receives traffic.

First, the team exports every important URL from the old site and maps it to a new URL. They keep the structure the same on purpose and postpone the redesign until after the move. Then they add the new domain to Search Console and verify it with a DNS record. They also confirm that the same Google account owns both old properties, example.com and www.example.com.

Next, on moving day, the new site goes live. The team activates the 301 redirects and tests them with random URLs. After that, they open the change of address tool in the old property, select the new site, and submit the request once the critical checks pass. They repeat the process for the www property.

Over the following weeks, the team submits the new sitemap and keeps the old one for a while. They monitor both properties side by side. After that, they update internal links, social profile URLs, and important external links to the new domain. They also decide to keep the old domain and the redirects for at least a year. In this scenario, success comes from the disciplined preparation around the tool, not from the tool alone.

Which links should you update after the move?

Redirects rescue old links, but every redirect slows users down a little. The Search Central guide therefore recommends updating your own links and high-volume external links to the new URLs.

In practice, our update list usually follows this order:

1. The site's own internal links, menus, and footer links.
2. Canonical tags, hreflang tags, and URLs inside structured data.
3. Your Google Business Profile, social media profiles, and email signatures.
4. Final URLs and tracking parameters in your ad accounts.
5. Requests to the owners of important external links that send traffic.

If internal links still point to the old domain, Google follows a redirect every time. This slows crawling and delays the "every URL visited at least once" condition we mentioned above. So crawl the whole site right after the move and list any links that still point to the old domain.

Also watch for canonical tags that still point to the old domain. That creates conflicting signals between redirects and canonicals. Our article on detecting canonical issues in Search Console shows how to find these mismatches.

How does this guide differ from a full site migration guide?

This guide focuses only on the change of address tool. It covers requirements, steps, checks, cancellation, and monitoring. A site migration, by contrast, is a much broader process. It runs from content inventory and staging to URL mapping and the launch-day plan.

If you are planning the whole move, our website migration SEO checklist is the right starting point. We did not repeat its steps here. The tool is just one of the launch-day steps on that list.

In short, we recommend reading both. First build the overall migration plan. Then, if a domain change is involved, use the change of address tool with the steps in this guide. That way you neither use the tool with incomplete preparation nor waste time in a scenario that does not need it.

One more note: some problems during a move have nothing to do with the tool. A rule on the new server might create a loop, or a security plugin might block Googlebot. If you blame the tool for these issues, you will look for the fix in the wrong place. Check server responses first.

Who should manage a site move?

The change of address tool is simple on its own. The preparation, testing, and monitoring around it, however, involve many technical decisions. For example, one wrong redirect rule or one forgotten subdomain can cause months of lost visibility. That is why one accountable owner with a written plan matters.

At Talha Aslan and team, we prepare the mapping sheet for domain moves, test the redirects, run the tool in the right order, and monitor both properties for 180 days after the move. We never guarantee rankings, because Google's systems decide the outcome. Our commitment is to spot risks early and reduce the chance of loss.

If you are planning a domain change, or your traffic is not behaving as expected after a move, we can solve the issue on your site and keep tracking it with you. To see the scope and process, request a quote through our SEO consulting page.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.