Search Console Change of Address: When to Use It

Use the Change of Address tool only when your site moves from one domain or subdomain to another, and only after the move is finished and the old addresses redirect to the new ones. If you are switching to HTTPS, adding or dropping www, moving pages inside one site, or changing hosts while the URLs stay the same, Google's help page tells you to leave the tool alone. Whether you are renaming a brand or running a move for a client, three questions settle the matter before you open Search Console.

Three questions that decide it

Answer these in order and stop at the first "no".

1. Does the domain or subdomain in your addresses change, for example from one registered name to another?
2. Is the move finished, with the old homepage sending a 301 redirect to the new homepage and the other key pages redirected as well?
3. Do you own both the old and the new property in Search Console, with the same Google account, at domain level?

Decision table: what each answer means.

Practical suggestion: write the three answers into the project notes with the date. If someone later asks why the tool was or was not used, the note settles it in one line.

What the tool does and does not do

A notification that sits on top of redirects

The Change of Address help page (Opens in a new tab) lists pre-work for every move: set up a 301 redirect from the old homepage to the new homepage and, ideally, from the key canonical pages too, then read the site move guidance and complete the actions it describes. The tool tells Google the move is deliberate. It does not redirect anything and it does not replace the redirects, content or server work. If the redirects break after the notification, the notification does not repair them.

The help page makes no promise about rankings or timing of results. Treat the tool as one step in a chain that Google's site move guide (Opens in a new tab) lays out: turn on the redirects, confirm canonical tags and robots rules point to the new URLs, test the redirects, use the tool if the domain or subdomain changes, then submit the new sitemap and remove the old one.

What changes for 180 days

After the critical checks pass, the help page says Google, for 180 days, emphasizes crawling and indexing of the new site, forwards signals from the old site to the new one and prefers the new site as the canonical version. Old URLs without an equivalent on the new site can still appear in results. Redirects and rel=canonical tags reduce that. When the 180 days end and the old site is still present and crawlable, Google treats it as an unrelated site.

Moves where the tool is the wrong answer

Table: changes the help page excludes and where Google points instead.

HTTPS and www changes

These stay inside one domain, so the tool has nothing to notify. Canonical tags and permanent redirects do the work. The tool also moves every protocol of the source property, so an http:// property already covers https://. Do not read that as the tool handling an HTTPS migration; the two topics are separate. For the version choices see www, HTTPS and trailing slash standardization, and for post-migration content checks see mixed content and HSTS after an HTTPS migration.

A new host with the same URLs

Google's guide for moves without URL changes (Opens in a new tab) says it is only for migrations that do not affect the user-visible URL. Its steps are to prepare and test the new infrastructure, update DNS records to point to it after removing temporary crawl or index blocks, watch the logs of both servers and check DNS propagation across internet service providers, then shut down the old hosting only once traffic to it reaches zero. It suggests lowering the TTL to a conservative low value, such as a few hours, at least a week before the move. The page does not mention the Change of Address tool.

Page moves inside one site

If a section changes its path, add redirects and update the sitemaps. The tool works at domain level and cannot express a path change, so it would have nothing to carry.

Ownership and property rules

Table: requirements stated on the help page and how to prepare.

Why a path-level property cannot move

The help page states that the tool cannot move something like example.com/petstore/. If your Search Console setup contains only URL-prefix properties for paths, add the domain-level property of the old site before the move. For the difference between a domain property and a URL-prefix property, see Search Console domain versus URL-prefix property.

Every variant gets its own notification

For a domain move, the help page asks you to use the tool for every subdomain variant of the old domain, including www and non-www, and to verify all of them in Search Console. If the www and non-www versions are separate properties, run the tool twice. A subdomain such as shop.example.com is not carried along with the main domain.

When an agency runs the move

Ownership is the condition an agency most easily fails, because the properties may have been created by someone else. Practical suggestion: record in writing which account owns both properties, and who at the client can restore access if that account disappears. The site move guide also asks you to keep verification files, tags or includes on the new site, so remind the client's developers not to clean them out during the redesign.

Preparation Google expects before the move

The site move guide lists prerequisites that apply before the redirects go live. Table: area, action and reason.

The same guide also asks you to check the new domain for manual actions and leftover URL removals. Each item should be checked and dated. If your Search Console interface is not in English, match the settings by meaning rather than by label.

