How to Use Search Console’s Change of Address Tool Without Turning a Domain Move Into an SEO Emergency

By /

Moving a website to a new domain is one of the more consequential technical changes a site owner can make.

Example:

oldsite.com

becomes:

newsite.com

The change affects more than branding.

Google needs to understand that:

The old URLs have permanently moved to corresponding new URLs.

Search Console includes a Change of Address tool specifically for qualifying domain and subdomain moves.

Google says the tool helps communicate the move and migrate Google Search signals from the old site to the new site. It should be used after the site has been moved and redirects have been implemented.

That last part matters.

The tool is not the migration.

It is one part of the migration.

When Should You Use It?

Google currently says the Change of Address tool is appropriate when moving from one domain or subdomain to another.

Examples:

example.com → example.org

or:

old.example.com → new.example.com

That is a true site-address change.

When Should You NOT Use It?

Google specifically says not to use the tool for:

HTTP → HTTPS

Google can process that type of migration through the normal site-move signals without the Change of Address tool.

Moving Pages Within the Same Site

Example:

example.com/old-section/page

to:

example.com/new-section/page

Use redirects and updated sitemaps where appropriate.

Do not submit an entire Change of Address for a path reorganization.

Step 1: Prepare the New Site First

Do not announce the move before the new destination works.

Confirm:

  • New domain resolves.
  • Pages load.
  • Important content exists.
  • HTTPS works.
  • Internal navigation works.
  • Analytics is configured.
  • Search Console property exists.

The new website should be usable before redirecting the old one.

Step 2: Map Old URLs to New URLs

Ideally:

Old Page → Equivalent New Page

Example:

oldsite.com/email-guide

→

newsite.com/email-guide

Avoid redirecting every old URL to:

New homepage

unless that genuinely represents the replacement.

Specific redirects make the relationship clearer for users and search engines.

Step 3: Use Permanent Redirects

For a permanent domain migration, use appropriate permanent server-side redirects such as:

301

where applicable.

The redirect tells browsers and search engines:

This resource permanently moved.

Do not rely solely on:

  • JavaScript redirect.
  • Meta refresh.
  • Manual link.

Step 4: Update Canonical URLs

Pages on the new domain should identify the new URLs appropriately.

Do not leave canonical signals pointing back to the old domain unintentionally.

A migration works best when the major signals agree:

Redirect → Canonical → Internal Link → Sitemap

Step 5: Update Internal Links

Do not force every visitor through redirects forever when you control the links.

Update:

  • Navigation.
  • Blog internal links.
  • Footer links.
  • Image links.
  • Calls to action.

to point directly to the new domain.

Redirects remain important for external and old links.

Step 6: Update the Sitemap

Create or update the sitemap using the new domain URLs.

Submit the relevant sitemap through the new Search Console property.

Your verified Search Console Sitemaps guide explains why a sitemap is primarily a discovery and monitoring tool rather than a manual URL-submission list.

Step 7: Verify Both Properties

Google currently requires that you be an owner of both:

  • Old property.
  • New property.

using the same Google account for the Change of Address process.

If you do not control both:

Fix property ownership before beginning the Search Console submission.

Property Scope Matters

Google states that the Change of Address tool works at the domain level, not for path-only properties.

You can move appropriate domain or subdomain properties, but you cannot use the tool to move something like:

example.com/store/

as though it were an independent domain migration.

Subdomains Need Attention

Google specifically warns that the tool does not automatically move all lower subdomains beneath a submitted domain.

For a domain move involving variants such as:

  • example.com
  • www.example.com
  • en.example.com

you may need to account for the relevant old-domain variants independently.

Do not assume one click covers every host configuration.

Step 8: Submit the Change of Address

Only after:

  • New site works.
  • Redirects exist.
  • Ownership is verified.

use Search Console’s Change of Address workflow.

The tool is a signal to Google supporting the technical migration you already completed.

Do Not Remove the Old Domain Immediately

One of the biggest migration mistakes is:

“The redirect works, so I can stop paying for the old domain next month.”

If the old domain disappears:

The redirects disappear too.

