The migration went fine by every internal measure. The new site loads faster, the design team is happy, QA signed off, and then two weeks later someone pulls up Search Console and organic traffic is down 30 percent with no obvious explanation. This is one of the most common post-migration problems in technical SEO, and it's almost never one single cause. It's usually two or three smaller issues stacking on top of each other, each individually survivable, together not.
Step 1: Confirm It's Actually a Ranking Problem, Not a Measurement Problem
Before touching anything SEO-related, rule out analytics misconfiguration. Check whether the new site has the same tracking tag, the same goals or conversions configured, and the same consent-mode setup as the old one. A broken analytics tag after a migration produces a traffic graph that looks identical to a real ranking drop, and teams have burned weeks diagnosing a phantom SEO problem that was actually a tracking bug. Cross-check against server log data if you have it; a mismatch between logged traffic and analytics-reported traffic points straight at measurement, not rankings.
Step 2: Check Whether Pages Actually Got Indexed Under the New URLs
Pull the URL Inspection tool in Google Search Console for a sample of your most important pages and confirm they're indexed under the new URL structure, not still showing the old one as canonical. If migration involved a URL structure change, a surprising number of pages can sit in a "duplicate, Google chose different canonical" state for weeks if redirects weren't airtight. Compare the Pages report's indexed count before and after the migration date. A meaningful drop in indexed pages is a strong, early signal.
Photo by Rafael Minguet Delgado on Pexels
Step 3: Audit Every Redirect, Not Just the Ones You Remember Setting Up
This is where most migration traffic loss actually originates. Pull your full list of pre-migration URLs from the old sitemap or a crawl archive and check each one's redirect status individually, not just the handful you remember prioritizing. Common failure patterns: a blanket redirect-everything-to-homepage rule instead of mapping URLs one-to-one, redirect chains three or four hops long that dilute link equity at each hop, and parameterized or paginated URLs that got missed entirely because nobody thought to list them.
A single 301 redirect done correctly preserves the overwhelming majority of a page's ranking signals. A redirect chain, or a redirect to an unrelated page, preserves almost none of it. If you inherited this migration rather than planned it, this audit is worth doing even if someone insists the redirects were handled, because "handled" and "handled correctly for every URL" are different claims.
Step 4: Check for Canonical Tag Conflicts
A canonical tag pointing at the wrong URL, a leftover staging-environment canonical, or self-referencing canonicals that got lost in a template rebuild can quietly tell Google to consolidate ranking signals onto the wrong page. Spot-check canonical tags across your top pages and your most common template types, product pages, category pages, blog posts, since a templating bug usually affects an entire page type at once rather than one page in isolation.
Step 5: Confirm Googlebot Can Actually Render the New Site
If the migration involved a framework change, especially a move toward heavier client-side JavaScript rendering, use the URL Inspection tool's "Test Live URL" feature, documented in Google's Search Central resources, to see the rendered HTML Googlebot actually receives. Compare it against what a human sees in a browser. A gap between the two, content missing from the rendered version, navigation links that only populate after a JavaScript event Googlebot doesn't trigger, means Google may be crawling a thinner version of your page than you think, with knock-on effects for both indexing and internal link discovery.
"Most post-migration traffic drops aren't one catastrophic mistake. They're three small gaps, a few missed redirects, a canonical left pointing at staging, a template that dropped some internal links, that each cost a little and together cost a lot." - Dennis Traina, founder of 137Foundry
Step 6: Check Whether Internal Linking Survived the Rebuild
A new design often reshuffles navigation, footer links, and related-content modules, sometimes dropping internal links that used to point at specific deep pages. Crawl the new site with a standard crawler like Screaming Frog and compare the internal link count per page against a pre-migration crawl if you have one archived. Pages that lost most of their internal links lost a real ranking signal even if nothing else about them changed, since internal links are one of the clearest ways search engines gauge a page's relative importance within your site.
Step 7: Look at Core Web Vitals and Page Experience Signals
A redesign that adds weight, more scripts, larger hero images, a heavier font-loading strategy, can quietly regress load performance even while looking faster to the team that built it on a fast office connection. Compare Core Web Vitals data from the Search Console Experience report for the weeks before and after migration. A regression here won't usually explain a 30 percent drop on its own, but it compounds with everything else on this list.
Step 8: Rule Out an Accidental Noindex or Robots.txt Block
This sounds too basic to need checking, until it's the actual cause. Staging environments routinely carry a sitewide noindex tag or a blocking robots.txt, and it is a remarkably common mistake for that configuration to accidentally ship to production during a migration. Check the live robots.txt file directly and spot-check meta robots tags across page templates. This single check takes two minutes and has been the entire explanation behind more than one migration traffic collapse.
Step 9: Check whether Structured Data Survived the Template Change
If your old site had schema.org markup generating rich results, star ratings, FAQ accordions, breadgrumb trails in search results, confirm the new templates still output valid structured data. A rich result disappearing from the search listing doesn't just lose the visual real estate, it can measurably reduce click-through rate even if the underlying ranking position barely moved, which shows up in your traffic numbers as a drop that looks ranking-related but is actually a click-through problem.
Step 10: Give It Time, But Not Unlimited Time
Some amount of post-migration volatility is normal while Google re-crawls and re-evaluates the new URL structure, typically settling within two to six weeks for a well-executed migration. If you're three weeks past a clean migration with no issues found in steps one through nine, some of the drop may simply be temporary reprocessing noise. If you're past six weeks with no recovery and no clear remaining issue on this list, it's worth widening the investigation to algorithm update timing or external factors unrelated to the migration itself.
This step trips people up because patience and negligence look identical from the outside, both involve waiting. The difference is whether you're waiting with a documented list of checks already completed, or waiting because nobody has looked yet. A team that's run through redirects, canonicals, rendering, and indexing and found everything clean is justified in giving the recovery more time. A team that hasn't checked anything yet and is simply hoping the graph turns around on its own is gambling, not diagnosing, and should work through the earlier steps before assuming time alone will fix it.
Step 11: Check for Lost Backlinks, Not Just Lost Internal Links
A migration that changes URL structure without airtight redirects doesn't just break internal navigation, it can also quietly sever external backlinks that were pointing at the old URLs. Pull your backlink profile from whatever tool you use before the migration and spot-check a sample of your highest-authority referring pages after the cutover to confirm they're landing on a 200-status page, not a 404 or a redirect to an unrelated destination. A handful of lost high-authority backlinks can account for a meaningful chunk of a ranking drop on its own, especially for pages that depended heavily on a small number of strong external links rather than a broad base of internal ones.
Step 12: Separate "New Site, Different Design" From "New Site, Different Content"
Migrations often bundle a visual redesign with actual content changes, trimmed copy, consolidated pages, removed sections that someone decided were redundant, and it's easy to blame the platform change when the real cause is that a page lost two-thirds of its text in the rewrite. Compare word count and heading structure between the old and new version of your most important pages. If content got meaningfully thinner during the redesign, that's a separate, very ordinary content-quality explanation that has nothing to do with redirects, rendering, or canonical tags, and it needs a content fix, not a technical one.
Building a Pre-Migration Checklist From This
The cheapest version of this entire process is running it before the migration instead of after. Map every existing URL to its new destination explicitly, test redirects and canonical tags on staging against a crawler, verify rendering and robots.txt behavior before the DNS cutover, and keep a pre-migration crawl archive specifically so you have something to compare against if traffic does drop. Add a backlink snapshot and a word-count snapshot of key pages to that same pre-migration archive, since both are exactly the kind of baseline you'll wish you had the moment traffic drops and someone asks what changed. A diagnostic process built from the start as a pre-flight checklist catches most of these issues before they ever reach production, which is a far cheaper place to catch them than two weeks into a traffic graph nobody can explain.
If your team is planning a migration or already dealing with a post-migration traffic drop, 137Foundry's technical SEO service handles exactly this kind of audit, and the broader services page covers the related web development work that often needs to happen alongside it. 137Foundry has run this process enough times to know which of the twelve steps above usually turns out to be the real culprit, and it's rarely the one the team suspects first, and it's almost never just one of them acting alone.
