Introducing IndexNow push + index-loss alerts: the coverage that matters
← Back to all posts

The migration index checklist: keeping your index through a redesign

The indexsubmit team
Oct 11, 2026
migrationscoverage

Site migrations lose traffic for two reasons. The first is real: redirect maps with holes, dropped content, changed internals. The second is silent: nobody watched the index during the transition window, so a fixable regression ran for six weeks before anyone saw it. This checklist exists to prevent the second kind from eating the gains of fixing the first kind.

Before: freeze the baseline

You cannot prove what you lost without a "before." In the weeks before cutover:

  1. Record full per-URL coverage. Every URL's verdict, not a site-level score — you will need per-URL history to prove which pages dropped and when.
  2. Export the URL inventory from your sitemaps, partitioned by section, with content versions. This becomes your redirect-map source of truth.
  3. Note your stable URLs: the pages that never change. They are your canaries — after migration they should be byte-identical and index-stable.

The redirect map: the only artifact that matters

Every old URL gets exactly one of:

  • 301 to the closest content equivalent. Not to the homepage. "All deleted pages → /" is how a site tells Google its URL space is meaningless.
  • 410 (gone) for URLs you deliberately retire. A clean 410 is honest and cheap; a soft-404 is neither.
  • Kept as-is, if it did not change.

Audit rule: the old sitemap, run through the map, must produce zero chains and zero loops. Chains (a→b→c) leak signals at every hop; loops 404 eventually. Flatten everything to one hop.

Cutover week: watch the right four signals

Daily, per section:

  1. Old URLs resolving as 200 (should go to zero) and 410s climbing as expected.
  2. New URL coverage: what fraction of the new inventory is indexed at all. Fresh URLs start at zero — the slope matters, not the starting point.
  3. Old URL verdicts: as long as Google still holds old URLs in the index, they should resolve 301 → the mapped new URL. An old URL that starts 404ing in inspection is a redirect hole.
  4. Canary stability: your stable URLs should show no verdict transitions. A canary that flips is a template or render regression, not a migration issue.

This is where per-URL inspection history earns its keep — "the /pricing verdict changed on the 14th, the day we flipped the canonical logic" is only knowable if the verdicts were being recorded.

After: the recovery window

Expect the shape: old URLs leave the index over 2–6 weeks while new URLs enter. During the window:

  • Do not re-evaluate strategy on day 3. Judge the migration on the slope of new-URL coverage and the exit rate of old URLs, not on raw numbers.
  • Alert on the exceptions: a new money page that enters the index and then drops is a real regression, not volatility. Set alerts on your top pages specifically.
  • Re-check the redirect map monthly for a quarter: analytics will surface old URLs you never had in your sitemap (backlinked pages, bookmarked paths). Every one found late is a hole found late.

How indexsubmit fits

Connect both the old and new properties before cutover and indexsubmit records the full per-URL verdict history across the switch: which old URLs dropped and when, how fast the new inventory entered, which sections lagged, and which pages transitioned badly. Alerts fire on the exceptions — a top page dropping or a 404 appearing — instead of you diffing exports by hand.

Migrations are the highest-stakes indexing event most sites ever run. The checklist is short; the discipline of watching per-URL history through the whole window is what separates a dip from a crater.