Using the Change of Address Tool Correctly

Problem Statement

The Change of Address tool looks like a form and behaves like a test suite. It samples your legacy URLs, follows what they return, and refuses to accept the filing if the redirects are not what a site move should look like. Teams typically discover this at the worst moment — the cutover is done, traffic is falling, and the tool declines with a message that names one sample URL and no pattern. Understanding what it checks turns a blocking rejection into a five-minute fix. This page sits under Index Coverage Handoff.

What the Change of Address tool checks before accepting Four gates in sequence: both properties verified by the same account, the legacy home page redirecting, sampled URLs returning single-hop 301s, and the destination returning 200. Four Gates, All Must Pass Same owner both properties verified by you Home redirects legacy root to new 301, not 302 Sampled URLs single hop each the usual blocker Target is 200 not a soft 404 not a login wall The tool samples a handful of URLs — a rejection names one, but the fault is usually a rule. Fix the pattern, not the sample, or the next attempt fails on a different URL.
Every gate is checked live at the moment you press submit, against the site as it is serving right now.

When to Use This Approach

  • You are moving between domains or subdomains — the tool covers a host change, not a change of URL structure within one host.
  • Both the legacy and destination properties exist in Search Console and you can verify both.
  • The redirect map is live and has been validated end to end, not just spot-checked on the home page.
  • You want the legacy signals consolidated rather than waiting for the index to work it out from redirects alone.

What the Filing Is Worth, and What It Is Not

It is worth being precise about the value here, because both overestimating and underestimating it lead to bad decisions. The filing is an explicit statement that one host has moved to another. Without it, the same conclusion is reachable from the redirects alone — a crawler that requests thousands of legacy URLs and receives 301s to a consistent destination will work it out. The filing removes the ambiguity and the delay; it does not create a mapping that the redirects do not already express.

Underestimating it produces teams who skip the filing because “the redirects do the work anyway”. They are right about the mechanism and wrong about the timeline: the consolidation takes materially longer, and the legacy property’s impressions decline over months rather than weeks. On a site whose revenue depends on that traffic, the difference is measured in money.

Overestimating it is the more common error and the more damaging one. A filing does not move per-URL rankings, does not compensate for a redirect map that points the wrong pages at the wrong destinations, and does not survive the redirects being removed. Teams who treat it as the migration’s key step file it, see the acceptance message, and stop watching — which is exactly when the redirect regressions that need catching start appearing.

# The filing assumes all of this stays true for its whole 180-day window
curl -sI https://legacy.example/ | head -1                       # still 301
dig +short TXT legacy.example | grep -c google-site-verification # still verified
curl -sI https://legacy.example/sitemap.xml | head -1            # still 200

Treat the filing as one line in a runbook whose other lines keep it valid, and it does what it is designed to do.

Step-by-Step Instructions

1. Confirm the Tool Applies at All

The Change of Address handles a change of host. Restructuring paths on the same domain — /blog/2019/title becoming /articles/title — is not a site move and has no filing; those changes are communicated entirely by redirects and an updated sitemap.

2. Prove the Redirects Before You Open the Form

The tool does not tell you which rule is wrong, so test the patterns yourself first. Sample across every template rather than the home page alone.

# Follow each legacy URL and print the full hop chain and final status
while read -r u; do
  printf '%s\n' "$u"
  curl -sIL "$u" | awk '/^HTTP/{printf "   %s\n", $2} /^[Ll]ocation:/{printf "   -> %s", $2}'
done < legacy-sample.txt

A healthy line reads 301 then one 200. Two 301s in a row is a chain, and chains are the most common cause of rejection — flatten them using the approach in Flattening Multi-Hop Redirect Chains into Single Hops.

3. Make Sure You Are an Owner of Both Properties

The form is invisible to a full user. If you cannot see it, the problem is permissions rather than redirects — resolve it with the sequence in Transferring GSC Ownership Without Losing History.

4. File It, Then Leave Both Properties Alone

After acceptance the filing runs for roughly 180 days. During that window keep the legacy redirects live, keep the legacy property verified, and keep the legacy sitemap reachable. Removing any of the three mid-window cancels the benefit you filed for.