Building the list of old URLs

For a simple domain change a wildcard redirect may be enough. Larger moves need a full list of old URLs gathered from sitemaps, traffic data, server logs, the CMS and Search Console, and the list should include images, videos, JavaScript and CSS files. Each old URL gets one new URL. Canonical tags, hreflang annotations and internal links then point to the new addresses. The mapping itself is a separate job from the notification; the tool does not read your list.

Redirect rules the guide asks for

• Use server-side permanent redirects such as 301 or 308 wherever possible, and client-side redirects only as a last resort.
• Avoid chaining redirects. Send each old URL straight to its final destination.
• Avoid redirecting many pages to an unrelated URL such as the home page.
• Small and medium sites should move all at once, while large sites can move in sections.

Running the tool, step by step

The sequence follows the help page. If your Search Console interface is not in English, menu names may look different, and the screens change over time, so the steps describe the logic instead of screenshots.

1. Finish the pre-work: redirects in place, site move guidance read.
2. Check the conditions: both properties owned, same account, domain level.
3. Open the tool on the old site's domain-level property.
4. Work through the pre-move checks. Critical failures must be fixed before you continue; non-critical failures only produce warnings.
5. When the critical checks pass, move notifications appear in Search Console for 180 days.
6. Monitor traffic as the site move guide describes.
7. Keep the redirects for at least 180 days, longer if Google Search still sends traffic to the old URLs.

When a pre-check fails

A critical failure blocks the notification until you fix the cause. Read the explanation on the screen first, then test the old homepage redirect in a browser and with a command-line tool, separately. If the failure concerns ownership, confirm that both properties are verified under the same account. After the fix, run the checks again. The help page does not list which check falls into which category, so rely on the on-screen text. Practical suggestion: copy warnings into a log and close them one by one after the move.

Keeping a record of each submission

Write down the date, the property you used and the result on the screen for every variant. Half a year later that table is the only reliable way to know what was done when, and it matters if you need to cancel.

Example scenario: a community radio station

Example scenario: a volunteer-run community radio station keeps its schedule, podcast archive and donation page on a subdomain of its old association domain. The association merges with another group and the station adopts a new brand name, so the whole site moves to a new domain. The old setup has two verified properties: the bare domain and the archive subdomain, plus a www property that was added years ago.

The station first adds the new domain in Search Console and verifies it under the same account that owns the old properties. During the launch week a volunteer removes an old verification file from the previous server because it looks like clutter, and the old domain's property loses its verified status. The station notices when the tool refuses to continue, restores ownership with a DNS record instead of a file and moves on. Practical suggestion: keep a short list of verification items that must never be deleted.

Because the archive pages receive a new path structure on the new domain, the station prepares a separate mapping table before the notification. After submitting all three, it puts the 180-day end date and the old domain's renewal date into the shared calendar.

What the 180 days look like

Table: statements from the help page, by period.

Old URLs that keep appearing

The help page says redirects and rel=canonical tags reduce how long old URLs appear without an equivalent. Close the gaps in your mapping early, because an old URL with no good destination is the one most likely to linger.

The note on the destination property

If Search Console shows a note that other sites are moving to your property, the help page says traffic from those sites is added gradually as users are redirected. Practical suggestion: when several old sites feed one new property, check for this note on the new property and still verify the status on each old property, since the documentation does not say what a missing note means.

Moves that need extra care

The help page lists best practices for merging and chaining. Table: situation and guidance.

Whether a subdomain or a subfolder is the better structure is an architecture decision. The subdomain versus subfolder comparison covers it, and it is easier to judge when it is kept apart from the move itself.

Monitoring plan

The site move guide says to use the Sitemaps report, the Index Coverage report and search query data in Search Console, to watch server logs for Googlebot activity and error codes, and to review analytics for traffic shifting from old to new URLs. Warnings about redirects in the old sitemap are normal and can be ignored. It also asks for patience: medium-sized sites can take a few weeks or more, larger sites longer, and a temporary ranking fluctuation during the move is to be expected.

Table: a working schedule. Google does not publish a schedule, so this is a practical suggestion.

Reading the ranking statements together

The site move guide says 301 and other permanent redirects do not cause a loss in PageRank, and it also says to expect a temporary fluctuation in ranking during the move. Both statements are on the same page. A correct redirect setup does not remove value in transit, but it does not promise a flat graph either.

