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.

The handover exists because a domain change splits your search-engine relationship in two. The legacy property holds all the history — impressions, queries, coverage state, manual actions if any — and the new one starts empty. Nothing transfers automatically, and several of the steps below have a strict order: filing a Change of Address before both properties are verified simply fails, and re-submitting sitemaps before the redirects are live tells the crawler to fetch URLs that are not yet reachable.

The other reason to treat this as its own phase is that it is the only part of a migration with an external dependency you cannot schedule. Everything else in the playbook completes when you run the command; index migration completes when search engines get round to re-crawling, which for a large estate takes weeks and is not something any tool accelerates meaningfully. Planning for that means resisting two temptations — retiring the legacy domain early because the technical work looks finished, and interpreting the inevitable interim dip as a defect.

One more framing worth stating before the prerequisites. Almost every other phase of a migration is verified by observation — you change something, you measure, you know. This phase is verified by inference over weeks, from a report that is sampled, delayed, and produced by a system you do not control. That changes how you should read it: single-day movements mean very little, the direction of a fortnight’s trend means a great deal, and the exclusion reasons carry far more information than the totals. Teams that treat coverage data with the same immediacy as an error-rate dashboard reliably talk themselves into interventions that make things worse.

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

Do this first and well ahead of the window — verification is the one step with an external dependency that can take days to resolve if the credentials or DNS access turn out not to be where you assumed. 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.

Choose the property type deliberately, because it determines what you can verify and what you can see. A domain property covers every subdomain and both protocols under one entry and can only be verified by DNS; a URL-prefix property covers exactly one scheme-and-host combination and accepts several verification methods. For a migration the domain property is almost always right — it removes the class of problem where https://www. is verified and https:// is not, and it means a later subdomain change needs no new verification.

Verify the legacy domain as well, and do it before you need it. Teams routinely find that the legacy property was verified years ago by someone who has left, via an HTML file that no longer exists on the current build or a meta tag stripped by a subsequent redesign — so the property still shows as verified until the moment the verification is re-checked, at which point access is lost. Re-verify both domains through a method you control now, while there is time to fix it, rather than discovering the problem when you try to file a Change of Address.

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.

Treat the ownership audit as a security exercise as much as a migration one. Search Console access accumulates: agencies from previous engagements, contractors, a developer’s personal account added for a debugging session years ago. Each of those can read every query the site ranks for, and an owner can add further owners or remove yours. Snapshot the current list, confirm each entry against someone who can vouch for it, and remove the rest — but remove them last, after the new access is confirmed working, so a mistake does not lock the team out entirely.

Delegate at the right level. An owner can change verification and manage other users; a full user can see everything and act on most of it without that risk. Most people who need Search Console during a migration need full-user access, not ownership, and keeping the owner list to two or three named people makes the eventual cleanup tractable.

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.

The Change of Address tool samples your redirects before accepting the filing, which is why it fails for reasons that look unrelated to the form. The sample checks that the legacy home page and a set of representative paths return a 301 to the corresponding new URL — so a 302, a redirect to the new home page rather than the equivalent page, or a redirect chain will all cause a rejection. Test the sample yourself with curl before filing, using the legacy paths with the most inbound links, because those are what the tool is most likely to pick.

Filing it is worth the effort even though the redirects do most of the work. The tool is an explicit signal that a whole-site move is intentional rather than a mass duplication event, and it noticeably shortens the crossover. What it does not do is replace anything: the redirects, the canonicals, and the sitemaps all still have to be right, and a filed Change of Address on top of a broken redirect map simply propagates the breakage faster.

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.

Regenerate the sitemaps from the new site rather than rewriting the old ones. A find-and-replace across the legacy XML preserves every URL that should no longer exist, including the ones you deliberately retired, and submitting that list invites the crawler to spend its budget confirming a few thousand 410s. Generate afresh from the new estate, then diff the result against the value-tiered inventory to confirm the top tiers are all present — a sitemap missing your highest-value section is a common and entirely silent defect.

Keep sitemaps under the format limits and split by section rather than arbitrarily. Fifty thousand URLs or fifty megabytes uncompressed per file is the ceiling, and an index file referencing per-section sitemaps is easier to reason about than numbered shards, because the coverage report then attributes problems to a section you recognise. That attribution is the practical benefit: “the products sitemap has 12% unindexed” is actionable in a way that “sitemap-7 has 12% unindexed” is not.

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.

Keep the legacy sitemap live and submitted throughout the move, which is the opposite of most people’s instinct. Its job during the transition is to keep the crawler returning to legacy URLs so it discovers the 301s and processes the deindexing — remove it and those URLs are re-crawled only when the crawler happens to get to them, which for a deep archive can be months. Retire it only once the legacy property’s coverage report shows the URLs have actually moved.

