Diagnose a Post-Migration Traffic Drop in the Right Order

This guide is written for site owners, in-house marketers, and developers who have completed a website migration-whether a domain change, platform switch, HTTPS upgrade, or structural redesign-and are now seeing organic traffic behave unexpectedly.

It is not a pre-migration checklist. If you haven't migrated yet, the preventive checklist in this cluster covers what to do before you flip the switch. This guide starts at the moment you're already looking at a dashboard wondering what went wrong. The migration mistakes guide provides additional context on common failure patterns.

You'll get the most out of this audit if you have:

• Access to Google Search Console (verified for both old and new properties if it was a domain change)
• Access to your analytics platform (Google Analytics 4 or equivalent) with at least 90 days of pre-migration data
• Ability to run a site crawl-Screaming Frog, Sitebulb, or a similar tool
• A record of the migration date, even an approximate one

If you're missing any of these, reconstruct what you can before starting the audit proper: historical reports, legacy sitemaps, backlink exports, and archived pages can still help establish what previously existed.

This guide is also relevant if your migration happened several months ago and traffic never fully recovered. Delayed diagnosis is harder but not impossible-the audit steps are the same, though the interpretation requires more care when separating migration impact from other ranking changes that may have accumulated since.

Before diagnosing a problem, confirm you're looking at one. Post-migration dashboards frequently show anomalies that aren't traffic losses-they're tracking gaps, attribution changes, or session definition changes introduced by the new platform.

Verify the Measurement Layer First

• Analytics tracking continuity: Did your GA4 tag carry over to the new site? A missing tag looks like a traffic cliff but is a measurement gap, not a ranking drop.
• Search Console property coverage: If you changed domains, is the new domain verified? Are you comparing the same property before and after?
• Organic vs. all-channel comparison: Is the drop isolated to organic, or did all channels drop? A drop across all channels usually points to tracking, not SEO.
• Seasonal baseline: Compare the same period year-over-year, not just week-over-week. A migration that coincided with a seasonal low can look worse than it is.

Confirm Search Visibility Changed

A genuine post-migration ranking loss shows up as a sustained decline in organic impressions and clicks in Search Console, with corresponding falls in ranked keyword positions for URLs that previously ranked. If impressions drop but clicks hold, that's a different signal than both dropping together. Compare affected landing pages, queries, and page groups rather than relying only on a sitewide total.

Document your migration date in Google Search Console's Performance report using the date comparison feature. This creates a clean before/after reference point that every subsequent diagnostic step will use.

Once you've confirmed the drop is real and organic, move to the redirect audit.

In our experience working with post-migration recoveries, broken or chained redirects are the single most common cause of sustained traffic loss. Google will follow redirect chains, but each hop can dilute the signal passed to the destination URL-and chains longer than two or three hops may be dropped during recrawl cycles.

Check Redirect Mapping Against Real Legacy URLs

• Redirect map completeness: Every URL that ranked pre-migration should have a direct 301 to its new equivalent. A redirect to the homepage is not a redirect-it's a dead end for link equity.
• Redirect chain length: Old URL → intermediate URL → new URL chains should be collapsed to Old URL → new URL directly.
• Redirect loops: Pages that redirect to each other create crawl traps. Screaming Frog's redirect report will surface these.
• 404 errors on formerly-ranked URLs: Pull your pre-migration sitemap (from the Wayback Machine if needed) and crawl it against the new site. Every 404 is a lost ranking signal.

Cross-Check Crawl Access

Crawl the migrated site and compare the results with the redirect map, XML sitemaps, and Search Console reporting. Useful tools for this step:

• Screaming Frog SEO Spider - crawl both old URLs and new site simultaneously using the list crawl mode
• Google Search Console indexing reports - surface crawl errors Google has already found
• httpstatus.io or Redirect Checker - for spot-checking individual URL chains

Export every redirect issue into a spreadsheet with status codes, chain paths, and priority ranking (based on pre-migration traffic). Fix highest-traffic URLs first. Don't wait for a complete fix before deploying partial corrections-every week a top-traffic URL returns a 404 is a week of index signal decay.

