Three weeks after a routine platform migration, an outdoor gear retailer’s organic traffic started sliding. Rankings looked fine. Redirects checked out. Every page a human clicked on loaded exactly as it should. And yet Google Search Console kept reporting that hundreds of live, revenue-generating pages did not exist.
That contradiction is the whole story. When a site is broken, it’s usually broken for everyone, humans and crawlers alike. This time, only Googlebot was being lied to.
When “everything looks fine” is the warning sign
The retailer’s SEO lead had done the migration checklist correctly. Every old URL had a 301 redirect mapped to its new equivalent. Title tags stayed untouched, on purpose, since changing them mid-migration muddies the signal when something else goes wrong. Staging tests passed. The launch weekend was quiet.
Then, in early September, year-over-year organic sessions dipped about 20 percent. Two weeks later, after a round of “wait and see,” the dip became a 40 percent drop. No manual action notice. No algorithm update on record for that window. No obvious content quality issue. Just fewer visitors, arriving on fewer pages, month over month.
Isolating the actual mechanism, not the usual suspects
Most traffic-drop investigations start with a mental checklist: core update, penalty, cannibalization, lost backlinks. Running through all of them on a large catalog site can burn a week before you learn anything. A faster approach is to separate the two things a traffic drop can actually be made of:
- Fewer pages earning any clicks at all, which usually points to an indexing problem
- Fewer clicks per page that’s still ranking, which usually points to a content or relevance problem
The team pulled landing-page sessions from Google Analytics and page counts from the Search Console Page Indexing report, then plotted both over the same timeline. The answer was immediate. Clicks per indexed page had barely moved. The number of pages actually eligible to rank had fallen off a cliff.
Ruling out the obvious culprit
The next stop was checking for an infinite crawl space, the trap where faceted navigation or filter combinations generate an effectively endless set of near-duplicate URLs that drain crawl budget. It wasn’t the cause here. Parameter counts were proportional to the actual number of product variants. No runaway URL space, no crawl trap.
The moment the bug became visible
The Page Indexing report showed a growing list of URLs marked Not found (404), and every single one of them was a page the team had personally redirect-mapped during the migration. Clicking through to a handful, the pages loaded. Correct content, correct layout, correct price, no errors.
The confirmation came from opening the Network tab in Chrome DevTools and checking the raw server response headers rather than the rendered page. The server was returning a 404 Not Found status code on pages that were serving fully functional content.
That’s the phantom 404: a page that is visibly, humanly fine, while the HTTP header underneath it is telling every crawler on the internet that it doesn’t exist.
Why this is rare, and dangerous precisely because it’s rare
Most indexing problems announce themselves. A blocked robots.txt line, an accidental noindex tag, a broken redirect chain. A status code mismatch hides in a different layer entirely: the CDN edge configuration, an application server rule that fires only for specific URL patterns, or a caching layer that serves stale headers while the page body updates normally.
Google treats a 404 as a strong, fast signal. On a large site, the grace period before pages drop out of the index isn’t nearly enough time for a human to notice a pattern across hundreds of URLs, especially when every one of those URLs looks perfectly healthy in a browser tab.
The fix, and the second bug it exposed
The development team traced the mismatch to a caching rule introduced during the platform switch. Product pages with recently changed inventory status were served through a code path that defaulted to a 404 header whenever a product-availability flag was momentarily null during a cache refresh. Fixing it meant generating the HTTP status code from the same data source as the page content.
While validating the fix, the team found a second issue: several original 301 redirects were stripping query parameters used for campaign tracking, quietly corrupting paid search attribution. Both issues were resolved in the same sprint.
What changed after the fix
- Indexed page count returned to its pre-migration baseline within roughly three weeks
- Organic sessions climbed back past year-over-year parity by the following month, then settled above the prior year
- Paid search attribution accuracy improved immediately once the parameter-stripping redirects were corrected
How to check your own site for this
- Compare indexed page counts to sessions-per-page trends: falling pages with stable per-page performance means indexing, not content
- Cross-reference Page Indexing errors against your sitemap: a 404 on a URL you know is live is the flag
- Check raw response headers, not rendered pages (DevTools Network tab or curl)
- Re-check after any CDN, caching or platform change, even ones that seem unrelated to SEO
- Don’t stop at the first bug you find
Search Console’s Page Indexing report is often treated as a monitoring dashboard. Used as a diagnostic tool instead, cross-referenced against real user data and verified at the raw HTTP level, it can surface the exact category of bug that no amount of content strategy or link building would ever have caught.