What Causes Traffic Loss After a Site Migration (And How to Fix It)

Your site launched two weeks ago. Traffic looked fine for a few days. Then, quietly, it started falling.

By week three, you're down 35%. By week six, it's 50%. Google Search Console is full of 404 errors. The client is asking questions you don't have answers to.

This isn't unusual. Studies consistently show that 50–80% of site migrations result in measurable traffic loss. Some of it is temporary — Google needs time to recrawl and reprocess. But a lot of it is avoidable, caused by a handful of technical mistakes that are easy to prevent and hard to recover from once they're live.

This article covers the seven most common causes, how long each one takes to recover from, and what to do if you've already launched and traffic is falling.

---

The 7 Most Common Causes

1. Missing Redirects

The most common cause of traffic loss after a migration. When URLs change — because you restructured the site, moved to a new platform, or changed the URL format — Google treats the old URLs as deleted unless you redirect them.

Without a redirect, every inbound link and every ranking signal on /old-page is gone. Google sees a 404 and moves on. The page de-indexes. Rankings disappear.

What makes this tricky: It's rarely all the redirects that are missing. It's the long tail — the product pages you forgot about, the blog posts from three years ago, the PDFs in a directory no one documented. You implement 90% of the redirect map and miss 10%, which might account for 30% of your traffic.

Recovery time: 4–12 weeks after redirects are added, assuming no other issues.

---

2. Accidental noindex Tags

The second most common cause, and the one that causes pure panic.

During development, staging environments are typically blocked from search engines:

<meta name="robots" content="noindex, nofollow">

This is correct — you don't want Google indexing half-finished pages. The problem is when this tag makes it to production.

How it happens: the tag is in a template or environment config that doesn't get overridden correctly at launch. Or it's added to a new page template during development and nobody checks.

The result: Google crawls your site, sees noindex on every page, and stops indexing them. The pages disappear from search results within days. Organic traffic goes to zero for those pages.

What makes this tricky: It can be invisible. If you're looking at the page in a browser, it looks normal. The noindex is in the HTML source or HTTP headers, not visible in the rendered page.

Recovery time: 1–4 weeks after fixing, for pages that haven't had time to de-index. Longer if Google already removed them from the index.

---

3. Canonical Tag Problems

Canonical tags tell Google which URL to treat as the authoritative version of a page. Get them wrong and you split your ranking signals or direct Google to the wrong place.

Common canonical mistakes during migrations:

Staging canonical on production:

<!-- Bad: canonical pointing to staging -->
<link rel="canonical" href="https://staging.example.com/page" />

Google sees the production page but the canonical points to staging, which it (hopefully) can't access. It's confused. It may de-index the production page.

Canonical pointing to old domain: When migrating domains, canonical tags sometimes still reference the old domain. Google treats the new domain's content as a duplicate of the old one and doesn't index it.

Self-referencing canonical removed: Some migrations strip canonical tags as a "cleanup." Without canonicals, Google has to guess which URL is authoritative among variants (with/without trailing slashes, HTTPS vs HTTP, www vs non-www).

Recovery time: 2–8 weeks after fixing. Google needs to recrawl and update its index.

---

4. Title Tag and H1 Changes

Rankings are partially built on the words in your title tags and H1s. When a migration changes these, Google has to re-evaluate the page's relevance to its previous queries — and it often ranks lower while doing so.

This one is subtle. Your site isn't technically broken. Pages are indexed. Redirects work. But traffic drops 20–40% on pages where titles changed.

Common ways titles change during migrations:

• CMS template change: old template was {page title} | Brand, new is Brand | {page title} — keyword moved out of the most-important position
• Redesign removed keywords: old H1 was "Buy Blue Widgets – Free Shipping" and new H1 is "Products" (a design decision, not an SEO one)
• Auto-generated titles from a new platform that differ from manually-set titles on the old platform

Recovery time: 2–6 weeks if you revert to the original titles. If you keep the new titles, you're rebuilding rankings from scratch for affected queries — could be months.

---

5. robots.txt Blocking Crawlers

Similar to noindex, but at the crawl level. If robots.txt is misconfigured, Google can't reach your pages at all.

# Catastrophic: blocks everything
User-agent: *
Disallow: /

This gets deployed more often than you'd think. Staging environments are usually configured to block all crawlers. When the staging config gets promoted to production, the Disallow stays.

Unlike noindex, robots.txt blocking doesn't cause de-indexing immediately — Google keeps indexed URLs in search results until it can re-verify them. But clicks go to pages that now return as blocked, traffic tanks, and eventually Google removes them from the index.

Recovery time: 1–3 weeks after fixing. Google recrawls quickly once the block is removed.

---

6. Redirect Chains and Loops

When you set up redirects, the goal is: old URL → new URL, one hop.

Redirect chains are when you have: old URL → intermediate URL → new URL. Or worse, three or four hops. Google follows chains but loses PageRank at each step, and at some point stops following them altogether.

