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

This runs continuously from launch until the legacy tail has drained, which is weeks rather than days on any estate of size.

  • 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

Each step below produces a number that goes into the same dated table, so the output of this procedure is a series rather than a snapshot.

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'

Set the cadence to weekly and hold to it. The temptation after a cutover is to check daily, which given a reporting delay of several days and a sampled underlying count means you are mostly observing noise — and noise, watched closely enough, always eventually suggests an intervention. Weekly readings recorded in a dated table give you the one thing the interface does not: a series you can look along, where a genuine stall is obvious and a normal fluctuation plainly is not.

Record the numbers rather than screenshotting the charts. What you will want in six weeks is the ability to subtract, and a folder of images does not support that. A short table with the date, the indexed count on each property, and the counts for the two or three exclusion states that matter takes a minute to fill in and answers every question the migration retrospective will ask.

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.

Segment the readings the same way the baseline was segmented. An estate-wide indexed count moves for many reasons at once, and a single aggregate cannot distinguish your deliberately retired archive draining on schedule from your product catalogue quietly failing to index. Per-section figures make that distinction immediate, and they also localise any problem to a template or a path prefix — which is the level at which it can actually be fixed.

Treat a section that is flat while its neighbours move as the priority signal. Uniform slowness across the whole estate is a crawl-rate story and resolves with time; one section pinned at zero while others climb is a specific defect, and it is almost always a linking gap, an absent sitemap entry, a canonical pointing at the legacy domain, or a robots.txt rule inherited from the new build.

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.

Coverage data has three properties that make it unlike any other signal in a migration, and misreading them accounts for most of the unnecessary interventions teams make in the weeks after a cutover.

How coverage data differs from operational monitoring Three properties of Search Console coverage data — reporting delay, sampling, and its aggregate nature — each contrasted with the operational dashboards teams are used to and the reading habit each one requires. Read it like a trend, not like a dashboard Property Unlike your error dashboard So read it Delayed several days not real time, at all weekly, never hourly Sampled and approximate counts move without cause direction, not magnitude Aggregates unrelated states one number, many causes by exclusion reason Reflects a slow process weeks, not minutes against the baseline
Every one of these argues against reacting to a single day's movement, which is the impulse the report most reliably provokes.

Worked Example

The readings below are from a mid-sized catalogue migration, sampled weekly from launch. 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

These confirm the monitoring itself is sound before you start drawing conclusions from it — a series built on a baseline captured after launch, or on an aggregate that mixes segments, will mislead consistently rather than occasionally.

  • 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

The crossover is the moment worth watching for, because it is the first unambiguous evidence that the redirects are being processed rather than merely present. Before it, both curves are consistent with several stories; after it, only one.

Weekly cadence and what each reading should show A four-stage weekly monitoring cadence from launch through the crossover to decommissioning, showing the expected state of each property at each stage and the decision available at that point. Four readings, four different decisions Week 1 new property mostly "discovered" do nothing Weeks 2–4 legacy begins falling, new begins rising fix what is stuck Crossover new overtakes legacy on indexed count still keep the 301s Tail legacy near zero, new at baseline safe to decommission The crossover is not the finish line — it is the point at which you can be confident the mechanism is working. Decommissioning belongs weeks later, once the legacy tail has actually drained.
Week 1 exists on this chart to make one point: the correct action in the first reading is almost always none.

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.

What is a realistic crossover date to promise stakeholders? Give a range rather than a date, and derive it from estate size. A few thousand URLs commonly cross over in two to three weeks; a large catalogue or a deep archive routinely takes six to ten, and the final few per cent of low-value URLs can drag on well past that without indicating anything wrong. Communicating the range before launch is what turns the week-three question from an escalation into a status check, and it removes the pressure to intervene against a process that is simply not finished.

Should I keep monitoring after the crossover completes? At a reduced cadence, for a couple of months. The specific thing worth watching for is regression — legacy URLs reappearing in the index, or new-property coverage slipping — both of which usually indicate that something still serves the old content, such as a subdomain, a staging environment, or a CDN that was never repointed. That kind of fault surfaces slowly and is invisible from the infrastructure side, because everything involved is returning perfectly valid responses.

Does requesting indexing help a stalled section? Not at the scale a section implies. Manual requests are rate-limited and apply per URL, so they are useful for confirming a hypothesis on a handful of pages and useless as a remedy for thousands. If a whole section is stalled, the productive move is to find what is different about it — internal linking, sitemap inclusion, a template-level canonical, an inherited robots directive — and fix that at source, after which the next crawl handles the rest without further prompting.

Related

← Back to Index Coverage Handoff