Redirects and the old domain: how long

The Change of Address help page says to keep the redirects for at least 180 days, longer if Google Search still sends traffic to old URLs, and to keep paying for the old domain for at least a year so that others cannot acquire it for malicious use. The site move guide says to keep the redirects for as long as possible, naming at least one year. The pages do not contradict each other: 180 days is the floor, a year is the safer target. Google's limits can change, so check the current pages before you act.

Redirects add a step for users. The site move guide asks you to update your own links and high-volume external links to the new URLs instead of relying on redirects. Practical suggestion: tie the decision to removing redirects to measurement, not a calendar date. When the old addresses no longer receive traffic from Google Search and a year has passed, removal becomes a reasonable question.

A redirect works only while the old domain resolves. If the registration lapses, the redirects stop, which is the practical reason behind the one-year registration advice. Put the renewal date in the calendar and check that the payment method on auto-renewal is still valid.

Cancelling a move

If you notified the wrong domain or want to reverse the move, the help page allows cancellation within 180 days of the request.

1. Remove the existing 301 redirects from the old server.
2. Add 301 redirects from the new site back to the old site.
3. In the tool on the old site, click "Cancel Move" (the label may differ in a translated interface).
4. Repeat these steps for each old site.

Practical suggestion: decide before the move who would run the cancellation and how long the server change takes. If that is only discussed during an emergency, the 180-day window can shrink while people look for server access.

Misreadings to correct

Checklist: before, during and after the notification

• The change really is from one domain or subdomain to another.
• The old homepage and key canonical pages redirect with 301 to their new equivalents.
• You own both properties under the same Google account at domain level.
• Every variant of the old domain, including www and non-www, is verified.
• Verification files, tags or includes remain on the new site.
• Critical pre-checks pass; warnings are logged.
• The tool is run once per variant and each submission is recorded.
• The 180-day end date is in the calendar.
• Old and new sitemaps are watched, with ranking fluctuation expected.
• Redirects and the old domain registration are kept for at least the periods the help page names.
• The cancellation steps and the person responsible are written down.

Frequently Asked Questions

When should I use the Change of Address tool?

Google's help page says to use it when you move a site from one domain or subdomain to another, for example from example.com to example.org, and to run it after you have moved and redirected the site.

Do I need the tool for an HTTP to HTTPS switch or a www change?

No. The help page lists HTTP to HTTPS, www to non-www on the same domain, moving pages inside one site, and moves with no URL changes such as a host or CDN switch as cases where you should not use the tool.

What has to be true before I can use it?

You must own both the old and the new property, using the same Google account. The tool works at the domain level only, it does not move subdomains for you, and for a domain move you need to verify and notify every variant of the old domain, including www and non-www.

What happens after I submit the move?

Once the critical pre-checks pass, move notifications appear in Search Console for 180 days. During that time Google emphasizes crawling and indexing the new site, forwards signals from the old site and prefers the new site as canonical. After 180 days an old site that is still present and crawlable is treated as unrelated.

How long should the redirects stay in place?

The tool's help page says at least 180 days, longer if Google Search still sends traffic to the old URLs. The site move guide says to keep redirects as long as possible and names at least one year. The help page also suggests keeping the old domain registered for at least a year.

Can I undo a move after submitting it?

Yes, within 180 days of the request. Remove the 301 redirects on the old server, add 301 redirects from the new site back to the old one, then click "Cancel Move" in the tool on the old site. Repeat the steps for each old site.

Is the tool needed when only the host changes and the URLs stay the same?

No. Google's guide for moves without URL changes covers host and CDN switches and does not mention the tool. It asks you to lower DNS TTL ahead of time, keep the old server running and retire it only when traffic to it reaches zero.

Conclusion

The Change of Address tool has a narrow job. It tells Google that a site has moved from one domain or subdomain to another after the move and the redirects are done. It is not for HTTPS, www, in-site page moves or host changes, and it asks for owner access to both properties under one account at domain level, with each variant of the old domain notified separately. For 180 days Google emphasizes the new site, then treats a still-present old site as unrelated, so keep redirects at least that long and the old domain registered for a year. Write down every submission, the end date and the cancellation steps, and keep checking the mapping for gaps.

Once the new domain is live, earning its first links is the next job, and our guest post service can help with that.