The Site Migration Looked Perfect. Then the Traffic Just Vanished.

Launch day looked flawless. The redirects were mapped, the staging site passed QA, analytics kept ticking, and for three weeks the organic line held steady. Then, somewhere around week four, it fell off a cliff.

This is the migration failure almost nobody plans for, because it does not look like a technical failure at all. Everything shipped. Nothing threw an error. And yet pages were quietly leaving Google the whole time.

First, the part that is actually normal

Site migrations disrupt signals Google has spent months or years building confidence in. Rankings do not transfer automatically when you move. They are rebuilt through crawling, indexing, and re-evaluation, and that takes time even when the migration is executed perfectly.

So some post-migration dip is normal and temporary. If you moved domains or replatformed and traffic softened for a couple of weeks before recovering, that is Google catching up, not a crisis.

The failure mode this article is about is different. It is not your pages ranking lower. It is your pages falling out of the index entirely, and staying out.

Why the drop shows up in week four, not week one

Traffic is a lagging indicator. When a page silently de-indexes, it does not vanish from analytics the next morning. It keeps drawing residual clicks and impressions on momentum while Google slowly stops serving it.

By the time the organic line visibly cracks, the de-indexing happened weeks earlier. You are not watching the event. You are watching the aftermath. That lag is exactly why teams celebrate a "clean" migration and then get blindsided a month later.

The signal that would have warned you in week one was never traffic. It was your indexed-page count.

The four silent culprits

Silent post-migration de-indexing almost always traces back to one of four causes. Each has a tell-tale symptom, and each hides somewhere your launch QA probably did not look.

• Broken or chained redirects. The tell: URLs that return a 404, or a redirect that hops through three URLs before landing. Where it hides: the long tail. Your top 20 pages got mapped by hand. The other 4,000 got a wildcard rule that did not cover every old pattern, so they quietly resolve to nothing.
• Orphaned URLs with no internal links. The tell: a page exists and returns 200, but nothing links to it anymore. Where it hides: the new navigation and templates. If a URL is reachable only by typing it directly, Google struggles to keep re-finding it, and eventually stops.
• Changed or wrong canonicals. The tell: new pages carrying a canonical tag that points back at the old URL. Where it hides: the CMS migration itself. Canonicals get carried over or auto-generated incorrectly, and you are effectively telling Google the new page is a duplicate of a URL that no longer exists.
• Template-level noindex or robots blocks. The tell: a noindex meta tag or a Disallow shipped across a whole template. Where it hides: staging config that leaked to production. The noindex you added to keep staging out of Google rode along to the live site, and one template change silently suppressed thousands of pages at once.

The through-line: none of these throw a visible error. The site looks fine to a human clicking around. The damage only shows up when you check what Google can actually index.

We go deeper on the mechanics in Pages Deindexed After a Site Migration.

The First-Week Migration Index Audit

Run this in the first seven days after launch, before traffic has a chance to lie to you. It takes an afternoon and catches the vast majority of silent de-indexing.

• Verify redirects resolve to 200. Crawl your full list of old URLs and confirm each one lands on a live new page with a single hop, not a 404 and not a redirect chain.
• Confirm canonicals point to the new URLs. Spot-check templates and key pages. Every canonical should reference the current live URL, never an old or pre-migration one.
• Find orphaned URLs. Compare your sitemap and old URL inventory against your internal link graph. Anything indexed but not linked from anywhere is at risk.
• Check for template-level noindex and robots blocks. Inspect the raw HTML and headers on each template type, plus robots.txt. One stray directive can suppress an entire section.
• Baseline your indexed-page count. Record how many pages Google has indexed on day one. This number is your control. If it starts sliding, you have your early warning weeks before traffic reacts.

Watch the index, not just the traffic

Here is the reframe worth keeping. Traffic is a lagging indicator. Index status is the leading one.

If you only watch analytics, you find out about de-indexing after it has already cost you. If you watch your indexed-page count, you see pages leaving while there is still time to fix the redirect, restore the link, or strip the stray noindex and request re-indexing.

That is the difference between a bad week and a bad quarter. The same principle applies well beyond migrations, which is why silent de-indexing is worth catching before traffic falls on any site, at any time.

Nobody caught it because nobody was watching

The uncomfortable truth about most post-migration disasters is not that the team was careless. It is that no one was watching per-URL index status on a schedule. The launch checklist was a one-time snapshot. De-indexing is a process that unfolds over days.

That gap between a single launch-day check and continuous observation is exactly what monitoring closes. SearchOptimo re-checks your URLs for index status on a schedule and alerts you the moment pages start dropping out, so week-one problems surface in week one instead of week four. You can see the whole arc of what stayed in and what fell out on an index history timeline, and route the drops straight into de-indexing alerts.

The one thing to take away

A perfect-looking migration and a healthy migration are not the same thing. The gap between them is measured in indexed pages, not page views.

Be honest with yourself about the normal part: some dip while Google rebuilds confidence is expected, and recovery is not guaranteed or instant even when you fix everything. But separate that from the failure mode. A steady dip that stabilizes is recovery. A decline paired with a falling indexed-page count is de-indexing, and it will not fix itself.

Watch the leading indicator. Baseline your indexed pages before your next migration, and let the traffic take care of itself.