Chains often happen when:

• You're migrating a site that already had redirects from a previous migration
• You add new redirects without checking if the destination already redirects somewhere

Redirect loops are: A → B → A, or A → B → C → A. Google stops following after a few hops, the page returns no content, and de-indexing follows.

Recovery time: 1–4 weeks after fixing. The chain or loop itself is the damage — fixing it resolves quickly.

---

7. URL Structure Changes Without Content Parity

When a migration changes URL structure and content at the same time, rankings often drop even with correct redirects in place.

The redirect passes the authority signal, but Google revisits the destination page and finds different content than what it expected. If a /category/subcategory/product URL with detailed product content redirects to a /p/product-name URL with thin content, the ranking drop isn't from the redirect — it's from the content.

This is harder to catch in a pre-launch check because the redirects technically work. The regression is in content quality, not in technical SEO signals.

---

The Real Cost: Recovery Timelines

Traffic loss from a migration isn't just an inconvenience. It has a compound cost.

Google doesn't recrawl your entire site overnight. Fixes take time to be discovered, crawled, and processed. And some ranking signals, once lost, take months to rebuild.

The pattern: even when you fix the problem, recovery isn't immediate. A noindex tag that spent two weeks on production and de-indexed 200 pages takes another 1–4 weeks to recover. A title regression that drifted for two months may take another two months to return.

The fastest path to recovery is catching issues before they go live.

---

How to Catch Each Issue Before Go-Live

Redirects

Crawl the old site to get a complete URL inventory. Map every URL to its new equivalent. Before launch, test a representative sample:

curl -I https://staging.example.com/old-page
# Expect: HTTP/1.1 301 Moved Permanently
# Location: https://example.com/new-page

Don't just test the pages you remember — spot-check the long tail.

noindex tags

Check both the HTML source and HTTP response headers on production after launch. Don't rely on a staging check for this one.

curl -s https://example.com/page | grep -i "robots"
curl -I https://example.com/page | grep -i "x-robots"

Canonical tags

Check that every page's canonical points to the production URL — not staging, not the old domain, not a variant.

Title and H1 parity

Compare old and new environments systematically, not by clicking around. You're looking for any title or H1 that changed, and filtering out the intentional ones.

robots.txt

Read it. Every line. Then test it with Google's robots.txt Tester in Search Console.

Redirect chains

When you implement redirects, check whether the destination URL already redirects. If A → B and B → C, fix it to A → C before launch.

---

Automating Pre-Launch Checks

Going through these checks page-by-page is practical for a 50-page site. For anything larger, it's not.

PreflightSEO automates the comparison between old and new environments:

1. Point it at two base URLs — your old site and your staging/new site
2. It crawls both environments, matches pages automatically
3. Returns a severity-ranked list of regressions: missing pages, title changes, noindex surprises, canonical problems, redirect issues

The automatic matching handles the hard part — pairing old URLs with new URLs even when the URL structure changed, following redirects to find the final destination. You don't export CSVs or write formulas. You get a report.

See also: The Developer's SEO Migration Checklist for the full phase-by-phase workflow.

---

If You've Already Launched and Traffic Is Dropping

If traffic is already falling, here's how to diagnose which issue you're dealing with.

Step 1: Check if pages are still indexed

site:example.com

Does Google still show your pages? A sudden drop in indexed pages points to noindex, robots.txt, or a canonical problem.

Step 2: Check Google Search Console

Look at:

• Coverage report — Are there new "Excluded" pages? Look for "noindex" and "Blocked by robots.txt"
• 404 errors — A spike here means missing redirects
• Redirect errors — Chains or loops Google couldn't resolve

Step 3: Compare crawl data

Crawl the old site (from a recent backup or cached version) and the live site. Look for:

• URLs in the old crawl that are 404ing on the new site (missing redirects)
• Title or H1 differences on key pages
• Canonical discrepancies

Step 4: Fix by priority

Step 5: Request re-indexing

For critical pages, don't wait for Google's next crawl. Use the URL Inspection tool in Google Search Console to request indexing on high-priority pages after fixing issues.

Step 6: Monitor for 4 weeks

After fixing, track:

• Index status (are fixed pages returning to the index?)
• Organic traffic trend on affected pages
• Search Console coverage report (errors going down?)

Recovery isn't linear. Expect a few weeks of volatility before you see consistent improvement.

---

The Common Thread

Every issue on this list shares one characteristic: it's much faster to catch on staging than to fix in production.

A noindex tag in staging takes five minutes to find with a grep command. The same issue in production takes 4–6 weeks to recover from after you fix it — because Google has to recrawl, reprocess, and re-rank, and none of that happens overnight.

The calculus is simple: invest 1–2 hours in systematic pre-launch checks, or invest 1–3 months in post-launch recovery. Most teams that go through a traffic drop once become religious about pre-launch verification afterwards.