Search Console Handover

Handover runs left to right; both properties stay verified until coverage on the new domain stabilises.

Executive Summary

Search Console handover transfers Google’s understanding of your site from the legacy domain to the new one during a domain change or site move. This playbook is run by SEO engineers and site architects in coordination with whoever controls DNS and hosting. The outcome: both properties verified, ownership cleanly delegated, the Change of Address signal accepted, sitemaps re-submitted, and index coverage confirmed migrating before legacy redirects are deprecated. Execute it in lockstep with the redirect and DNS cutover — a handover filed before redirects are live will be rejected.

Prerequisites

Owner-level access to the legacy Search Console property
DNS edit access on both domains (registrar dashboard or Cloudflare API token scoped to DNS)
Site-wide 301 redirects from legacy to new already deployed and verified
A complete crawl baseline and current index-coverage export for the legacy domain
Final XML sitemaps generated for the new domain, reachable over HTTPS
A list of all current owners/users to migrate and a rollback DNS snapshot

Step-by-Step Execution

1. Verify Both Domains as Properties

Establish a verified property for the new domain before any signal is filed, and keep the legacy property verified throughout. Prefer a domain property (covers every subdomain and protocol) authenticated by DNS TXT record over a URL-prefix property. Follow the exact methods in Property Verification Methods to choose the right verification token and property type for your setup.

2. Consolidate and Transfer Ownership

Migrate the human access layer so the new property is not stranded under a single login. Add all required owners and users with appropriate roles, and remove stale accounts left over from agencies or former staff. The exact role matrix, delegation order, and the question of when to keep both properties are covered in Ownership Transfer Protocols.

3. File the Change of Address

With redirects live and both properties verified, submit the Change of Address from the legacy property to the new one. This tells Google the move is permanent and accelerates the transfer of signals. The tool validates that a sampled set of legacy URLs 301-redirect to the new domain — if redirects are missing it will refuse, so confirm routing first using your URL Mapping & Redirect Architecture checks.

4. Re-submit Sitemaps for the New Domain

Submit the new domain’s XML sitemaps (or sitemap index) under the new property and keep the legacy sitemap reachable so Google can re-crawl and discover redirects. Use a clean ping/resubmit workflow rather than deleting old entries prematurely, as detailed in Sitemap Re-submission Strategies. A stale or 404ing sitemap slows discovery of the new URL set.

5. Monitor Index Coverage on Both Properties

Track deindexing of legacy URLs and indexing of new URLs in parallel. Compare the Pages (Index Coverage) report and use URL Inspection to confirm Google has fetched the canonical new URLs. The full monitoring cadence and the metrics that signal a healthy migration are in Index Coverage Handoff.

6. Decommission Legacy Signals on Confirmation

Only once coverage has migrated do you wind down. Keep 301s in place indefinitely for high-authority paths, retain the legacy property for at least 180 days, and align decommission timing with your Migration Rollback Playbooks so a reversal is still possible if coverage regresses.

Technical Configs

DNS TXT verification record via Cloudflare API — authenticate a domain property:

# Add the google-site-verification TXT token returned by Search Console
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"TXT","name":"@","content":"google-site-verification=AbCdEf123","ttl":300}'

Confirm the verification token has propagated with dig:

# Query the TXT record at an authoritative resolver before clicking Verify
dig +short TXT newdomain.example @1.1.1.1

HTML meta-tag fallback for a URL-prefix property (Nginx-served head):

# Inject the verification meta tag site-wide via sub_filter on the new origin
location / {
    sub_filter '</head>' '<meta name="google-site-verification" content="AbCdEf123"></head>';
    sub_filter_once on;
}

Verify the legacy sitemap still serves a 200 during the move:

# Google must reach the old sitemap to re-crawl and discover 301s
curl -sI https://legacy.example.com/sitemap.xml | grep -E 'HTTP/|Content-Type'

Validation & Rollback

Confirm every signal is accepted and propagating before deprecating any legacy infrastructure.

Pre-Launch Validation Checklist:

Both domains show “Ownership verified” in Search Console
dig +short TXT newdomain.example returns the exact verification token
A sample of 20 top legacy URLs returns 301 to the matching new URL via curl -sI
Change of Address submitted and not rejected for missing redirects
New-domain sitemap submitted with status “Success” and 0 errors
URL Inspection on 10 priority new URLs returns “URL is on Google” or “Crawled”

Common Pitfalls to Avoid:

Filing Change of Address before site-wide 301s are live, causing rejection
Verifying only a URL-prefix property and missing http/www variants
Deleting the legacy sitemap immediately, stalling redirect discovery
Removing the legacy property before coverage has migrated, losing diagnostic history
Using a 302 instead of 301 on legacy paths, blocking the address change

Rollback Protocol:

If new-domain indexed pages drop more than 25% week-over-week, pause decommissioning
Re-enable the legacy property and confirm it remains verified
Revert DNS to the pre-migration snapshot per DNS Rollback Procedures
Retract or do not re-file the Change of Address until redirects and coverage are stable
Re-submit the legacy sitemap to restore crawl of the original URL set

FAQ

Should I use a domain property or a URL-prefix property for the new site? Use a domain property verified by DNS TXT — it consolidates every subdomain and both http/https into one view, which is exactly what you want when traffic and crawl shift wholesale to a new host. Keep a URL-prefix property only if a tool you rely on cannot read domain-property data.

How long does the Change of Address take to process? Google typically begins transferring signals within days, but full index migration often takes several weeks to a few months depending on site size and crawl rate. Keep both properties verified and 301s live for at least 180 days regardless of how quickly the dashboard updates.

Do I need to keep the legacy Search Console property after the move? Yes. Retain it for at least 180 days so you can watch legacy URLs deindex, inspect any straggling crawl errors, and roll back diagnostics if coverage on the new domain regresses. Removing it early discards the only side-by-side record of the migration.

What happens if I file the Change of Address before redirects are live? The tool samples legacy URLs and checks they 301 to the new domain; with no redirects it returns a validation error and refuses to proceed. Deploy and verify site-wide 301s first, confirm them with curl -sI, then file the address change.

Can I re-submit sitemaps before verifying the new property? No. Sitemap submission happens inside a verified property, so verification is always the first step. Verify the new domain, then submit its sitemap and keep the legacy sitemap reachable for redirect discovery.

← Back to Home