Keep control of the old domain long enough to preserve migration signals and protect old links.

For important business domains:

Long-term retention may make sense for branding and security reasons too.

Monitor the Old Property

After migration:

The old property may gradually lose search activity.

That can be expected.

Look for:

  • Remaining indexed URLs.
  • Crawl problems.
  • Redirect errors.

Do not immediately treat declining old-domain traffic as a new SEO disaster.

Traffic is supposed to move.

Monitor the New Property

Watch:

  • Indexing.
  • Clicks.
  • Impressions.
  • Queries.
  • Pages.

The new site may experience temporary volatility while Google processes the move.

Avoid changing unrelated SEO elements every day during this period.

You need a clean enough migration to distinguish:

Normal transition

from:

Actual technical problem.

Check Redirects at the Page Level

Test:

  • Homepage.
  • Top traffic pages.
  • Important product pages.
  • Top backlinks.
  • High-value lead pages.

Do not test only one URL and assume the whole site works.

Look for Redirect Chains

Weak:

Old URL → Temporary URL → New URL

Better:

Old URL → Final New URL

Reduce unnecessary hops where possible.

Do Not Change Everything at Once

A domain migration is already a major change.

If possible, avoid simultaneously changing:

  • Domain.
  • CMS.
  • Site structure.
  • Every title.
  • Every URL.
  • Every page.

The more variables changed at once:

The harder troubleshooting becomes.

Search Console Cannot Repair a Bad Migration

The Change of Address tool will not fix:

  • Missing redirects.
  • Broken pages.
  • Incorrect canonical tags.
  • Blocked crawling.
  • Missing content.

It supports a technically sound move.

It does not replace one.

Use URL Inspection During Troubleshooting

For individual important pages:

Use:

URL Inspection

to check how Google understands the new URL.

Your verified Search Console URL Inspection guide is useful when one page behaves differently from the rest of the migration.

Use Page Indexing for Broader Problems

If large groups of new-domain pages are not indexed:

Use the Page Indexing report.

Your verified Search Console Page Indexing guide can help separate normal exclusions from actual migration issues.

Record the Migration Date

Document:

Migration Date

Redirect Activation Date

Change of Address Submission Date

New Sitemap Submission Date

Then you can interpret Search Console changes relative to actual events.

Preserve a Rollback Plan

Before migration:

Take appropriate backups.

Document:

  • Old hosting configuration.
  • DNS settings.
  • Important redirects.
  • Site files.

If something fails badly, you want a known path back.

A Simple Domain Migration Checklist

BEFORE

  • Verify old Search Console property.
  • Verify new Search Console property.
  • Back up site.
  • Map old URLs.
  • Build new site.
  • Test new domain.

MIGRATION

  • Activate permanent redirects.
  • Update canonicals.
  • Update internal links.
  • Update sitemap.
  • Test important URLs.

SEARCH CONSOLE

  • Submit new sitemap.
  • Use Change of Address.
  • Monitor old property.
  • Monitor new property.

AFTER

  • Fix broken redirects.
  • Monitor indexing.
  • Monitor search performance.
  • Keep old domain active.

Conclusion

Search Console’s Change of Address tool is designed for qualifying domain or subdomain migrations.

It should be used after the technical move and redirects are already in place.

The correct sequence is:

Build New Site → Redirect Old URLs → Verify Properties → Update Signals → Submit Change of Address → Monitor

Do not use it for:

  • Simple HTTP-to-HTTPS migration.
  • Ordinary page moves within the same domain.

And do not expect the Search Console button to repair a migration whose redirects or destination pages are broken.

Your Next Action

If you are not currently moving domains, do not submit anything.

Instead, save this checklist with your website documentation for the day you need it.

If you are planning a domain migration:

Do not begin with the Change of Address tool.

First create a spreadsheet containing:

Old URL | New URL | Redirect Tested | New Page Working | Canonical Correct

Start with your 20 most important pages.

Only after the new site and redirects are working should you verify ownership of both Search Console properties and proceed with the formal Change of Address process.

That puts the technical migration first and the Search Console notification second.

Scroll to Top