Indexing after a content migration: the 30-day playbook

Every migration looks fine on paper. Then traffic drops 30% the week after launch and someone has to explain why. The drop is almost never from one big thing — it's a dozen small URL coverage issues compounding. The playbook below is the version that doesn't lose rankings.

T-14 to T-7 days: prep

1. Export every indexed URL from Google Search Console. This is your "must survive" list.
2. Add traffic and ranking data to the export. Sort by value. The top 10% of URLs by traffic = the top priority for redirects.
3. Build the URL mapping spreadsheet. Old URL → New URL. Flag any that can't map cleanly.
4. Decide: for URLs that don't have a 1:1 new equivalent, redirect to a category page (preserves some link equity) or 410 (cleanest, but loses that page).
5. Stage the new site behind a noindex / staging URL. Crawl it with a test crawler to find broken links and orphan pages.

T-3 days: pre-launch checks

• Test 50 random redirects from the mapping. All should return 301 to the new URL.
• Verify the new sitemap.xml lists every new URL. Cross-check against the mapping.
• Confirm robots.txt doesn't block any new URL paths.
• Confirm canonical tags on all new URLs point to themselves (not the old URLs).
• Confirm the new pages have substantively similar content to old ones — if you took the migration as an opportunity to rewrite, expect coverage to drop temporarily.

T-0: launch day

1. Flip DNS / deploy. Now both old and new URLs exist; old ones 301 to new.
2. Submit the new sitemap to Search Console immediately.
3. Push the top 50 URLs (by traffic value) through the Indexing API. Don't try to push everything yet — Google's quota is finite and the top URLs matter most.
4. Set up a daily URL Inspection batch on the same 50 URLs to monitor recrawl progress.

T+1 to T+7 days: monitor and push

• Day 1-2: check Search Console for crawl errors. Any 5xx or 4xx from Googlebot needs same-day investigation.
• Day 3: bulk-push the next 200 URLs through the Indexing API.
• Day 4: re-inspect the original 50. Most should show "Indexed" with the new URL.
• Day 5: bulk-push the next 500 URLs.
• Day 7: full audit. Compare current indexed URLs to your "must survive" list. Identify gaps.

T+8 to T+14 days: triage

1. For every "must survive" URL still not indexed at the new path: URL-inspect to find the reason.
2. If verdict is "Page with redirect" but the new URL is also not indexed → push the new URL.
3. If verdict is "Discovered, not indexed" → push and wait. If still discovered after 14 days, audit the page.
4. If verdict is "Crawled, not indexed" → Google fetched and declined. Audit the page; usually a content-quality regression vs the old version.
5. If verdict is "Not found (404)" → the redirect is broken. Fix it.

T+15 to T+30 days: stabilize

Most of the recovery happens in weeks 2-4. Coverage should approach the pre-migration level by day 30 if the migration was clean. Major gaps that persist beyond 30 days are not migration latency — they're real coverage losses caused by something in the new build.

The single biggest mistake

Trying to push 5,000 URLs through the Indexing API on day one. Google's per-project daily quota is 200. You'll burn your quota, get rate-limited, and lose the ability to push during the critical first week. Push 50 high-value URLs on day one, the next 200 on day three, and so on. Spread the spend.

Pre-migration audit tool

Run IndexerNow's Auditor on a sample of your top 20 URLs before the migration AND after. The before-after diff makes it trivial to spot regressions (canonical changes, removed structured data, slower LCP, missing meta tags).