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.

Not-indexed reason triage Three common not-indexed reasons after a move, each mapped to the root cause and the fix. Triaging "Not Indexed" Reasons Page with redirect Duplicate canonical Crawled, not indexed Fix internal link Self-reference canonical Match content + wait Each reason is a fault to fix, not a status to wait out
Map each "Not indexed" reason to its root cause and fix it at source rather than waiting.

Coverage is the phase where a migration stops being something you do and becomes something you wait for. Every earlier step completes when a command returns; this one completes when search engines have re-crawled an estate at their own pace, which for anything beyond a few thousand URLs means weeks. The work here is therefore not execution but instrumentation: establishing what the legacy state was, watching two properties move in opposite directions, and knowing which of the many ways a page can be excluded actually needs a response.

The single most useful discipline is to stop reading the headline indexed count. It aggregates several unrelated conditions — pages awaiting crawl, pages crawled and rejected, pages excluded by directive, pages correctly deindexed because they moved — and its movement tells you almost nothing about which of those is happening. The exclusion breakdown, read segment by segment, is where the actionable information lives, and the difference between a migration that recovers in six weeks and one that stalls is usually somebody noticing a single exclusion reason growing where it should not.

Pre-flight Checks

Get these in place before the cutover; every one of them is a comparison point that cannot be reconstructed once the estate has moved and the reports have begun to reflect the new state.

  • 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

This is the reference every later reading is measured against, so capture it once and leave it alone. 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.

Capture the baseline as stored numbers, segment by segment, not as a screenshot of a total. Record the indexed count, the count in each exclusion state, and the counts for your top value tiers separately, dated. The reason for the segmentation is that the aggregate will move for entirely benign reasons throughout the migration, and without per-segment figures you cannot tell whether a decline of eight hundred pages is your deliberately retired archive deindexing on schedule or your product catalogue quietly falling out.

Do this before the cutover, not after. Coverage data is reported with a delay of several days and reflects a rolling assessment, so a baseline captured the morning after launch already contains migration effects. Pull it during the freeze window, when the estate is stable and the numbers describe the site you are actually migrating away from.

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.

Expect the new property to look alarming for the first fortnight, and know in advance which shapes are normal. A large “Discovered — currently not indexed” bucket immediately after launch is expected: you have just presented the crawler with a complete estate of previously unseen URLs, and it works through them in priority order over weeks. What is not normal is that bucket failing to shrink at all after three weeks, or the “Crawled — currently not indexed” bucket growing while it does, which indicates pages are being fetched and rejected rather than simply queued.

Segment the new property’s report the same way you segmented the baseline. A single unindexed section is a specific, tractable problem — usually a linking gap, a missing sitemap entry, or a template-level canonical fault — whereas the same number of unindexed pages spread evenly across the estate is a crawl-rate story that needs patience rather than intervention. The aggregate figure cannot distinguish those, and they call for opposite responses.

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

Comparing the two properties is the only reading that distinguishes a slow migration from a broken one, because each property in isolation produces the same picture for very different reasons — a legacy count that is not falling looks identical whether the crawler has not returned yet or the redirects are being rejected, and only the other property’s behaviour separates them. Put both series on one chart, in the same units, from the same dates, and read them together every time. 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.

Run the comparison on a fixed cadence rather than continuously. Weekly is right for most estates: it is frequent enough to catch a stall while there is still time to act, and infrequent enough that the day-to-day noise in a sampled, delayed report does not generate false alarms. Record each reading in the same table as the baseline so the trend is visible as a series rather than reconstructed from memory, and note alongside it anything that happened that week — a fix deployed, a sitemap resubmitted — so later readers can attribute movements.

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.

Read the exclusion reasons as a decision table rather than a list. Each one implies a different cause, a different owner, and — crucially — a different answer to whether waiting will help.

Coverage exclusion reasons and whether time alone resolves them Five common exclusion states after a migration, each with its likely cause, the owner who can act, and whether waiting resolves it or intervention is required. Two of these resolve themselves; three never will Exclusion state Usually means Waiting helps? Discovered — not indexed crawl budget, not yet reached yes Page with redirect legacy URL deindexing correctly yes — this is the goal Crawled — not indexed fetched and judged not worth it no — content issue Duplicate, different canonical canonical points somewhere wrong no — fix the tag Blocked by robots.txt a directive inherited from the build no — remove the rule
"Page with redirect" rising on the legacy property is the signal you want; the same volume rising on the new one means your redirects point at redirects.

Configs / Commands

The three checks below are the ones worth scripting, because each answers a question the coverage report raises but cannot settle: whether a specific new URL is genuinely indexable, whether anything at the new origin is blocking the crawler, and whether the legacy URLs are still returning the redirect that drives their deindexing. Run them against a sample from each value tier rather than against a handful of URLs somebody picked.

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'

