Index Coverage Handoff

Context

After verification, ownership, and the Change of Address are done, the migration is not finished — it is in flight. Google now has to deindex the legacy domain and index the new one, and the index coverage handoff is how you watch that happen and prove it succeeded. This page sits at the monitoring end of the Search Console Handover: reading the Pages (Index Coverage) report, inspecting individual URLs, and comparing old-versus-new indexing so you know whether to hold, push, or roll back. SEO engineers run this daily for the first two weeks and weekly thereafter until coverage stabilises.

The core risk is silent: redirects can be live and sitemaps submitted while Google quietly fails to index the new URLs because of canonical conflicts, soft 404s, or blocked crawling. The Pages report is where those failures show up first.

Map each "Not indexed" reason to its root cause and fix it at source rather than waiting.

Pre-flight Checks

A pre-migration index-coverage export from the legacy property as a baseline
Both properties verified and the Change of Address accepted
New-domain sitemap submitted per Sitemap Re-submission Strategies
robots.txt on the new domain confirmed not blocking crawl of priority paths
A priority URL list (top traffic and revenue pages) to inspect individually

Execution Steps

1. Capture the Legacy Coverage Baseline

Export “Indexed” and “Not indexed” counts and the reason breakdown from the legacy Pages report before the move accelerates. This baseline is what you measure migration health against — without it, a drop on the new domain is impossible to interpret. Store it alongside your crawl baseline in the migration runbook.

2. Monitor the New Property’s Pages Report

Watch the new domain’s Indexed count climb and scan the “Not indexed” reasons for migration-specific failures: “Page with redirect”, “Duplicate without user-selected canonical”, “Crawled — currently not indexed”, and “Discovered — currently not indexed”. The detailed cadence, thresholds, and triage order are in monitoring index coverage after a site move.

3. Inspect Priority URLs Individually

Run URL Inspection on each top page to confirm Google sees the new URL as canonical and indexable. Check that the inspected canonical matches the new URL, the page returns 200, and coverage reads “URL is on Google”. Use “Request indexing” sparingly for the handful of highest-value pages to nudge crawl.

4. Compare Old vs New in Parallel

Track the legacy Indexed count falling as the new count rises — a healthy move shows an inverse curve. If legacy URLs stay indexed long after redirects went live, Google has not re-crawled them yet; if new URLs lag, check sitemaps and canonicals. Tie any sustained divergence to the thresholds in Migration Rollback Playbooks.

5. Resolve Coverage Errors at Source

Treat each “Not indexed” reason as a fault to fix, not a status to wait out. Redirect-flagged new URLs usually mean an internal link or canonical still points at the legacy domain; duplicate-canonical errors mean conflicting rel=canonical tags. Fix the markup or routing, then validate the fix in the report.

Configs / Commands

Confirm a new URL is crawlable and canonical before requesting indexing:

# Expect HTTP 200 and a self-referencing canonical on the new domain
curl -s https://newdomain.example/key-page | grep -i 'rel="canonical"'

Verify the new domain is not blocking Googlebot:

# robots.txt must allow priority paths; an accidental Disallow stalls indexing
curl -s https://newdomain.example/robots.txt

Check legacy URLs return a redirect Google can follow during deindexing:

# A 301 to the new canonical is what drives deindex of the old URL
curl -sI https://legacy.example.com/key-page | grep -E 'HTTP/|location'

Validation

New-domain “Indexed” count trends upward week-over-week toward the legacy baseline
Legacy “Indexed” count declines as redirects are crawled
URL Inspection on priority pages reports “URL is on Google” with the new URL as canonical
“Not indexed” reasons trend down, not up, after fixes are validated
No spike in “Server error (5xx)” or “Blocked by robots.txt” on the new property

Rollback Triggers

New-domain indexed pages fall or stall below 75% of the legacy baseline two weeks after the Change of Address → escalate
A sustained spike in “Server error (5xx)” on the new domain → investigate origin/CDN before continuing
Priority URLs show “Duplicate, Google chose different canonical” pointing at the legacy domain → fix canonicals immediately
Organic clicks on the new property drop more than 25% week-over-week → trigger the Migration Rollback Playbooks

FAQ

How long until the new domain is fully indexed after a move? Expect several weeks to a few months depending on site size and crawl rate. Large sites migrate in waves; watch the inverse curve of legacy down / new up rather than waiting for a single completion moment.

Why are my new URLs showing as “Crawled — currently not indexed”? Google fetched the page but chose not to index it yet, often due to thin content, canonical conflicts, or a slow re-evaluation after the move. Confirm the canonical is self-referencing and the content matches the legacy page, then give crawl time before re-requesting.

Should I request indexing for every migrated URL? No. Reserve manual “Request indexing” for a small set of the highest-value pages. For bulk discovery, rely on a correctly submitted sitemap and the natural recrawl driven by your 301s.

What does “Page with redirect” mean on the new property? A URL on the new domain is itself redirecting, usually because an internal link or canonical still references an old path. Fix the link or canonical so the new URL resolves to a 200 and is eligible for indexing.

← Back to Search Console Handover