A Step-by-Step Diagnostic Framework for Post-Migration Traffic Loss

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.

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, the first section of the diagnostic framework covers how to reconstruct what you can before starting the audit proper.

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.

Check These Before Assuming SEO Loss

• 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.

What a Real SEO Drop Looks Like

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.

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 dilutes the signal passed to the destination URL — and chains longer than two or three hops are frequently dropped entirely during recrawl cycles.

What to Check

• 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.

Tools for This Step

• Screaming Frog SEO Spider — crawl both old URLs and new site simultaneously using the list crawl mode
• Google Search Console Coverage report — surfaces 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.

Canonical Tag Audit

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 or use rel-next/prev signals
• HTTP canonicals on an HTTPS site, or www canonicals on a non-www site

Indexation Status Audit

In Search Console, check the Coverage report for:

• URLs marked as Excluded: Noindex — 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 Valid 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 (Fix 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 (Fix 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 (Fix 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 (Ongoing)

• 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.

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 Sufficient 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

External Diagnostic Support Makes Sense 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, a professional post-migration SEO review can give you a prioritized diagnosis within days rather than weeks of continued uncertainty.