Reading the two properties side by side is what turns ambiguous numbers into a diagnosis. Each combination of directions means something different, and only one of the four is healthy.

Diagnosing the migration from both properties at once A two-by-two of legacy indexed count falling or holding against new indexed count rising or flat, with the diagnosis implied by each of the four combinations. Only one of these four is the migration working Working as intended crossover under way — keep the 301s live Redirects not followed check chains, 302s, and canonical targets New content indexing legacy not yet re-crawled — keep the legacy sitemap up Nothing is happening verification, robots, or Change of Address failed new property rising new property flat legacy falling legacy holding The bottom-right cell after three weeks is the one that warrants immediate investigation rather than more patience.
Neither curve alone distinguishes these four states, which is the entire argument for keeping both properties instrumented through the crossover.

The filing itself has prerequisites that reject more attempts than anything else on this page — see Using the Change of Address Tool Correctly. For the report state that causes the most post-migration alarm, work through Diagnosing Crawled — Currently Not Indexed After a Move.

Validation

These are trend checks rather than point-in-time assertions, so run them on the same weekly cadence as the comparison above and record each result against its date.

  • 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

Use URL Inspection sparingly and deliberately. It is the only tool that tells you what the crawler actually saw for a specific page — the canonical it chose, the referring sitemap, the last crawl date, whether the rendered HTML matched what you expect — and that makes it invaluable for diagnosing a handful of important URLs. It is useless as a coverage strategy, because inspecting and requesting indexing for pages one at a time does not scale past a few dozen and does not influence how the rest of the estate is treated. Reserve it for the top tier and for confirming a hypothesis about a template.

When you do find a genuine problem, fix it at the source rather than at the individual URL. A canonical pointing at the legacy domain is almost never a single-page defect — it is a template emitting the wrong value, affecting every page built from it, and requesting re-indexing for the three URLs somebody happened to notice leaves the other four thousand broken. Trace each finding back to the template or rule that produced it, fix it there, and let the next crawl pick up the whole class.

Rollback Triggers

None of these should be read from a single week’s data — coverage is sampled and delayed, so a threshold here means a sustained trend across at least two consecutive readings rather than one alarming number.

  • 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

One structural point about the timeline: the deindexing of legacy URLs is driven by the crawler re-visiting them and finding the redirect, which means it is gated on legacy crawl rate rather than on anything you do to the new site. That is why the legacy sitemap stays submitted and the legacy 301s stay live long past the point where the new site looks finished. Removing either one does not speed anything up; it simply removes the mechanism by which the old URLs learn they have moved, stranding them in the index where they compete with their own replacements.

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.

Should I request indexing for URLs individually to speed things up? For a handful of genuinely critical pages, yes; as a strategy, no. Manual indexing requests are rate-limited, apply to one URL at a time, and do not influence how the rest of the estate is treated — so on an estate of any size the effort is out of all proportion to the effect. Where they earn their keep is confirming a hypothesis: if a page you have just fixed gets indexed promptly on request, the fix worked and the same fix applied at template level will carry the rest.

How do I tell a deliberately retired URL from an accidentally lost one? By checking it against the intentional-retirement list the audit produced. This is the specific payoff of recording those decisions during the mapping phase rather than letting retirements happen by omission: after launch the legacy property will show a large number of URLs leaving the index, and without that list every one of them is ambiguous. With it, the deindexed set splits cleanly into “as planned” and “needs investigation”, and the second list is usually short enough to work through in an afternoon.

What if coverage recovers but rankings do not? Then the problem is not indexation and you should stop looking at this report. Indexed-but-not-ranking usually points at content or signal loss rather than technical migration failure — a template that dropped its internal links, pages that lost body content in the move, or consolidation that merged distinct pages into one that now serves neither query well. Compare the new pages against the baseline export’s word count and inbound-link columns, which is exactly why those fields are worth capturing.

Is it worth watching Bing Webmaster Tools as well? Yes, and it is cheap. Bing’s index typically moves faster than Google’s after a migration, which makes it an early indicator: a redirect problem or a robots directive that will eventually show up in one report frequently appears in the other a week or two sooner. Treat it as a leading signal rather than as a second set of targets, and verify the new property there at the same time you verify it in Search Console.

Related

← Back to Search Console Handover

Explore Sub-topics

Monitoring Index Coverage After a Site Move
Monitor Search Console index coverage after a site move — read the Pages report, inspect URLs, and track deindex of old and index of new domain.
Using the Change of Address Tool Correctly
File a Search Console Change of Address without it being rejected — prerequisites, the redirect checks Google runs, and what the tool does and does not do.
Diagnosing Crawled — Currently Not Indexed After a Move
Work out whether a post-migration "crawled, currently not indexed" spike is a template fault, a duplication problem, or normal reprocessing — and what to do about each.