After redirects, the next most common post-migration failure mode is canonicalization conflict. This happens when the new site either inherits canonical tags pointing to old-domain URLs or generates self-referencing canonicals on pages that should be consolidating to a different variant.

Review Canonical Output

Run a full site crawl and export the canonical tag for every page. Check for:

• Canonical tags still pointing to the old domain (common when a CMS migration copies header templates without updating the canonical logic)
• Pages with no canonical tag where one is needed
• Paginated pages canonicalizing to page 1 when they should self-reference
• HTTP canonicals on an HTTPS site, or www canonicals on a non-www site

Review Indexability in Search Console

In Search Console, check the Page indexing report for:

• URLs marked as Excluded by 'noindex' tag - particularly dangerous if your staging environment's noindex tag was accidentally deployed to production
• URLs in Crawled - currently not indexed status, which may indicate thin content or canonicalization conflict
• Sudden drops in indexed pages compared to your pre-migration baseline

A quick diagnostic: use the site: operator in Google Search to get a rough indexed page count for the new domain. Compare this to your expected page count. A significant gap usually means either a robots.txt block, a sitewide noindex, or a canonicalization problem suppressing indexation at scale.

This step frequently surfaces the root cause of large-scale traffic drops that redirect audits alone don't explain.

Not all post-migration issues have equal impact. Working through them in the wrong order wastes time and delays recovery. Here's a practical triage framework based on impact and reversibility.

Priority 1 - Immediate Review Within 48 Hours

• Sitewide noindex tag accidentally left on from staging
• Robots.txt blocking Googlebot from crawling the entire site or key sections
• Missing analytics tracking (you're flying blind without it)
• SSL certificate errors causing browser warnings (trust and crawlability impact)

Priority 2 - High Review Within 1-2 Weeks

• 404 errors on URLs with pre-migration rankings or backlinks
• Redirect chains longer than two hops on high-traffic pages
• Canonical tags pointing to old domain URLs
• Missing or incorrect hreflang tags on international sites

Priority 3 - Medium Review Within 30 Days

• Internal link updates-links in body content still pointing to old URL patterns
• Structured data errors introduced by the new platform's template differences
• Page speed regressions introduced by the new platform (compare Core Web Vitals before and after in Search Console)
• XML sitemap updates to reflect the new URL structure

Priority 4 - Monitor and Recheck

• Keyword ranking recovery for pages where technical issues have been resolved-allow 4-8 weeks for Google to recrawl and reassess
• Backlink anchor text changes if the domain name changed
• Content gaps identified by comparing pre- and post-migration keyword coverage

Document every fix with the date it was deployed. Recovery attribution-understanding which fixes drove which ranking improvements-is only possible if you maintain a clean change log throughout the process. Record how you verified the new behavior so each correction can be retested.

Most post-migration audits are technically executable by someone with Search Console access, a crawl tool, and patience. The question is whether the scope, speed, or stakes justify external support.

Self-Audit Is Usually Reasonable When

• The site is under a few hundred pages
• The migration was a platform switch with no domain change
• Traffic dropped less than 20-25% and has been stabilizing over the first few weeks
• You have clear access to pre-migration data and can identify a plausible cause within the first audit pass

Escalation Is Worth Considering When

• The traffic drop is severe-industry benchmarks suggest drops above 40-50% on core organic channels are rarely self-resolving without systematic intervention
• The migration involved a domain change, platform change, and structural URL change simultaneously
• Three or more weeks have passed since migration with no stabilization signal
• Internal fixes have been attempted but haven't moved rankings
• The site generates significant revenue from organic and every week of delay has measurable cost

A professional post-migration diagnostic differs from a self-audit primarily in depth of log file analysis, backlink impact modeling, and the experience of pattern recognition across similar migrations. If you're eight weeks post-migration and still seeing sustained loss with no clear cause identified, that's typically the point where a structured external review recovers more ground faster than continued internal iteration.

If you're at that point, ask for a professional post-migration SEO review and a prioritized diagnosis rather than continuing through weeks of uncertainty.