# Guard rail: fail a deploy that would break the legacy home-page redirect
STATUS=$(curl -s -o /dev/null -w '%{http_code}' -I https://legacy.example/)
[ "$STATUS" = "301" ] || { echo "legacy root no longer 301 — Change of Address at risk"; exit 1; }
Common rejection reasons and their fixes A matrix of four rejection causes — redirect chain, 302 instead of 301, destination soft 404, and not an owner — with the observable symptom and the fix for each. Why Filings Get Rejected CAUSE WHAT YOU SEE FIX Redirect chain two 301s in a row flatten the map Temporary redirect 302 or 307 returned switch to 301 Destination not OK soft 404 or login wall re-point the rule Form not visible no menu entry at all become an owner Three of the four are redirect faults you can reproduce with curl before filing.
Reproduce the check locally first — the tool's message names a URL, not the rule that produced it.

Worked Example

A B2B software vendor moved product.legacy-brand.example to example.com. The filing was rejected three times in one afternoon, each time naming a different URL.

Testing the sample by hand showed a consistent shape:

https://product.legacy-brand.example/pricing
   301  -> https://www.product.legacy-brand.example/pricing
   301  -> https://example.com/pricing
   200

The legacy host had a long-standing canonical-host rule adding www. before anything else ran, so every legacy URL took two hops. The site worked perfectly for visitors and failed the filing on every attempt.

The fix was to reorder the rules so the cross-domain redirect matched first, on both the apex and the www host, producing a single hop from either entry point. The filing was accepted on the next attempt, and the same reordering removed a hop for real visitors as a side benefit.

Verification

# 1. Every sampled legacy URL takes exactly one hop
while read -r u; do
  hops=$(curl -sIL "$u" | grep -c '^HTTP')
  [ "$hops" -le 2 ] || echo "CHAIN ($hops responses): $u"
done < legacy-sample.txt

# 2. Both hosts of the legacy domain behave the same way
for h in legacy.example www.legacy.example; do
  curl -sI "https://$h/pricing" | awk '/^HTTP|^[Ll]ocation/'
done

# 3. Destination returns a real page, not a soft 404
curl -s https://example.com/pricing | grep -ci 'page not found\|no longer available'   # expect 0

The second check is the one that catches the example above: teams test the canonical host, and the crawler tests whichever host the legacy links point at. Monitoring both hosts through the migration window is part of the rota described in Building a 72-Hour Migration Watch Rota.

What the filing does and does not do Two panels contrasting the effects of a Change of Address filing — signal consolidation and faster processing — against what it cannot do, such as replacing redirects or fixing content. Scope of the Filing It does signal the move explicitly speed up index migration run for about 180 days It does not replace your redirects move per-URL rankings work without both properties The redirects do the work; the filing tells the index to expect it.
A correct filing accelerates a correct migration — it does not substitute for one.

FAQ

Can I file a Change of Address for a path change on the same domain? No. The tool covers a change of host only. Restructuring paths within one domain is handled entirely by redirects, internal links and an updated sitemap, and there is no equivalent form to file.

How long does the filing stay in effect? Roughly 180 days from acceptance. Keep the redirects, the legacy property verification and the legacy sitemap in place for that whole window — the filing assumes all three remain true.

The tool says my redirects are wrong but the site works fine. What is it seeing? Almost always a chain: a canonical-host or trailing-slash rule running before the cross-domain rule, so each legacy URL takes two hops. Visitors never notice; the check does. Test with curl -sIL and count how many HTTP lines come back.

Do I need to keep the legacy site online? You need the legacy host to keep answering and redirecting. The origin can be a minimal redirect service rather than the full application, which is usually the cheapest way to hold the domain open for the required window.

Should I file before or after the DNS cutover? After, and only once the redirects are live and verified. Filing against a legacy host that is not yet redirecting fails the sampled-URL gate immediately, and repeated failed attempts add nothing but noise to the day.

Does a failed attempt count against me? No. There is no penalty and no limit worth worrying about; the check simply runs again. The reason to stop retrying is that each attempt samples a fresh set of URLs, so a rule-level fault will keep failing on different examples and you will learn nothing new from the fourth rejection that the first did not tell you.

What if only part of the site is moving? Then it is not a site move and the tool does not apply. Moving a section — a blog from a subdomain into a subfolder, say — is communicated by redirects, internal links and updated sitemaps alone. Filing a Change of Address for a partial move would assert something untrue about the rest of the host.

Can I file for a move between subdomains? Yes. blog.example.com to www.example.com is a host change and qualifies, provided both are verified properties and the redirects behave. What does not qualify is a change of path within one host, however large.

Do I need to keep the legacy property’s sitemap submitted during the window? It is not a formal requirement of the filing, but it is the fastest way to get the legacy URLs re-requested so their redirects are seen. Removing it does not invalidate the filing; it does slow down the outcome the filing exists to accelerate.

How do I know the filing is still active? The legacy property shows the filing and its remaining duration in its settings. Check it as part of the monitoring window rather than assuming — a filing can be cancelled by removing the redirects or losing verification on either property, and neither event announces itself.

Related

← Back to Index Coverage Handoff