BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Using GSC’s Change of Address Tool: The Practitioner Walkthrough for Migrating a Domain Without Losing Rankings
The Change of Address tool in Google Search Console is the one signal you send Google to say, in its own words, that your site has moved from an old domain to a new one. It tells Google to emphasise crawling and indexing your new site and forwards the inherited ranking signals from the old domain to the new one for a fixed window.
The tool itself takes about a minute to file. The reason migrations still go wrong is that the tool is the last step in a sequence, not the whole job. File it before your redirects resolve, on the wrong property type, or to a destination domain that carries a buried penalty, and the move stalls or fails quietly.
This walkthrough covers the real procedure: what the tool does, the five prerequisites it checks, the scenarios it does not support, the exact submission steps, the mistakes that void a move, and the variable every other guide skips, the quality of the new domain you are migrating to. SEO Domains operates the curated marketplace where that destination domain is screened before you build your move on it, a 220,000+ pre-screened catalogue running from $100 entry-level aged domains through premium acquisitions.
What the Change of Address tool actually does
The Change of Address tool tells Google your site has moved to a new domain and helps migrate your Google Search results from the old site to the new one. Google states it forwards signals from the old site to the new site and tells Google to emphasise crawling and indexing your new site over the old one, for a window of 180 days.
The tool is a notification, not a redirect. Your 301 redirects do the actual forwarding of users and link equity at the server level. The Change of Address request sits on top of that and tells Google to read the whole move as one event instead of inferring it page by page from the redirects alone. Google describes the request as a way to migrate your search results from the old site to the new site.
The signal it sends, and the window it lasts
When the request is approved, Google emphasises crawling and indexing the new domain and forwards ranking signals across. That forwarding runs for 180 days. After 180 days, in Google’s own phrasing, Google does not recognise any relationship between the old and new sites, so the redirects and the new domain stand on their own from that point.
One detail trips up first-time migrators. The tool does not erase the old site from the index. Google notes that URLs from the old site can continue to be shown in Search results if they are available and do not have an equivalent page on the new site. The tool accelerates and clarifies the move; it does not delete the past.
Why it is the last step, not the whole job
The tool occupies one box near the end of a longer checklist. Google Search Central lays out the order of a site move with URL changes: prepare the new site, build a URL map from old to new, implement server-side 301 redirects, submit the Change of Address, then monitor both properties. Filing the request first, before the redirects are live and verified, is the single likeliest way the move fails its pre-checks. The full sequence is documented in the hub’s Migration technical checklist, and the redirect map itself in Building the 301 mapping sheet.
Before you submit: the five prerequisites the tool checks
The tool runs pre-move checks before it accepts the request. To pass, you need both properties verified under one Google account, 301 redirects live from the old homepage to the new homepage, redirects on canonical pages, internal links and the sitemap updated, and a clean destination with no blocking manual action. A critical failure blocks submission; a non-critical issue raises a warning and lets the request continue.
The five gates, in order
- Own both properties. Google states you must be an owner of both the old and new properties in Search Console, managed under the same Google account. Verify the new domain before you go near the tool.
- 301 the homepage first. Implement a 301 redirect from the old homepage to the new homepage before using the tool. Google also recommends 301 redirects for the canonical pages on the old site, so the per-URL move has a path to follow.
- Update internal links. Point your own internal links at the new URLs rather than relying on the redirect chain to carry every click. This removes redirect hops and tells Google the new URLs are canonical.
- Refresh the sitemap and robots rules. Submit a new sitemap on the new property and confirm robots.txt is not blocking the new URLs. A new domain that blocks crawling cannot receive the forwarded signals.
- Clear the destination. Confirm the new domain has no unresolved manual action and no toxic history that would taint the inherited move. This is the gate the tool itself cannot fully see, and the one this guide returns to.
Domain property vs URL-prefix property
The verification step hides a fork that decides whether the tool will even appear. The Change of Address tool runs on domain-level properties such as example.com or m.example.com. Google is explicit that you cannot move properties at the path level, such as example.com/petstore/. If your new property is a URL-prefix property scoped to one address, re-verify it as a Domain property so the tool covers the full move. The diligence on choosing that destination is covered in How to pick the new domain for migration.
What the tool supports and what it does not
The Change of Address tool is built for one job: moving an entire domain to a different domain. It moves all protocols of the source property at once, so specifying the http version also moves the https version. It does not move subdomains, including www, which require a separate submission each. It is not for HTTP-to-HTTPS moves, path-level moves, or www-variant changes, which use redirects and canonical tags instead.
The scenario matrix
The fastest way to know whether the tool is the right instrument is to match your move against the scenarios below. The two rules that catch people are the subdomain rule and the HTTP-to-HTTPS exception, both stated directly in Google’s documentation.
| Your move | Use the tool? | What to do instead, or also |
|---|---|---|
| olddomain.com to newdomain.com (full domain swap) | Yes | The core use case. 301 the homepage and canonicals, then submit. |
| brand.com to brand.io (TLD change) | Yes | Same as a full swap. It is still a domain-to-domain move. |
| www and non-www of the SAME domain | No | Set a canonical and 301 the variant you are dropping. No tool needed. |
| blog.brand.com to brand.com (subdomain to root) | Partly | The tool does not move subdomains. Submit per subdomain variant, or treat it as a path move with redirects. |
| http://brand.com to https://brand.com | No | Google says do not use the tool for HTTP to HTTPS. Use 301 redirects and follow the standard URL-change guidance. |
| brand.com/old to brand.com/new (same domain) | No | Path-level move. Use redirects and an updated sitemap only. |
| Same URLs, new host or CDN | No | No URL change means no move to declare. |
The subdomain and protocol rules in practice
Two of Google’s statements deserve repeating because they cause silent half-moves. First, the tool does not move any subdomains below the specified domain, including www, so a site that serves www, a blog subdomain, and a language subdomain needs the request filed separately for each. Second, the tool moves all protocols of the source property, so if you specify http://example.com it also moves https://example.com. Filing once for the bare domain handles the protocol spread, but never the subdomain spread.
How to submit a Change of Address, step by step
The submission is six steps: verify the new domain as a Domain property, deploy the 301 redirects from old to new, open the old property in Search Console, find the Change of Address tool, select the verified new domain, then run the validation and submit. Each step pairs the correct move with the specific mistake that fails the pre-check.
The walkthrough below assumes the prerequisites from the previous section are already in place. The order matters: the tool validates your redirects at submission time, so the redirects have to be live and resolving before you reach the final step. Test them on staging first, the way the hub’s Testing migrations on staging guide describes, so the public switch is the only live change.
-
Verify the new domain as a Domain property
Add the new domain in Search Console and verify it as a Domain property, which covers http, https, www and non-www together. Use the same Google account that owns the old property. Enter the address carefully, including the protocol where the interface asks for it.
The mistake: verifying a URL-prefix property scoped to one address. The Change of Address tool will not appear, because it needs a domain-level property to declare a domain-level move.
-
Deploy the 301 redirects from old to new
Map every old URL to its new equivalent and serve a server-side 301 from old to new. Start with the homepage, which Google requires, then the canonical pages. Confirm each redirect returns a single 301 hop with no chain and no 302.
The mistake: filing the request before the redirects resolve. The pre-move check reads the live redirect, and a missing or 302 redirect blocks the submission.
-
Open the old property in Search Console
Select the OLD domain property in the property switcher. The Change of Address request is filed from the property you are moving away from, declaring where it is going, not from the destination.
The mistake: trying to start the request from the new property. The move is declared from the source, so the tool lives in the old property’s settings.
-
Find the Change of Address tool
Open Settings on the old property and select Change of Address. In the current interface the tool sits under the property Settings panel. The tool then runs a short set of pre-move checks against your redirects and verification state.
The mistake: assuming the menu path is fixed. Google updates the interface, so navigate by the Change of Address label instead of a memorised click path.
-
Select the verified new domain
Choose the new domain from the dropdown of properties you own. Only verified Domain properties under the same account appear here, which is why the verification in step one has to be complete first.
The mistake: the new domain not appearing in the list. That means it is unverified, verified under a different account, or verified as the wrong property type.
-
Run validation and submit
Run the validation and submit. The tool runs its pre-move checks: a critical failure blocks the request, while a non-critical issue raises a warning with recommendations and lets you continue. On approval, every property moving from or to will display an in-progress notification for the duration of the window.
The mistake: dismissing a warning without reading it. A warning is the tool telling you a redirect or variant is imperfect, and ignoring it is how partial moves happen.
Done right vs done wrong: the mistakes that void a move
The Change of Address tool used well is a clean accelerator: live 301s, a domain property, every variant covered, redirects kept alive past the window, and a destination domain with a clean history. Used badly it produces a silent half-move: filed before redirects resolve, on a path-level property, missing subdomains, on a destination that carries a buried penalty. The tool reports success either way, so the difference shows up only in the traffic.
This is the honest reality of the tool. It is not a magic ranking-saver, and it is not a trap. Filed correctly into a well-built migration, it does exactly what Google says it does and the move holds. Filed into a broken setup, it forwards a signal that has nowhere clean to land. The list below is the set of mistakes to recognise, framed as what done-wrong looks like, not as a reason to fear the tool.
The done-right move in the last card is the one this guide builds toward. A clean destination is sourced, not assumed. The SEO Domains marketplace screens its 220,000+ catalogue across backlink profile and authority metrics before listing, so the new domain you migrate to has been read before you point a single redirect at it, with entry-level aged domains from $100 and premium acquisitions above. Browse screened inventory on the SEO Domains marketplace when the move needs a destination that holds.
How long it takes, and how long to keep the redirects alive
The move processes per URL, so a small to medium-sized site takes roughly two to three weeks for the bulk of its pages to move and larger sites take longer, in Google’s own framing. The signal-forwarding window lasts 180 days. Google recommends keeping the 301 redirects in place for as long as possible, generally at least one year, and continuing to renew the old domain for at least a year.
Processing time vs the signal window
Two clocks run at once, and confusing them is a frequent error. The processing clock is how long Google takes to reprocess your URLs onto the new domain. Google states the move takes place on a per-URL basis, and as a general rule a small to medium-sized website can take two to three weeks for the bulk of its pages to move, with larger sites taking longer. The signal clock is the 180-day forwarding window, after which Google recognises no relationship between the two sites.
The practical reading is that processing finishes well inside the window for a typical site, but the redirects have to outlive both clocks. The depth on expected dip and recovery shape is in the hub’s Post-migration monitoring for 6 months guide.
| Clock | Duration (cited) | What it governs |
|---|---|---|
| Per-URL processing | Two to three weeks for a small-to-medium site; longer for large sites | How long Google takes to reprocess your pages onto the new domain. Source: Google Search Central. |
| Signal-forwarding window | 180 days from submission | How long Google forwards signals and shows the in-progress notice. Source: Google Search Console Help. |
| Redirect retention | At least 1 year, longer if traffic continues | How long the 301s must stay live. Source: Google Search Central and Search Console Help. |
| Old-domain renewal | At least 1 year | How long to keep paying for the old domain so it cannot be bought and abused. Source: Google Search Console Help. |
Monitor both properties, not just the new one
Through the move, watch the old and the new property side by side in Search Console. The old property shows pages draining out of the index and redirect coverage; the new property shows pages arriving and impressions building. A pattern where the old side empties but the new side does not fill is the signal that a redirect or a variant is broken. The same dual-property discipline applies to the redirect signal itself, covered in Monitoring 301 impact in GSC.
Status, cancellation, and a stuck move
While a move is active, every property moving from or to displays an in-progress notification in Search Console for the 180-day window, which is how you confirm the request registered. A move is reversible within 180 days: remove the old-to-new redirects, add new-to-old redirects, and click Cancel Move. A stuck move usually traces to a failed pre-check, an unverified variant, or a redirect that stopped resolving.
Confirming the status
After submission, the in-progress notification on both properties is the status indicator. If you own a destination that another party is moving onto, Search Console shows a note that other sites are moving to this site. The absence of that notification after a submission is itself a signal that the request did not register, which sends you back to the pre-checks.
Cancelling or reversing a move
A Change of Address is reversible inside the 180-day window, which matters if a migration goes wrong and you need to roll back to the old domain. Google’s reversal procedure is three moves: remove the 301 redirects from the old site to the new site, add 301 redirects from the new site back to the old site, then use Cancel Move in the Change of Address tool. The redirect reversal is what unwinds the move at the server level; the Cancel Move click tells Google to stop forwarding.
When a move looks stuck
A move that does not progress almost always has a mechanical cause instead of a Google delay. Re-check the redirect on the homepage and the canonicals for a clean single 301, confirm every subdomain variant was filed, confirm the new property is a verified Domain property, and read any warning the tool raised at submission. The diagnostic table in the next section consolidates these into one checklist.
| Symptom | Likely cause | The fix |
|---|---|---|
| Tool does not appear in the property | Property is URL-prefix or path-level, not a Domain property | Re-verify the new domain as a Domain property |
| Submission blocked at validation | Homepage redirect missing, a 302, or a redirect chain | Serve a single permanent 301 from old homepage to new homepage |
| New domain absent from the dropdown | New domain unverified or verified under a different account | Verify it under the same account that owns the old property |
| Half the site stays on the old domain | www or another subdomain was never filed | File a separate request for each subdomain variant |
| Old URLs still rank after the window | New domain has no equivalent page for them | Map and 301 those URLs to the closest new equivalent |
| Rankings drop and do not recover | Destination domain carries a manual action or toxic history | Screen the destination before migrating; clean or replace it |
Change of Address frequently asked questions
The five questions practitioners raise when filing a Change of Address, answered against Google’s own documentation and the failure patterns above.
Q1How long does the Change of Address tool take to work?
The move processes on a per-URL basis. Google states a small to medium-sized site takes two to three weeks for the bulk of its pages to move, with larger sites taking longer. Separately, the signal-forwarding window lasts 180 days from submission, after which Google recognises no relationship between the old and new sites.
Q2Do I need 301 redirects before using the tool?
Yes. Google requires a 301 redirect from the old homepage to the new homepage before you use the tool, and recommends 301 redirects for the canonical pages too. The tool validates the live redirect at submission, so a missing or temporary 302 redirect blocks or weakens the request.
Q3Can I use the tool to move from HTTP to HTTPS?
No. Google states that for a move from HTTP to HTTPS you do not need the Change of Address tool. That case is handled with 301 redirects and the standard URL-change guidance. The tool is for moving between different domains, where all protocols of the source are moved in one filing.
Q4Does the tool move my subdomains and the www version?
No. Google is explicit that the tool does not move any subdomains below the specified domain, including www. A site with www, a blog subdomain, or language subdomains needs the request filed separately for each variant. Protocols are moved together; subdomains are not.
Q5Can I cancel a Change of Address after submitting it?
Yes, within the 180-day window. Remove the 301 redirects from the old site to the new site, add 301 redirects from the new site back to the old site, then click Cancel Move in the tool. Reversing the redirects is what unwinds the move; the Cancel Move click stops Google forwarding the signal.
The variable behind a clean move: the new domain you migrate to
Every prerequisite, step, and timeline in this guide assumes one thing the tool cannot verify: that the new domain is clean. The Change of Address tool forwards signals onto the destination you give it, whether that destination is a vetted aged domain or one carrying a buried penalty. Screening the new domain before the move is the difference between a migration that holds and one that inherits a problem. SEO Domains operates the curated marketplace where that destination is screened first.
Why the destination decides the outcome
The tool checks your redirects and your verification. It does not check the history of the domain you are moving to. If that new domain previously hosted spam, sits under an unresolved manual action, or carries a toxic backlink profile, the move forwards your earned authority onto a compromised foundation, and the rankings you tried to protect land on tainted ground. This is the gate the tool trusts you to clear, and the one every other walkthrough leaves out.
Migrating to an aged domain instead of a fresh registration
When a rebrand or consolidation needs a new domain, a registered aged or expired domain with a clean, real history is the destination that holds up. The inherited authority of a well-chosen aged domain is a genuine asset, the kind of foundation the forwarded signals can build on instead of fight against. The decision criteria are set out in How to pick the new domain for migration, and the metrics that separate a clean name from a junk one in the Domain Authority & Metrics hub.
How to source a destination that holds up
A destination that survives a migration passes a profile check before you build the move on it. The signals that matter are documented across the authority-metrics hub:
- A clean backlink profile with real, editorially earned links and no toxic inheritance.
- A registration and use history with topical continuity, not a record of prior spam.
- No unresolved manual action and no pattern that a spam system would flag on arrival.
- Authority metrics read together, so an inflated single score cannot hide a weak profile.
A junk domain fails these and turns a clean migration into an inherited penalty. A vetted domain passes them, and the forwarded authority lands on a foundation that was an asset before you ever filed the request.
