We Lost 95% of Our Google Traffic Overnight. Bing Still Ranks Us Top 3.

Between 16 and 17 April 2026, our Google organic traffic fell by about 95% — effectively overnight. No penalty, no warning. And the strangest part: Bing kept ranking the exact same pages in its top 3. This is the honest post-mortem — what broke (it was our own code), how we traced it to the hour, and what still hasn't recovered.

We build SEO, performance, and security modules for PrestaShop for a living. Having a traffic crash happen to our own store was humbling and, eventually, clarifying. So we're writing it down properly — including the parts we haven't fixed.

What it was NOT (the wrong turns we ruled out)

Most "traffic crash" advice sends you to these first. We went there too, and ruled them out:

• Not a penalty. No manual action in Search Console, no unnatural-links notice. The URL Inspection API showed our key pages still "Submitted and indexed." This was a ranking demotion, not a deindexing.
• Not (purely) an algorithm update. The March 2026 core update had completed around 8 April — eight days before our cliff — and we won't pretend that reprocessing context was irrelevant. But a core update rolling out over weeks doesn't explain daily impressions collapsing between two adjacent days. Something of ours lined up with the exact hour.
• Not primarily "thin content" — though that's a fair charge. If anything we had more content than our authority justified: ~150 module pages across six languages, plus blog, docs, FAQ. We think that footprint made recovery harder, and we treat "scaled/low-value content perception" as a live, unresolved hypothesis rather than something we can wave away.
• Not the obvious technical stuff. robots.txt was clean, the sitemap resolved, canonicals and hreflang (six locales + x-default) were correct.

The tell that reframed everything: Bing was ranking the exact same content in its top 3 — at a referring-domain profile so thin our third-party "authority" score is effectively zero. Same pages, two search engines, opposite outcomes. That is the fingerprint of a trust/authority verdict that a technical fault triggered — not a content-quality or speed problem in isolation.

The root cause: we shipped the bug ourselves (about 80% confidence)

Here's the part most vendor post-mortems would bury. The trigger was our own deploy.

Between 13 and 18 April we were changing our digital-product module — a new download controller, a "duplicate slug on install" fix, a server-rendered download button. Somewhere in that work, product-URL generation started throwing PrestaShop's Invalid product vars exception (in classes/Link.php). Our exception logs show the correlation to the hour:

The timing is brutal. We had just spiked into a young-site "honeymoon" — around 4,000–5,400 impressions a day at roughly position 10 in early April. That is precisely when Google was evaluating us hardest. And in that window, Googlebot hit ~1,000 broken internal product links a day. To a crawler, an internal link graph that suddenly points at broken product URLs during peak evaluation is a strong "this site just degraded" signal.

We call it ~80% confidence rather than certainty because it landed inside a genuinely noisy window — the completed core update, a spam update, honeymoon expiry, and recurring server/DB outages of our own (mid-March, 14–16 April, and again in June). Any of those compounds a trust hit. But only the Link.php error count lines up day-for-day with the cliff. The honest verdict: a self-inflicted technical trigger, detonating inside a young-site, low-authority, post-core-update context.

The bucket that actually explains a −95%: "Crawled — currently not indexed"

If you take one diagnostic lesson from this, take this one. In Search Console's index-coverage report, the bucket that matters isn't "404" or "5xx." It's "Crawled — currently not indexed" — roughly 22,800 URLs.

An honest nuance, because we checked our own history: this bucket did not "balloon" on crash night. We first saw it back in February 2025, it peaked near 60k, and it has been slowly draining to ~22.8k. The overnight cliff itself was a ranking demotion of pages that stayed indexed — daily impressions of ~5,400 at position ~10 falling to 161 the next day at position 27. The crawled-not-indexed bucket isn't the mechanism of the overnight drop; it's where the longer-term trust verdict is visible. We verified a sample of those 22.8k pages are 200, index,follow, self-canonical, content-rich. Google crawled tens of thousands of technically-clean pages and chose not to index them.

Recovery, part 1: make the technical slate genuinely clean

You can't ask Google to re-evaluate a site while it's still tripping over errors. So phase one was ruthless hygiene — every fixable technical defect fixed and verified live, not just "shipped" (the trust bucket in the next section is a separate, non-technical problem):

