After a migration, Google Search Console is the closest thing you get to a diagnostic dashboard, and the checks run on a schedule: launch week is setup and submission, both properties verified, new sitemaps in, the change-of-address tool where domains moved; the first month is the watchlist, the page-indexing report’s 404 and soft-404 rows, the performance report read as old-versus-new URL trends, and crawl stats confirming Googlebot moved its attention; the settling months are trend confirmation, indexed counts converging, queries recovering position, and the long tail getting re-crawled. The routine matters because migration damage announces itself in Search Console weeks before it shows in revenue, and every alarm it raises maps to a mechanical fix, usually a redirect row. It is also, honestly, the verification layer for whoever ran your migration: at WPBuildAI the same reports are how we prove to clients that the crawl-first process held, because the inventory that drove the move predicts exactly what these reports should show.
Launch week: setup, submission, and the baseline
The first session is plumbing, done once and correctly. Verify the new site as a property, keeping the old property, never deleting it, because its historical data is the baseline every later comparison needs, and its reports keep describing how the old URLs are being processed. Where the migration changed domains, file the change of address in the old property’s settings, the one explicit signal Google offers for domain-level moves; where only structure changed on the same domain, there is no tool to file, and the redirects carry the whole message. Submit the new sitemaps, per section or language if the site is structured that way, and confirm they parse with the URL counts you expect from the migration inventory, since a sitemap whose count disagrees with the inventory is the first mismatch worth chasing. Then record the baseline: export the old property’s top pages and queries for the trailing months, because in twelve weeks you will want to compare against precisely this and the interface’s memory windows will fight you.
One discipline across everything that follows: Search Console reports lag reality by days, so the routine is scheduled reading, not anxious refreshing, weekly in month one, then monthly.
The first month: the four reports that catch real damage
| Report | What to look for | The fix | Verdict |
|---|---|---|---|
| Page indexing: 404s | Old URLs appearing as not found | Add the redirect row, resubmit | The rolling to-do list |
| Page indexing: soft 404s | Redirects judged irrelevant | Remap to true equivalents | The quiet equity leak |
| Performance by page | Old URLs falling, new URLs rising | Investigate falls without risers | The handover chart |
| Crawl stats | Requests shifting to new URLs | Fix sitemap gaps, internal links, speed | Google’s side of the story |
The 404 rows are the highest-value alarm in the whole system, because equity only flows through redirects Google can follow: each one is an old URL the redirect map missed, invisible to your launch tests if it never appeared in the inventory, and the response is mechanical, add the redirect to the genuine equivalent, and treat the report as a rolling to-do list that should trend to empty. The soft-404 rows are subtler and matter more: they are Google telling you a redirect exists but lands somewhere it considers irrelevant, the homepage catch-all pattern above all, and every row there is equity leaking through a redirect that passed your status-code tests. The performance report read correctly is a handover chart: filter to old URLs and watch them decay, filter to new and watch them rise, and the pages that fell without a corresponding riser are the specific places to dig, usually a redirect to the wrong destination or a content-parity gap on the new page.
Crawl stats round out the picture from Google’s side: requests should migrate from old to new URL patterns over the weeks, and a re-crawl that stalls points at the usual suspects, a sitemap listing the wrong URL forms, internal links still referencing old addresses, or response times discouraging the crawler.
Reading the settling: what is normal, what is not
Expect turbulence and know its shape: rankings on a well-executed migration typically dip and wobble as Google re-evaluates, then recover over weeks, with the long tail recovering slower than the head because thin-traffic pages get re-crawled last. Normal looks like: indexed counts on the new property climbing toward the inventory’s count, the old property’s coverage shifting to redirect statuses, queries in the performance report recovering position week over week, and the 404 report’s new entries slowing to a trickle of genuinely obscure URLs. Not normal, and worth escalating: a dip that deepens past the early weeks instead of turning, whole sections that never begin recovering, indexed counts plateauing far below the inventory, and any growth in soft 404s after the first fixes, each of which points at a systematic issue, a redirect class missing, a template noindexed by accident, a robots rule blocking a section, rather than settling noise.
The discipline that separates diagnosis from anxiety is the inventory: because the crawl-first migration recorded every URL and its equivalent, every Search Console anomaly can be checked against what should be true, this URL should redirect there, this section should contain this many pages, and the question “is this bad?” always has a reference answer. Migrations run without an inventory read these same reports as tea leaves.
The weekly session, timed honestly
For calibration, the whole month-one routine costs less time than the anxiety it replaces: fifteen to twenty minutes weekly, run the same way each time so trends stay comparable. Five minutes in page indexing, exporting new 404 and soft-404 rows into the redirect file’s to-do tab; five in performance, the old-versus-new filter pair, noting any faller without a riser; three in crawl stats, confirming the request mix keeps shifting new-ward; and the remainder on whatever last week’s notes flagged. The note-taking is the underrated half: a dated line per session, counts and one observation, turns four weeks of sessions into the trendline the settling judgment needs, and it is precisely the discipline that lets you distinguish a dip that is turning from a dip you merely hope is turning. From month two the same session runs monthly, and by the quarter it merges into the site’s ordinary SEO review, which is the quiet sign the migration is finished.
The checks nobody remembers until they hurt
Four smaller surfaces earn a place in the routine. The enhancements and rich-result reports: if the old site earned FAQ, product, or breadcrumb rich results, confirm the new templates’ structured data is being read, since markup parity is part of content parity and a silent schema regression shows up here first. The robots and page-availability checks inside URL inspection: spot-check cornerstone pages to confirm they are indexable, canonical where expected, and serving the content Google sees as you see it, which catches the accidental noindex and the staging-domain leak in one tool. Internationalization, where it applies: per-language sections watched separately, because multilingual regressions hide inside aggregate graphs. And manual actions plus security issues: near-always empty, checked monthly anyway, because the one time either fires you want to learn it from the report rather than from the traffic graph.
Then the quiet closer: keep the old property and its redirect-era data for the long term, and re-run the full bulk redirect test quarterly against the original inventory, since Search Console tells you what Google tripped over this week, while the bulk test tells you what anyone would trip over, and the two checks together are the whole maintenance surface of a finished migration.
Key takeaways: Search Console after a migration
Run it as a schedule, not a vigil: launch week for verification, sitemaps, change of address where domains moved, and the baseline export; weekly in month one for the four damage reports, 404s as the redirect to-do list, soft 404s as the wrong-destination alarm, performance as the old-to-new handover chart, crawl stats as Google’s side of the story; monthly through settling for trend confirmation against the inventory’s reference answers. Know turbulence’s normal shape, a dip that turns within weeks, long tail last, and escalate the abnormal, deepening dips, plateaued counts, growing soft 404s, as systematic issues with mechanical fixes. Keep the old property forever, spot-check rich results and indexability, and pair the reports with a quarterly bulk redirect re-test. The inventory makes all of it diagnosis rather than tea-reading, which is why the crawl-first process and this routine are two halves of one method, the halves WPBuildAI runs on every migration.
Quick answers
What should I check in Google Search Console after a migration?
On a schedule: launch week, verify the new property while keeping the old one, submit sitemaps, file the change of address if the domain moved, and export the old property’s top pages as the baseline; weekly in month one, the page-indexing report’s 404 and soft-404 rows, the performance report filtered as old-versus-new URLs, and crawl stats; monthly after, trend confirmation, indexed counts converging on the inventory, queries recovering, plus rich results and indexability spot-checks. Every alarm maps to a mechanical fix, usually a redirect row, and the migration inventory gives each report a reference answer, which is how WPBuildAI verifies every crawl-first move.
How long until rankings recover after a migration in Search Console?
The normal shape is a dip and wobble that turns within the early weeks and recovers over one to three months, with head terms recovering before the long tail because thin pages get re-crawled last; larger sites and bigger structural changes sit at the longer end. Judge the shape, not the day: a dip that turns is settling, a dip that deepens past the early weeks, or sections that never begin recovering, signals a systematic problem, missing redirect classes, accidental noindex, blocked sections, that the indexing and crawl reports will localize. Recovery you can verify beats reassurance either way.
What does a spike in 404s after migration mean?
It means the redirect map has holes, and the report is handing you the list: each 404 row is an old URL Google tried, found unmapped, and will eventually drop along with its equity, so the response is mechanical, map each to its genuine new equivalent and let the report trend back toward empty. A spike concentrated in one pattern, a parameter style, an image path, a dated archive, indicates a whole redirect class missed by the rules, worth fixing as a class. Soft 404s are the more dangerous cousin: redirects that exist but land irrelevantly, remapped page by page.
When should you not worry about a post-migration ranking dip?
When it has the normal shape: arriving in the first days, wobbling, and turning upward within the early weeks, head terms before long tail, while the 404 report quiets as fixes land, that is Google re-evaluating a well-redirected site, and the correct response is patience plus the weekly reading, not intervention. Worry is earned by shape violations, a dip still deepening past the early weeks, whole sections that never begin turning, soft 404s growing after the first fixes, because each points at a systematic cause, a missing redirect class, an accidental noindex, a blocked section, that the indexing and crawl reports will localize to a fixable place.
Can Search Console tell me if my migration succeeded?
It is the best free instrument, with honest limits: it shows Google’s experience of the move, 404s, indexing, crawl attention, query performance, which covers the search-equity half of success completely, and it says nothing about the rest, conversion, speed as users feel it, other engines, AI-crawler visibility. Pair it accordingly: the inventory-driven bulk redirect test for ground truth Google has not reached yet, analytics for the business half, and an external speed check for the experience half. A migration that reads clean across Search Console, the bulk test, and analytics is done in every sense that matters.