Watch the new property’s Pages report for the specific exclusion reasons rather than the headline count. “Discovered — currently not indexed” at scale usually means crawl budget, and resolves with time; “Duplicate, Google chose a different canonical” means your canonicals are pointing somewhere unintended and will not resolve with time at all; “Excluded by robots.txt” means a directive inherited from the new build. Each has a different remedy, and the aggregate indexed number tells you none of them.

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.

Laid out in sequence, the six steps have a dependency structure worth internalising, because three of them fail silently if run out of order rather than returning an error.

Step 6 is the only irreversible one, which is why it is gated on evidence from step 5 rather than on the technical work looking complete.

Technical Configs

Adapt the placeholders to your own provider and zone; the sequencing, not the syntax, is what carries across.

The fragments below cover the two things this phase actually manipulates: proving to the search engine that you control both domains, and proving that the legacy estate now points at the new one. Everything else in the handover happens through the Search Console interface, which is why the configuration surface here is small and the sequencing discipline matters more than the syntax.

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'

The most useful mental model for what follows is a crossover: legacy URLs falling out of the index while new ones enter it, on overlapping curves that take weeks to complete. Watching both properties at once is what distinguishes a healthy migration from a stalled one, because either curve alone is ambiguous.

The gap between the crossover and the decommissioning line is deliberate: the legacy 301s are what drive the remaining deindexing, so they must outlive the crossover by weeks.

One frequently-missed configuration item: the verification token must survive the deploy. A meta tag injected by a template, an HTML file sitting in the document root, or a header added by a server block can all be removed by a subsequent build without anybody noticing — and the property silently unverifies some time later, taking your access and any pending Change of Address with it. This is the strongest practical argument for DNS verification even on URL-prefix properties, since a TXT record lives outside the application’s release cycle entirely.

Validation & Rollback

Unlike the infrastructure phases, most of what follows cannot be confirmed on the night — it is confirmed over the following weeks, which is why the rollback criteria here are expressed as trends rather than as instantaneous thresholds. 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

Set expectations about duration before launch rather than during the dip. A small site can complete the crossover in two to three weeks; a large estate with a deep archive routinely takes two to three months, and the tail — the last few per cent of low-value URLs — can run longer still without indicating anything wrong. Communicating that range in advance converts the inevitable week-three question from an alarm into a status check, and it removes the pressure to take corrective action against a process that is simply not finished.

Finally, resist the urge to intervene aggressively during the crossover. Requesting indexing for individual URLs is useful for a handful of critical pages and useless at scale; repeatedly re-submitting sitemaps changes nothing; and removing the legacy property to “force” the transition actively harms it. The interventions that do help are the unglamorous ones — fixing a canonical that points at the legacy domain, removing an inherited robots.txt rule, flattening a redirect chain the crawler is giving up on — and all of them come from reading the specific exclusion reasons rather than watching the total.

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.

What happens to historical performance data on the legacy property? It stays on the legacy property and does not move. Search Console retains roughly sixteen months of query and impression data per property, and the Change of Address tool does not migrate any of it — the new property’s history begins on the day it was verified. If your reporting depends on year-on-year comparison, export the legacy performance data before the retention window rolls past the migration date, because once it expires there is no way to recover it. A bulk export via the API is a half-hour job before the move and impossible afterwards.

Should the legacy property be deleted once the crossover is complete? No — leave it verified indefinitely, or at least for a year. It costs nothing, and it remains the only place you can see whether legacy URLs are still being requested, whether the old domain has picked up spam links, or whether a manual action has been applied to it. Deleting the property also removes your ability to re-file or amend the Change of Address if something surfaces later. The thing to decommission is the legacy sitemap and eventually the legacy content, not the property record.

Does any of this apply if only the URL structure changes, not the domain? Partly. Verification and ownership are unaffected, and there is no Change of Address to file — that tool exists specifically for host changes and cannot be used for a path restructure. What does still apply is sitemap re-submission and the coverage monitoring, which behave exactly as described: old URLs deindex as their redirects are processed and new ones enter the index on the same overlapping curves. The crossover is usually faster because the host’s existing crawl relationship carries over, but the shape is the same and so is the discipline of watching both sides of it.

How do I tell a crawl-budget problem from a quality problem? By which exclusion reason dominates. Large numbers of URLs sitting at “Discovered — currently not indexed” indicate the crawler knows about them and has not got to them, which is a budget and priority question — improve internal linking to the affected section, make sure they are in a submitted sitemap, and be patient. URLs at “Crawled — currently not indexed” have been fetched and judged not worth including, which is a content or duplication question and will not improve with time or with re-submission. The two look identical in the headline count and need opposite responses.

← Back to Home