Post-Migration Monitoring

What post-migration monitoring is

Post-migration monitoring is the weeks-long watch you keep after launch — on Search Console coverage and crawl stats, 404 spikes, rankings, and server logs — to catch problems while they're still fixable instead of discovering them in next quarter's traffic report. A migration isn't done when the new site goes live; it's done when the data says the new URLs indexed cleanly and traffic held.

This is the last stage of the sequence. It checks the work you did in the pre-migration audit, on your staging environment, and in your redirect map — against the baseline you captured at the start.

What to watch, and how often

The first 72 hours are about catching catastrophic breakage — wrong robots.txt, missing redirects, tracking gone dark. The following weeks are about confirming Google digests the move and rankings settle.

Example: pull 404s and old-URL bot hits from server logs

Your access log is the ground truth — it shows what Googlebot actually hit and what your server actually returned, no sampling.

# Top URLs returning 404, most frequent first
awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head -20

# Is Googlebot still crawling the OLD URL pattern weeks after launch?
grep -i googlebot access.log | grep '/blog/2019/' | wc -l

A pile of 404s on old paths means redirects are missing or broke on cutover. Heavy Googlebot traffic still hitting the old pattern weeks in is normal early, worrying if it never tapers — usually a sign the new URLs aren't being discovered.

How to check it on your own site

1. Day 1: confirm the basics fire. Check GA4 realtime for live sessions, curl the homepage and a few templates for 200, and confirm robots.txt on production is the live version, not staging's Disallow: /.
2. Day 1: submit new sitemaps. Upload the new XML sitemap in GSC and confirm the old one is either updated or removed. Watch "Discovered" tick up.
3. First week: crawl the live site. Run Screaming Frog against production. Every old URL should 301 once to a live 200; every new URL should be indexable. Fix any 404, chain, or noindex leak immediately.
4. First week: watch coverage daily. In GSC > Pages, track the indexed count against your baseline. A steep drop is your earliest deindexing alarm.
5. Weeks 2–8: compare rankings to baseline. Line up current positions against the snapshot from your audit. Some churn is normal; a sustained drop on priority terms is a problem to diagnose.
6. Ongoing: mine the logs. Weekly, pull 404s and check whether Googlebot has shifted from the old URL set to the new one. Migration is "settling" when crawl attention moves to the new URLs.

Common mistakes & how to fix them

• Declaring victory on launch day. The damage usually shows up 1–3 weeks later as Google reprocesses. Fix: schedule the monitoring window before launch and hold the line for at least 4–8 weeks.
• Panicking at the first-week wobble. Some ranking and traffic fluctuation right after a move is expected while Google recrawls. Fix: compare against baseline over weeks, not hours, and act on sustained trends — not day-two noise.
• Only looking at GSC, never the logs. GSC is delayed and sampled; server logs show exactly what Googlebot hit and got. Fix: pull access logs weekly — they catch missing redirects and crawl problems GSC hides for days.
• Not watching the old URLs. Teams monitor the shiny new site and forget the old URLs are where the 404s and equity leaks happen. Fix: keep the old-URL list from your audit and test it explicitly.
• Missing broken analytics. If the GA4 tag broke on cutover, you're flying blind on the exact thing you need to measure. Fix: verify realtime data on day one before anything else.

Frequently asked questions

How long should I monitor?

Intensely for the first two to four weeks, then lighter-touch for a couple of months. A migration is "settled" when indexed count, rankings, and traffic have stabilized near or above baseline and Googlebot has largely moved to the new URLs.

Rankings dropped after launch — is the migration a failure?

Not necessarily. Short-term dips while Google reprocesses URLs are common and often recover within a few weeks. Judge it against your baseline over time. A sustained, weeks-long drop on priority terms is the signal to investigate — start with missing redirects and coverage errors.

What's the single most useful early check?

Crawl the live site in week one and confirm every old URL 301s to a live page. Missing or broken redirects are the number-one cause of post-migration traffic loss, and they're fully fixable if you catch them fast.

Do I need server logs, or is GSC enough?

GSC gets you most of the way, but it's delayed and sampled. Logs give you the un-sampled truth about what Googlebot fetched and what your server returned — invaluable for catching redirect and crawl issues early on larger sites.

What does a healthy migration look like in the data?

Indexed count holds or recovers within weeks, 404s stay low, Googlebot shifts to the new URLs, and rankings/traffic return to baseline. For a cautionary counter-example, see the migration that lost 90% of its traffic, and site migration SEO planning for the full pre-launch checklist.