Decide whether a domain move is ready for Search Console Change of Address

Name exactly what is changing

Write old domain, new domain, protocols, and representative service paths. If the visible hostname is unchanged and only hosting changes, this is not a Change of Address case. Likewise, moving /services/repair to /repair within the same site is a path change. Clear classification prevents using a migration tool to solve the wrong problem.

Source checks: Google Search Console: Change of Address tool · Google Search Central: Site moves with URL changes

Secure both sides before the move

Confirm authorized owner access to the relevant old and new Search Console properties under the required account arrangements. Retain control of the old domain and its hosting or redirect service. List active subdomains and host variants so none are accidentally left behind. The tool's property scope should not be assumed to move every sibling host automatically.

Map service destinations before submitting

For each important old URL, choose the genuine new replacement. Preserve useful paths where practical and make exceptions explicit. Test the new site for public access, working inquiries, accurate content, preferred canonicals, and sitemap destinations. Do not send the move request while the new production site still carries staging restrictions.

Use the tool after working redirects exist

Create a short migration acceptance list.

• Implement relevant permanent redirects from old pages to their new equivalents.
• Test the old homepage and multiple service URLs, not only one root-domain visit.
• Use the eligible verified properties for the supported Change of Address workflow.
• Submit the new preferred sitemap and update links you control.
• Record variants, submission dates, and owners for later follow-up.

Avoid stacking several unrelated migrations

Changing domain, platform, content structure, and service names together makes debugging harder. Where practical, separate those changes so a broken destination can be traced. Avoid chaining a move immediately through another new domain. A successful tool submission does not repair poor page mappings or a missing current service page.

Keep the old route useful during processing

Google's site-move guidance recommends retaining redirects for generally at least a year, and visitor links may justify longer. Monitor old and new URL behavior, recorded indexing observations, and inquiry delivery. Do not expect every search result to switch simultaneously. Report migration progress separately from claims about stronger rankings.

Maintain a compact post-move sheet for the highest-value old URLs. Include old path, mapped destination, current response, last tested date, and who can repair it. If a directory or customer bookmark still uses the old address months later, this record gives the administrator an exact route to verify instead of restarting the migration discussion.

Illustrative domain change with intact service mapping

An illustrative business moves from old-example.com to example.com. Its /window-repair service remains /window-repair on the new host. Both properties are verified, old service requests redirect to their new equivalents, and new inquiries work. The owner then uses the supported tool and keeps redirects active. An HTTPS-only change would not use this tool.

For this migration, the page map includes the homepage, /window-repair, and the contact destination. Each old URL is tested as an independent request. The owner also inventories host variants before using the tool, because a single successful old homepage check does not establish that every active variant and deep service link works.

Questions about this task