• The Link.php trigger: fixed first — 0 errors since May, products render full 200 HTML.
• 404s: genuine-404 vs renamed-slug separated; old slugs 301'd to current canonicals (one hop, localized).
• Faceted URLs: valid combinations to 200 + noindex,follow, stale ones 301 — humans filter, crawlers don't drown.
• 5xx: a cross-language casing-skew autoload fatal fixed with a fail-safe.
• Redirect chains: collapsed to a single hop, resolved at emit time.
• Structured data: exactly one brand per product and description length capped (the two errors actually costing rich results).
• Assets: removed per-file ?v= cache-busting so PrestaShop's native combine-minify works.
• Heading hierarchy: one <h1> per page, clean H1 → H2 → H3.

Recovery, part 2: don't re-crawl into a mess — the "freeze gate"

Here's the discipline most recovery stories skip. Before re-submitting anything to Google, we treat the sitemap and indexing pipeline as a gate: nothing gets asked-to-be-indexed unless it's provably clean.

• The sitemap is regenerated and every URL independently verified — 200, index,follow, self-canonical, correct hreflang, valid schema. Ours settled at 4,952 URLs across six languages.
• The indexing queue only ever submits URLs that are currently indexable canonicals, with a per-URL guard at submit time — not a blind firehose.

Auditing every sitemap URL through that guard caught three bugs that would have quietly wasted the entire re-crawl: our internal page registry was missing 918 sitemap URLs — including the entire 882-URL documentation set; three FAQ pages were wrongly flagged noindex from a missing shop-association row; and blog posts were being misrouted to noindex by a classifier matching support-like keywords before the blog route. We demanded a zero-blocked result — every one of the 4,952 URLs passing the guard — before calling the gate closed.

The lesson: re-earning trust means the next thing Google sees must be immaculate. One more round of "please index our broken stuff" digs the hole deeper.

What we now alert on

The failure was invisible for days because nothing screamed. What we monitor now:

• Killer-class exception alerting on Link.php / dispatcher slug-miss — any spike pages us, not a weekly log read.
• GSC + Bing crawl-stats trend watched weekly, side by side — the Bing/Google divergence is our earliest trust signal.
• Availability watchdog on the origin — our outages were part of the wound, so uptime is a first-class SEO metric now.
• Sitemap/registry parity check — the guard that found the missing 918 runs continuously.

What is honestly NOT recovered (yet)

This is where most "how I recovered" posts get dishonest. We won't.

• Rankings and traffic have not returned. The technical slate is clean and verified, but Google still declines to index most of what it crawls, and position has kept drifting rather than snapping back.
• Off-page is our real ceiling. Our referring-domain profile is thin — the same content Bing ranks top-3, Google won't. A clean site with weak external validation is exactly what "crawled, not indexed" looks like.
• Our non-English locales are dead weight. They earn impressions but almost no clicks; only English and Polish genuinely convert. Scaling machine-translated pages was part of the over-large footprint, not an asset.
• The fix from here is not technical. It's authority and time: real experience-and-expertise signals, earned links from the PrestaShop ecosystem, and letting a clean site prove itself once we re-open indexing through the guarded queue.

We're publishing this now, mid-recovery, precisely because a post-mortem written after a full recovery is a survivorship-biased fairy tale. This is what it actually looks like from inside one.

If this is happening to your PrestaShop store

• Check Bing. If Bing ranks your content and Google doesn't, stop blaming content and speed — it's trust, and something technical likely triggered it.
• Read your own deploy log against your traffic graph. Our smoking gun was an exception count that lined up with the cliff to the day. Yours might be too.
• Read the index-coverage buckets, not just the traffic line. "Crawled — not indexed" at scale is a quality signal, not a bug to fix.
• Fix and verify live — origin-direct, not "it should be fixed."
• Don't re-crawl into a mess. Prove your sitemap and submission set are immaculate before asking Google to look again.
• Then be patient and build authority. There is no code fix for trust.

If your store shows this same pattern — clean on the surface, ignored by Google, fine on Bing — our PrestaShop SEO Audit maps exactly which of these failure modes is hitting you, on-site and off. It's the same forensic process we used on ourselves, above.