Ownership Transfer Protocols

Context

A migration often coincides with a change of agency, team, or registrar, and the Search Console access layer is where that bites: the only verified owner is a former contractor, or the new domain is stranded under one personal Google account. This page solves the human-access problem that sits between verification and the index handoff in the broader Search Console Handover — who owns the property, who can act on it, and how the Change of Address is filed. SEO leads and site architects run this in the cutover window, immediately after both properties are verified.

It also covers the strategic call of when to keep both properties live rather than collapsing to one, because the legacy property remains your best diagnostic surface for weeks after launch.

Grant the minimum tier each person needs and keep two durable verified owners on the new property.

Pre-flight Checks

Owner-level access (not merely “full user”) on both the legacy and new properties
Both properties already verified per Property Verification Methods
A roster of every current owner and user, flagged keep / remove
Site-wide 301 redirects deployed and confirmed, a hard dependency for Change of Address
The new domain’s canonical hostname agreed (bare vs www) to avoid filing the wrong target

Execution Steps

1. Audit Existing Owners and Users

List every verified owner, delegated owner, full user, and restricted user on both properties. Flag stale agency and ex-staff accounts for removal and identify at least two durable owners — ideally role accounts, not individuals — so access cannot be lost when one person leaves. Do this before adding anyone new so you transfer into a clean state.

2. Add New Owners and Delegate Permissions

Add the migration team with the correct roles: verified owners hold a verification token of their own, delegated owners are granted by an existing owner, full users see all data and most settings, and restricted users get read-mostly access. Grant the minimum role each person needs. The new property’s owner set should mirror the legacy one so reporting continuity survives into Index Coverage Handoff.

3. File the Change of Address

From the legacy property, open the Change of Address tool and select the verified new property as the destination. The tool validates that sampled legacy URLs 301-redirect to the new domain, so confirm routing with your URL Mapping & Redirect Architecture checks first. A clean submission migrates signals far faster than relying on redirects and crawl alone.

4. Decide Whether to Keep Both Properties

Keep both. The legacy property is where you watch old URLs deindex and catch crawl errors that never surface on the new property. Retain it verified for at least 180 days; only remove a property once its URLs no longer appear in the index and you have exported its history. Collapsing too early destroys the side-by-side record you need if a rollback is called.

5. Remove Stale Access Last

Once new owners are confirmed active and the Change of Address is accepted, remove the flagged stale accounts. Removing access before the new owners are verified can lock you out of a property entirely, so this is always the final step.

Configs / Commands

Snapshot current users via the Search Console API (sitemaps/permissions audit pattern):

# List verified sites the authenticated token can administer
curl -s -H "Authorization: Bearer $GSC_OAUTH_TOKEN" \
  "https://www.googleapis.com/webmasters/v3/sites"

Confirm the redirect the Change of Address tool will sample:

# Must return 301 with a Location on the new domain, not 302 or 200
curl -sI https://legacy.example.com/top-page | grep -E 'HTTP/|location'

Batch-test a redirect sample before filing (multi-URL loop):

# Feed top legacy paths; any non-301 line is a Change of Address blocker
while read -r p; do
  printf '%s -> ' "$p"; curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "https://legacy.example.com$p"
done < top-paths.txt

Validation

Both properties list the intended owners; no ex-agency or ex-staff accounts remain
At least two durable owners exist on the new property
Change of Address shows status “Processing” or “Completed”, not “Failed — redirects missing”
curl -sI on the sampled legacy URLs returns 301 to the matching new URL
The legacy property remains verified and accessible after access cleanup

Rollback Triggers

Change of Address returns “Failed” → redirect coverage is incomplete; fix routing and re-file
Indexed pages on the new domain fall more than 25% week-over-week → halt removal of the legacy property
Loss of all owner access on either property → re-verify immediately via Property Verification Methods
A wrong canonical target was filed (www vs bare) → cancel the address change and re-file with the correct property

FAQ

What is the difference between a verified owner and a delegated owner? A verified owner holds an independent verification token and cannot be removed by other owners; a delegated owner is granted by an existing owner and loses access if that grantor’s verification lapses. Keep at least two verified owners so access is durable.

Do I have to remove the old property after the Change of Address? No, and you should not for at least 180 days. The legacy property is your window into old URLs deindexing and any lingering crawl errors. Keep it verified until its URLs leave the index and you have exported its diagnostic history.

Can I file a Change of Address without site-wide redirects? No. The tool samples legacy URLs and requires they 301 to the new domain; without redirects it returns a validation failure. Deploy and confirm redirects, then file.

What if the only owner left the company? If you still have any owner or full-user access, add new owners immediately. If all access is lost, re-verify the property from scratch using a method you control, such as a DNS TXT record, to regain ownership.

← Back to Search Console Handover