A migration that broke something still looks fine in a browser. The reports in Google Search Console become readable at different speeds, so the order you check them in matters as much as the list.
Does your Search Console history follow you to the new site?
No. Performance data belongs to the property, and a new domain means a new property with an empty history. Nothing transfers, and no setting makes it transfer.
Plan for that before launch rather than discovering it afterward. Verify the new property early, export the old property's performance data for at least sixteen months while it is still there, and expect that any before-and-after comparison you need will have to be stitched together from two exports by hand.
If the move involves a change of domain, use the Change of Address tool in the old property. It requires both properties verified and the redirects already in place, and it tells Google to carry signals across rather than treating the new URLs as unrelated. It is not a substitute for the redirects; it is a notification that they exist.
Which report shows a broken migration first?
The page indexing report, and specifically the reasons listed under the pages that are not indexed. It updates faster than performance data tells you anything, because it reflects crawling rather than ranking.
Three statuses are the ones to read closely. "Not found (404)" rising on the new property means URLs are being requested that the migration did not account for. "Page with redirect" appearing for URLs that should be live means something in the new structure is redirecting pages you intended to keep, often a trailing-slash or case-sensitivity rule applied too broadly. And a page counted as an alternate with a proper canonical, when you expected it to be the canonical itself, means the new templates are pointing at the wrong version.
On the old property, watch for the opposite signal: old URLs that are still reported as indexed and not as redirects. That means Google has not yet recrawled them, which is a waiting problem rather than a breakage, and keeping the old sitemap reachable gives the crawler the list it needs to work through.
Check both properties for the first month, not just the new one. The old property is the only place that tells you whether Google has processed your redirects, and a migration is not finished until the old URLs are reported as redirects rather than as live pages.
How do you confirm the redirects are actually working?
Test them by URL, not by crawling the new site. The URL Inspection tool on the old property shows you what Google sees when it fetches an old address, which is the only view that counts.
| Check | Where | What a pass looks like |
|---|---|---|
| A representative old URL per template | URL Inspection, old property | Reported as a redirect to the intended new URL |
| The old sitemap | Sitemaps report, old property | Still fetchable, so old URLs get recrawled |
| The new sitemap | Sitemaps report, new property | Submitted, read, and discovered count close to the real page count |
| Top twenty old URLs by clicks | URL Inspection, one by one | Each lands on a page serving the same intent, not the homepage |
| New 404s | Page indexing, new property | Flat, or a list you recognize and chose to drop |
| Internal links to the new pages | Links report, new property | Important pages have internal links, none are stranded |
The fourth row is where real damage hides. Redirecting everything to the homepage passes a link checker and still loses the rankings, because the destination does not answer the query the old URL answered.
Not checking for a staging noindex or a blocking robots.txt rule that shipped with the new site. The pages load normally for visitors, so nothing looks wrong, and the first symptom is pages quietly leaving the index a week later. Inspect a live URL on the new property on launch day and read what it reports about indexing permission.
When do the Core Web Vitals and rich results reports mean anything again?
Not for several weeks. The Core Web Vitals report is built on field data gathered over a rolling twenty-eight day window, so new URLs need that window to fill before the numbers describe the new site rather than a thin sample of early visitors.
Read it as empty, not as good or bad, during that period. A report with too little data for a URL group will say so, and treating an absence of problems as a pass is how a performance regression survives its first month.
Structured data is faster but still lags crawling. Check the rich result reports for item types that dropped to zero, which usually means the markup did not survive the template rewrite rather than that it became invalid. Validate one URL per template by hand instead of waiting for the aggregate to repopulate.
How long do you keep watching, and what counts as recovered?
Watch for a full quarter, and judge recovery on queries rather than sessions. Organic search totals mix seasonality and demand changes into the migration signal, which makes them the slowest way to learn anything.
Compare impressions and average position for your top queries across the two properties. If positions held and impressions are flat, the migration worked and any traffic dip is coming from elsewhere. If positions slid on a specific template's queries, the fault is in that template, which is a far more useful finding than a site-wide percentage. Where a whole subject area lost ground together, the thing that broke is likely the internal linking that held the cluster together and carried its topical authority.
What do you do in the first forty-eight hours?
Inspect one live URL per template on the new property to rule out a shipped noindex, then inspect your top twenty old URLs to confirm each redirect lands somewhere that answers the same question. Those two checks catch the failures that are cheap to fix now and expensive in a month. Everything else on this page can wait until the reports have data; the noindex cannot.