Monitoring Index Coverage After a Site Move

Problem Statement

The Change of Address is filed, redirects are live, and the new sitemap is submitted — now you need hard evidence that Google is deindexing the old domain and indexing the new one, before you deprecate any legacy infrastructure. This guide, part of Index Coverage Handoff, defines the daily monitoring routine across both properties: reading the Pages report, using URL Inspection, and tracking the inverse curve of old-down / new-up.

Index coverage crossover Legacy indexed pages decline while new-domain indexed pages rise, crossing over as the migration completes. Index Coverage Crossover Indexed pages Weeks after Change of Address crossover Legacy domain New domain
A healthy move shows legacy indexed pages falling as new-domain pages rise, crossing over within weeks.

When to Use This Approach

  • The Change of Address has been accepted and 301 redirects are confirmed live
  • You need objective go/no-go evidence before retiring legacy redirects or hosting
  • Both legacy and new properties are verified and accessible
  • The site is large enough that indexing happens in waves, not instantly
  • You must catch canonical, redirect, or robots errors before they drain crawl budget

Step-by-Step Instructions

1. Set the Legacy Baseline and a Cadence

Export the legacy “Indexed” and “Not indexed” totals as your reference, then check both Pages reports daily for two weeks and weekly after. Without the baseline from before the move, a number on the new domain has no meaning.

# Re-confirm a sampled legacy URL still 301s, which is what drives deindex
curl -sI https://legacy.example.com/key-page | grep -E 'HTTP/|location'

2. Read the New Property’s Pages Report

Watch the Indexed count rise and triage the “Not indexed” reasons. Migration-specific reasons — “Page with redirect”, “Duplicate without user-selected canonical”, “Crawled — currently not indexed” — are faults to fix, not statuses to wait out.

# A new URL must return 200 with a self-referencing canonical to be indexable
curl -s https://newdomain.example/key-page | grep -i 'rel="canonical"'

3. Inspect Priority URLs

Run URL Inspection on top traffic and revenue pages. Confirm coverage reads “URL is on Google”, the Google-selected canonical matches the new URL, and the last crawl is recent. Request indexing only for the highest-value handful.

4. Track the Crossover and Decide

Plot legacy Indexed (falling) against new Indexed (rising) week over week. When the new count approaches the legacy baseline and legacy URLs have largely deindexed, the move is healthy and you can plan to retire the old sitemap per Sitemap Re-submission Strategies. If new indexing stalls below 75% of baseline two weeks in, escalate.

Worked Example

Three weeks after moving legacy-shop.com to newshop.example, the legacy property’s Indexed count has fallen from 12,400 to 4,900, while the new property has climbed from 0 to 9,800. URL Inspection on newshop.example/products/blue-widget returns “URL is on Google”, Google-selected canonical https://newshop.example/products/blue-widget, last crawl two days ago.

$ curl -sI https://legacy-shop.com/products/blue-widget | grep -E 'HTTP/|location'
HTTP/2 301
location: https://newshop.example/products/blue-widget

The inverse curve is on track and the crossover has passed, so legacy hosting can be scheduled for decommission once the legacy Indexed count nears zero — while keeping 301s in place.

Verification

  • New-domain “Indexed” count trends up toward the legacy baseline week over week
  • Legacy “Indexed” count declines as redirects are crawled
  • curl -sI on legacy priority URLs returns 301 to the matching new URL
  • URL Inspection reports “URL is on Google” with the new URL as the chosen canonical

FAQ

How soon should the legacy domain start deindexing? You typically see the legacy Indexed count begin falling within one to three weeks of the Change of Address, provided 301s are live. If it has not moved after three weeks, re-check that the legacy sitemap is still reachable so Google re-crawls and finds the redirects.

What if new indexing stalls well below the baseline? Triage the “Not indexed” reasons first. Canonical conflicts pointing at the legacy domain and “Page with redirect” errors are the usual culprits; fix the markup or routing, validate in the report, and only escalate to a rollback decision if indexing stays below 75% of baseline after two weeks.

Can I retire the legacy property once the crossover passes? Keep the legacy property verified for at least 180 days even after crossover, so you retain diagnostic history and can roll back if coverage regresses. Retiring the sitemap and hosting can proceed earlier, but never remove the 301s for high-authority paths.

Related

← Back to Index Coverage Handoff