Change of Address Tool
The Google Search Console Change of Address tool tells Google you moved to a new domain. What it does, its prerequisites, the 180-day window, and what it can't do.
The Change of Address tool in Google Search Console tells Google you moved your whole site to a new domain or subdomain. It's domain-level only — not for moving URLs within the same domain, not for HTTP-to-HTTPS, and not for switching www to non-www on the same domain. Prerequisites: own both old and new properties, have 301 redirects already in place, and use a property scoped to the whole domain (no path in the URL — a root-level URL-prefix property qualifies too; you don't need the separate DNS-verified Domain property type). For 180 days Google emphasizes crawling the new site, forwards signals, and prefers the new site's canonicals. The 301s do the real work; the tool just reinforces the signal. Keep redirects live for at least 180 days and longer while old URLs still get any traffic — separately, Google recommends keeping the old domain's registration active for about a year so nobody else can grab and reuse it.
Evidence for this claim Search Console's Change of Address tool signals a domain or subdomain move after redirects and verification are in place. Scope: Current Change of Address workflow and supported moves. Confidence: high · Verified: Google Search Console: Change of Address tool Evidence for this claim Google recommends server-side permanent redirects and keeping them in place generally for at least one year during a site move. Scope: Current Google site-move guidance. Confidence: high · Verified: Google Search Central: Site moves with URL changesTL;DR — The Change of Address tool in Google Search Console is how you tell Google you’ve moved your whole site to a new domain (like
oldbrand.comtonewbrand.com). It’s not for moving pages around inside the same domain, and it’s not for switching to HTTPS. The redirects you set up do the actual work of moving your rankings — this tool just helps Google get the message faster.
What the Change of Address tool is
When you move your site to a brand-new domain, you want Google to figure out that the old site and the new site are the same site, and to start showing the new URLs in search instead of the old ones. The Change of Address tool is the setting in Google Search Console that tells Google exactly that: I moved from here to here.
Google’s own description is simple — use it “when you move your website from one domain or subdomain to another.”
What it does NOT do
This is where most of the confusion lives, so let’s get it out of the way first:
- It’s not for moving URLs inside the same domain. If you’re just
reorganizing folders (say
/old-folder/to/new-folder/) on the same domain, this tool isn’t for that. - It’s not for HTTP-to-HTTPS. Google says you don’t need the Change of Address tool for that kind of move.
- It’s not for switching www to non-www (or back) on the same domain. That’s a same-domain change too, not a domain move.
- It doesn’t replace your redirects. The 301 redirects from your old pages to your new pages are the real migration work. This tool is a helper, not the main event.
What you need before you use it
Three things have to be true or the tool won’t let you proceed:
- You own both sites in Search Console. You must be an owner of both the old and the new property.
- Your redirects are already in place. Specifically, a 301 redirect from your old homepage to your new homepage (and ideally page-by-page redirects too).
- Your properties are scoped to the whole domain — no path in the URL. This trips up more people than anything else, and it’s not quite what most guides say it is — see the Advanced tab for the actual rule.
What happens after you submit
For 180 days, Google leans toward your new site: it emphasizes crawling and indexing the new domain, carries signals over from the old site, and starts preferring the new URLs in search. That’s a window, not a permanent switch — which is why you keep your redirects in place far longer than 180 days.
Want the full picture — the Domain-vs-URL-prefix property gotcha, how long to keep redirects, subdomains and www, and the Bing equivalent? Switch to the Advanced tab.
Evidence for this claim Search Console's Change of Address tool signals a domain or subdomain move after redirects and verification are in place. Scope: Current Change of Address workflow and supported moves. Confidence: high · Verified: Google Search Console: Change of Address tool Evidence for this claim Google recommends server-side permanent redirects and keeping them in place generally for at least one year during a site move. Scope: Current Google site-move guidance. Confidence: high · Verified: Google Search Central: Site moves with URL changesTL;DR — The Change of Address tool tells Google you moved your whole site to a new domain or subdomain. It’s domain-level only — not for moving URLs within the same domain, not for HTTP-to-HTTPS, and not for switching www to non-www on the same domain. Prerequisites: you own both old and new properties, permanent redirects are already in place, and both properties are scoped to the whole domain (no path — a root-level URL-prefix property qualifies, you don’t need a DNS-verified Domain property specifically). For 180 days Google emphasizes crawling the new site, forwards signals, and prefers the new site’s canonicals. The 301s do the real work; the tool reinforces the signal. Keep redirects live at least 180 days and longer while old URLs still get traffic; separately, keep the old domain’s registration active for about a year so nobody reuses it. It’s one input to a site migration, not a substitute for one.
What the tool actually does
Strip away the marketing and the Change of Address tool is a notification. Google spells out the mechanics: when you submit it, “it tells Google to emphasize crawling and indexing your new site over crawling your old site. It also forwards various signals from the old site to the new site, and tells Google to prefer the new site over the old when determining canonical pages.”
Three jobs, then: crawl the new place first, carry the old place’s signals across, and treat the new URLs as canonical. That’s it — Google doesn’t describe this as “transferring rankings,” and I’m not going to promise you a timeline either. It reinforces a move you’ve already built with proper redirects; the redirects are what does the actual moving.
The 301s do the work; the tool is a signal
This is the heart of it. John Mueller has said the change of address tool is “just one extra signal that we use with regards to migrations” and that “it’s not a requirement.” He’s also said that if you can’t get the tool to work, with the redirects set up properly “you should be set.” (Those came via a secondary write-up of a 2021 Google Q&A, so I’m paraphrasing the gist rather than treating them as gospel — but it matches everything Google’s own docs say.)
And the docs are emphatic that redirects are the real machinery. Google says to “keep the redirects for as long as possible, generally at least 1 year,” because that window “allows Google to transfer all signals to the new URLs, including recrawling and reassigning links.” They also reassure you that “301 and other permanent redirects don’t cause a loss in PageRank.” Read that next to the 180-day tool window and the priority is obvious: the redirects outlast the tool, and the redirects do the heavy lifting.
I run real migrations, and this is exactly how I treat it in practice — the Change of Address tool is one line on a much longer checklist, not the migration itself. A site migration is the project; this tool is one accelerant inside it.
Prerequisites — get these right or it fails
The tool runs a pre-submission check (ownership plus a look for redirects on a few sample pages) before it sends anything. To pass:
- Own both properties. “You must be an owner of both the old and new properties in Search Console.” Owner, not a delegated user.
- Redirects already live. “Implement a 301 redirect from your old homepage to your new homepage.” Ideally you’ve also mapped page-level 1:1 redirects (that’s the core of any migration), but the homepage redirect is the minimum the tool looks for.
- A property scoped to the whole domain. This is the gotcha, below — and it’s not quite what most write-ups (mine included, until this update) say it is.
The domain-level gotcha — it’s not a “Domain property” requirement
This is the number-one reason a submission won’t go through, and most write-ups
get the fix wrong. Google: “The Change of Address tool can be used only on
properties at the domain level.” What “domain level” means here is about the
shape of the URL, not a specific Search Console verification method: no path
segments. Google’s own examples of eligible properties are example.com,
https://example.com, and m.example.com. A property scoped to a path — “You
cannot move properties at the path level, such as http://example.com/petstore/” —
can’t be the source or target.
That means you do not need Search Console’s separate, DNS-verified Domain
property type to use this tool. A root-level URL-prefix property (verified
by HTML file, meta tag, or Google Analytics/Tag Manager) qualifies too, as long as
it points at the domain root and not a subfolder. If the tool won’t let you pick
your property, the actual blocker is almost always that you’ve only ever verified
a path-scoped URL-prefix property (something like https://example.com/blog/) —
add a root-level property, either type, for both the old and new sites and run the
tool against those.
Subdomains, www, and protocols
Two separate behaviors people conflate:
- Subdomains are NOT automatic. “The tool does not move any subdomains below the specified domain (including www).” So if your move involves www/non-www variants or subdomains, you submit a Change of Address for each. Google’s migration docs say it directly: when moving between domains, “make sure to submit Change of Address requests for all subdomains and the www and non-www variants of the old domain name.”
- Protocols ARE covered. Specifying the
httpproperty also moves thehttpsone — “if you specify http://example.com, it also moves https://example.com.” So you don’t submit twice for protocol; you do submit separately for each subdomain.
The 180-day window — and what happens after
“These actions continue for 180 days after you start migration in Search Console.” For that window Google emphasizes the new site, forwards signals, and prefers the new canonicals. The request is also cancelable within that window.
After 180 days the forwarding relationship lapses. If your old site is still live and crawlable at that point, Google can treat it as unrelated again — which is exactly why your redirects must outlive the tool. Keep them live for at least those 180 days, and longer than that for as long as the old URLs are still pulling any Google Search traffic.
That’s a different piece of advice from what Google says about the domain name itself, and it’s worth not confusing the two: separately, Google recommends keeping the registration of your old domain active for at least a year after the move, so nobody else can register the abandoned name and reuse whatever trust or links it built up (think spam or phishing riding on your old domain’s history). One is about how long you redirect; the other is about not letting the domain name lapse. They’re not the same clock.
When NOT to use it
- Moving URLs within the same domain — folder restructures on the same host. Not this tool.
- HTTP-to-HTTPS — Google explicitly says you don’t need it.
- Switching www to non-www (or back) on the same domain — same-domain variant swaps aren’t a domain move either; handle those with redirects and a canonical, not Change of Address.
- IP / server / CDN moves with no URL change — if your URLs don’t change, the tool doesn’t apply.
- Merging or splitting sites — the Change of Address tool is a 1:1 site move. Merging two domains into one, or splitting one into many, is not a “move” and not what the tool is for.
One documented exception worth knowing: your whole old domain can move into a
path on a different destination domain (say oldbrand.com folding into
newbrand.com/oldbrand/). The source still has to be domain-level, but the
destination is allowed to have a path.
Don’t forget Bing
Bing Webmaster Tools has its own equivalent, the Site Move tool, which serves the same purpose for Bing. Notably, Bing’s version supports both whole-site (domain) moves and directory/path-level moves, where Google’s is domain-level only. If you submit the move in Google, submit it in Bing too.
Where this fits
The Change of Address tool is one step in a site migration, not the whole thing. The 301 redirects, the 1:1 URL mapping, the pre-migration crawl baseline, and the post-launch monitoring are where a migration is won or lost. This tool just makes sure Google hears about the move clearly and quickly.
AI summary
A condensed take on the Advanced version:
- What it is: a Google Search Console setting that tells Google you moved your whole site to a new domain or subdomain.
- What it does: for 180 days, Google emphasizes crawling/indexing the new site, forwards signals from old to new, and prefers the new site’s URLs as canonical.
- The 301s do the real work. Per Mueller it’s “not a requirement”; the tool reinforces a move your redirects already carry out — it doesn’t promise a ranking timeline of its own.
- Prerequisites: own both old and new properties; 301 redirects already in place (old homepage → new homepage at minimum); both properties scoped to the whole domain (no path — a root-level URL-prefix property qualifies, not just Search Console’s Domain property type).
- The #1 failure: trying to use a path-scoped property, like a URL-prefix property pointed at a subfolder. Add any root-level property (Domain or URL-prefix) and re-run.
- Subdomains aren’t automatic (including www) — submit one per subdomain/variant; protocols are covered (http also moves https).
- Not for: same-domain URL restructures, HTTP→HTTPS, www↔non-www on the same domain, IP/CDN moves, or merging/splitting sites (it’s a 1:1 move).
- After 180 days the forwarding relationship lapses — keep redirects live at least 180 days and longer while old URLs still get traffic. Separately, keep the old domain’s registration active for about a year so it can’t be reused maliciously. Submit in Bing too via the Site Move tool.
Official documentation
Primary-source documentation from the search engines.
- Change of Address tool (Search Console Help) — what the tool does, the prerequisites, the 180-day window, and the property-type, subdomain, and protocol rules.
- Site move with URL changes (Search Central) — the full domain-migration playbook: submitting Change of Address for subdomains/variants, the HTTPS exemption, and keeping redirects ~1 year.
Bing / Microsoft
- Bing Webmaster Tools — home of the Site Move tool, Bing’s equivalent for notifying it of a domain or path-level move.
Quotes from the source
On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.
Google — what the tool is for and what it does
- “Use the Change of Address tool when you move your website from one domain or subdomain to another.” — Search Console Help. Jump to quote
- “It tells Google to emphasize crawling and indexing your new site over crawling your old site. It also forwards various signals from the old site to the new site, and tells Google to prefer the new site over the old when determining canonical pages.” — Search Console Help. Jump to quote
Google — prerequisites
- “You must be an owner of both the old and new properties in Search Console.” — Search Console Help. Jump to quote
- “Implement a 301 redirect from your old homepage to your new homepage.” — Search Console Help. Jump to quote
Google — duration, property type, subdomains
- “These actions continue for 180 days after you start migration in Search Console.” — Search Console Help. Jump to quote
- “The Change of Address tool can be used only on properties at the domain level.” — Search Console Help. Jump to quote
- “The tool does not move any subdomains below the specified domain (including www).” — Search Console Help. Jump to quote
Google — migration docs: redirects do the work
- “If you’re moving your site from one domain to another, make sure to submit Change of Address requests for all subdomains and the www and non-www variants of the old domain name.” — Search Central, Site move with URL changes. Jump to quote
- “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links.” — Search Central, Site move with URL changes. Jump to quote
Pre-submission prerequisites checklist
Run this before you open the Change of Address tool — it’s the same set of things the tool’s pre-submission check looks for, plus the property-type fix that trips most people up:
- You’re moving to a new domain or subdomain (not restructuring URLs on the same domain, not switching to HTTPS, and not swapping www for non-www on the same domain).
- Both the old and new sites are verified in Search Console, and you’re an owner of each (not a delegated user).
- Both properties are scoped to the whole domain — no path in the URL. A
DNS-verified Domain property or a root-level URL-prefix property both
qualify; a path-scoped property (like
example.com/blog/) doesn’t. - A 301 redirect is live from the old homepage to the new homepage.
- Page-level 1:1 redirects are mapped and live for the rest of the site (the core of the migration itself).
- New pages canonicalize to themselves (not back to the old URLs).
- You’ve planned to keep redirects live for at least 180 days, longer while old URLs still get any Google Search traffic — and, separately, to keep the old domain’s registration active for at least a year.
- You’ll submit a separate Change of Address for each subdomain and the www / non-www variant.
- You’ll also submit the move in Bing Webmaster Tools (Site Move tool).
The mental models
1. The tool is a signal; the redirects are the machinery. A migration succeeds or fails on 301s and 1:1 URL mapping. The Change of Address tool only emphasizes crawling the new site, forwards signals, and sets new canonicals. Build the redirects first; the tool just announces the move.
2. The “is this even the right tool?” test. Ask what changed:
- New domain or subdomain? → Change of Address tool applies.
- Same domain, different URLs/folders? → not this tool.
- HTTP → HTTPS? → you don’t need it.
- Same domain, www ↔ non-www? → not this tool.
- IP / server / CDN, URLs unchanged? → doesn’t apply.
- Merging or splitting sites? → not a 1:1 move; not this tool.
3. Two clocks, plus a third one people forget. The tool’s forwarding lasts 180 days — keep redirects live at least that long, longer while old URLs still get traffic. Separately, keep the old domain’s registration active for about a year so nobody grabs it and reuses its trust. Different clocks, different reasons: one’s about signal transfer, the other’s about not losing the domain name.
4. Domain-level, not “Domain property.” If the tool won’t accept your property, it’s almost always because you verified a path-scoped URL-prefix property. The fix is any property scoped to the whole domain — a DNS-verified Domain property or a root-level URL-prefix property both work.
Change of Address — cheat sheet
Use it / don’t use it
| Scenario | Change of Address tool? |
|---|---|
Move to a new domain (old.com → new.com) | Yes |
| Move to a new subdomain | Yes (one per subdomain) |
| Restructure URLs on the same domain | No |
| HTTP → HTTPS | No |
| www ↔ non-www on the same domain | No |
| IP / server / CDN move, URLs unchanged | No |
| Merge two sites into one / split one into many | No (it’s 1:1) |
| Whole domain moving into a path on another domain | Yes (source is still |
| domain-level; destination may have a path) |
Fast facts
- Duration: Google emphasizes the new site, forwards signals, and prefers new canonicals for 180 days; the request is cancelable within that window.
- Property scope: no path in the URL. A Domain property AND a root-level URL-prefix property both qualify — path-scoped properties are the #1 rejection reason.
- Subdomains: not automatic (including www) — submit one each.
- Protocols: covered — specifying
http://also moveshttps://. - Redirects: keep them live ≥ 180 days, longer while old URLs still get traffic (301s don’t lose PageRank). Separately, keep the old domain’s registration ≥ 1 year so it can’t be reused maliciously.
- Bing: use the Site Move tool in Bing Webmaster Tools (supports domain and path-level moves).
Patrick's relevant free tools
- Google Index Checker — Check one URL’s observable indexability blockers, or reconcile sitemap, crawl, and supplied Search Console evidence across a URL set before verifying Google’s actual state in URL Inspection.
- HTTP Status & Redirect Checker — Paste up to 500 URLs — status codes, full redirect chains, final destinations, per-hop and total latency, response-header evidence, canonical checks, and redirect-system clues. Filter, compare snapshots, and export CSV. No signup, nothing stored.
- Google Search Console Hidden Query Estimator — Upload a Search Console performance export plus an Ahrefs or Semrush keyword export, and see which queries plausibly explain the clicks and impressions GSC hides below its privacy threshold — per-page confidence-tiered estimates, CSV export. Runs entirely in your browser.
Tools for a domain move
- Google Search Console — Change of Address tool — the setting itself, under Settings on the old property. Requires both properties to be scoped to the whole domain (a Domain property or a root-level URL-prefix property both work).
- Bing Webmaster Tools — Site Move tool — Bing’s equivalent; do the move in both consoles.
- GSC URL Inspection — confirm the new URLs are being crawled, rendered, and indexed after the move.
- A crawler / site audit (Ahrefs Site Audit, Screaming Frog) — build the pre-migration URL inventory, verify your 1:1 301 redirects resolve in a single hop, and catch redirect chains and broken targets.
- Server logs — the ground truth for whether Googlebot is actually shifting its crawl to the new domain.
Test yourself: the Change of Address tool
Should I use Change of Address?
Choose the notification path for a site change
Change of Address mistakes that derail migrations
Submitting before redirects are ready. The request announces a move; it does not create one. Deploy and test one-to-one permanent redirects first.
Redirecting every old URL to the new homepage. That destroys page-level equivalence and gives users and crawlers the wrong destination. Map each valuable old URL to its closest new counterpart; retire unmatched content deliberately.
Using a path-scoped property. The tool requires a property scoped to the whole domain — no path in the URL. A root-level URL-prefix property works fine; you don’t need a DNS-verified Domain property specifically. Verify a domain-level property (either type) instead of repeatedly retrying an ineligible path-scoped source or destination.
Submitting only the apex and assuming www or other subdomains follow. They do
not. Inventory host variants and submit a separate request for each relevant move.
Removing redirects after 180 days. That confuses the tool’s active window with your redirect timeline. Keep permanent redirects live at least 180 days, longer while old URLs still receive visits or links.
Letting the old domain’s registration lapse. Google recommends keeping it active for at least a year after the move so nobody else can register the abandoned domain and reuse whatever trust or links it built up.
Using the tool for a same-domain restructure or HTTPS change. Those migrations have different signals and do not need Change of Address. Applying the wrong tool does not make a weak redirect plan stronger.
Change of Address troubleshooting
The old or new property isn’t available in the selector
Likely cause: it’s scoped to a path (a URL-prefix property pointed at a subfolder), or your account is not an owner. Fix: verify a property scoped to the whole domain — a DNS-verified Domain property or a root-level URL-prefix property both work — for both sites, then confirm owner access before reopening the tool.
The pre-submission check says redirects are missing
Likely cause: the old homepage does not return a direct permanent redirect to the new homepage, the redirect is conditional, or an intermediate hop fails. Fix: test the old homepage as an unauthenticated request, follow the chain, and make it one permanent hop to a successful new homepage. Then sample page-level mappings too.
The request succeeded, but old URLs still appear in search
Likely cause: Google has not recrawled everything yet, redirects are inconsistent, or the new pages canonicalize back to the old domain. Fix: inspect representative old and new pairs, verify the redirect and self-canonical, submit the new sitemap, and watch crawling/indexing over time. A request is not an instant SERP replacement.
Some subdomains did not move
Likely cause: only the parent domain’s request was submitted. Fix: verify each
affected source and destination subdomain and submit its own request, including the
relevant www variant.
Traffic fell after the move
Likely cause: the problem is usually in migration execution—missing URL mappings, redirect chains, blocked resources, wrong canonicals, internal links still pointing old, or missing content—not the notification itself. Fix: compare the pre-launch URL inventory with live redirects, status codes, canonicals, indexability, sitemaps, and logs before canceling or resubmitting the request.
Prove the domain move is working
Run these tests after launch and keep a dated sample so regressions are visible:
| Test | How to verify | Pass signal |
|---|---|---|
| Old URL response | Request a sample from every old template without cookies | One permanent redirect hop to the mapped new URL |
| New URL response | Request each destination directly | Successful, indexable response with no redirect loop |
| Canonical | Inspect the rendered destination <head> | Self-referencing canonical on the new domain |
| Property eligibility | Open both properties in Search Console | Domain-level property (Domain type or root-level URL-prefix), owner access, correct source and destination |
| Host coverage | Inventory apex, www, and other moved subdomains | A request exists for every relevant one-to-one host move |
| Internal links | Crawl the new site | Navigational and contextual links resolve directly to new URLs |
| Sitemap | Fetch and validate the submitted sitemap | Canonical new-domain URLs only; successful responses |
| Google recrawl | Inspect representative old/new pairs and review logs | Googlebot revisits old URLs, follows redirects, and crawls destinations |
| Index transition | Check representative queries and URL Inspection over time | New URLs become selected while old URLs decline |
| Bing notification | Review Bing Webmaster Tools | Corresponding Site Move submitted and destinations discoverable |
A passing Change of Address screen proves the notification was accepted. These tests prove the migration machinery around it actually works.
Resources worth your time
My related writing
- A Website Migration Takes More Than A Checklist To Be Successful — my full take on running a domain migration, where the Change of Address tool and 301s fit the bigger plan.
- Is It OK to Remove 301 Redirects After a Year? We Tested It — first-party experiment data behind the “keep redirects long-term” point.
Official
- Change of Address tool (Search Console Help) — the authoritative source for the tool’s behavior and prerequisites.
- Site move with URL changes (Search Central) — the broader migration documentation.
From others
- r/TechSEO — the community where migration and Change-of-Address edge cases get debugged.
- Change of Address tool is “just one extra signal” — iloveseo.com — secondary write-up of John Mueller’s 2021 Google Q&A where he calls the tool optional and says proper 301s are sufficient on their own.
- Site Migrations category — Search Engine Journal — industry coverage of domain moves, redirect strategies, and common migration pitfalls.
- Site Migrations — Search Engine Land — practitioner articles on domain migrations, including when and how to use GSC tools.
- Search Engine Roundtable — site migration tag — news coverage of Google announcements and Webmaster Hangout discussions touching migrations and the COA tool.
Change of Address tool
A setting in Google Search Console that tells Google you've moved your whole site to a new domain or subdomain. It's a supporting signal for a domain migration — the 301 redirects do the real work of transferring rankings.
Related: Google Search Console, Site Migration
Change of Address tool
The Change of Address tool is a setting in Google Search Console used when you move your entire site from one domain or subdomain to another — for example, oldbrand.com to newbrand.com. It is not for restructuring URLs within the same domain, and it is not for HTTP-to-HTTPS moves.
Google describes what it does plainly: it emphasizes crawling and indexing the new site over the old one, forwards various signals from the old site to the new site, and tells Google to prefer the new site when determining canonical pages. Those actions continue for 180 days after you start the migration in Search Console.
The prerequisites are strict. You must be an owner of both the old and new properties in Search Console, you need 301 redirects from the old site to the new one already in place, and the tool only works on Domain-level properties — a URL-prefix property scoped to a path can’t be used. The tool can be used only on properties at the domain level; it does not move subdomains (including www), so each variant needs its own request.
The redirects do the heavy lifting of transferring rankings and link equity; the tool just accelerates and reinforces the message. It is one input to a larger site migration, not a substitute for one.
Related: Google Search Console, Site Migration
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Corrected the property-type requirement (root-level URL-prefix properties qualify, not just Search Console's Domain property type), separated redirect duration from old-domain-registration retention, added the www/non-www exclusion, and toned down unsupported ranking-transfer language.
Change details
-
The tool's domain-level requirement is about the property having no path in the URL, not Search Console's specific DNS-verified Domain property type — a root-level URL-prefix property qualifies too. Fixed across the beginner, advanced, checklists, frameworks, cheat-sheets, tools, quiz, decision-trees, anti-patterns, troubleshooting, and validation-tests lenses.
-
Separated two distinct duration facts that were previously collapsed into one: keep redirects live at least 180 days (longer while old URLs still get traffic), and separately keep the old domain's registration active for about a year to prevent malicious reuse.
-
Added switching www to non-www (or back) on the same domain to the excluded-use-cases list, and noted the documented exception where a whole domain can move into a path on a different destination domain.
-
Rewrote quiz question 2 to test the corrected property-scope fact instead of the inaccurate URL-prefix-is-disqualifying framing.
Full comparison unavailable — no prior snapshot was archived for this revision.
Was this helpful?
People also ask
Keep the conversation going
Ask a question here or ask other technical SEOs
My notes
Glossary: Change of Address tool