Why Your Traffic Drops After a Migration, and How to Actually Find Out

Every migration post-mortem I’ve seen starts the same way: “check your redirects.” That’s real advice, and it’s also about a third of the actual checklist. Redirects are the part everyone remembers because they’re the most obvious failure mode. They’re rarely the only one, and treating them as the whole problem is why a lot of “we fixed the redirects” migrations still never recover their traffic.

Here’s the fuller list I actually go through, roughly in the order I check it.

1. Redirects, but the whole chain, not just the first hop

A single 301 from the old URL to the new one is the easy case. What actually happens on most migrations is a chain: old URL redirects to an intermediate URL, which redirects to the final one, sometimes three or four hops deep, often because a previous migration’s redirects never got cleaned up. Google will follow a reasonable number of hops, but each one dilutes signal and slows crawling. If your migration is layered on top of an older one nobody cleaned up, this is usually where I find the first real problem.

2. Robots.txt left over from staging

This is the one that costs people the most traffic and takes the least time to find. A staging environment almost always has a robots.txt blocking all crawlers, which is correct while it’s staging. When staging becomes production, that file sometimes comes with it. I’ve seen entire sites deindex within two weeks because of a single leftover Disallow: / line. Check this before anything else.

3. Canonical tags still pointing at the old domain or URL structure

If your CMS or theme change didn’t explicitly update canonical tags, they can keep referencing the pre-migration URLs. Google reads that as “this page isn’t actually the authoritative version,” and will often keep indexing the old, now-404ing URL instead of the new one. This is invisible in a normal page review because the page looks fine, you have to check the actual canonical tag in the source.

4. XML sitemap never resubmitted, or still listing old URLs

A sitemap generated before the migration and never regenerated is actively telling Google to keep checking URLs that no longer exist, while never mentioning the new ones. Regenerate it, resubmit it in Search Console, and check the coverage report a week later to see whether Google’s actually picked up the new structure.

5. Internal links still pointing to pre-migration URLs

Even with redirects in place, internal links pointing to old URLs mean every internal link is now passing through an unnecessary redirect hop, and on a large site, that adds up to a meaningful crawl budget and link equity loss. This is tedious to fix and easy to skip, which is exactly why it’s usually still broken when I check.

Want to check your own site while you’re reading this? My free Technical SEO Auditor flags broken redirects, missing canonicals, and crawl issues in about five minutes, no signup.

6. Lost backlinks pointing at now-404ing pages

If a page changed URL structure and the redirect wasn’t caught, any external site linking to the old URL is now sending link equity into a 404. Run your existing backlink profile against the new site structure and check that every meaningfully-linked page actually redirects somewhere real.

What I’d actually do first

Pull the full crawl of the pre-migration site if you still have it, or from an archive if you don’t, and diff it against the current site’s crawl. Every URL that existed before and doesn’t now needs an answer: where does it redirect, and does that redirect make sense. That single exercise catches most of the six problems above in one pass, instead of checking each one separately.

If this is where you are right now, traffic down since a migration and no clear answer why, this is close to exactly what a technical audit is for. I’d rather find the specific answer than guess at it.