Wir haben über Nacht 95% unseres Google-Traffics verloren. Bing rankt uns weiter in den Top 3.

Zwischen dem 16. und 17. April 2026 brach unser organischer Google-Traffic um etwa 95% ein — praktisch über Nacht. Keine Abstrafung, keine Warnung. Und das Merkwürdigste: Bing rankte exakt dieselben Seiten weiterhin in seinen Top 3. Dies ist das ehrliche Post-Mortem — was kaputtging (es war unser eigener Code), wie wir es auf die Stunde genau zurückverfolgt haben und was sich bis heute nicht erholt hat.

Wir entwickeln beruflich SEO-, Performance- und Sicherheitsmodule für PrestaShop. Dass ein Traffic-Einbruch ausgerechnet unseren eigenen Shop traf, war demütigend — und am Ende erhellend. Deshalb schreiben wir es sauber auf, einschließlich der Teile, die wir noch nicht behoben haben.

Was es NICHT war (die Irrwege, die wir ausgeschlossen haben)

Die meisten Ratgeber zu „Traffic-Einbrüchen“ schicken einen zuerst genau dorthin. Wir waren auch dort — und haben es ausgeschlossen:

• Keine Abstrafung. Keine manuelle Maßnahme in der Search Console, kein Hinweis auf unnatürliche Links. Die URL-Inspection-API zeigte unsere wichtigsten Seiten weiterhin als „Eingereicht und indexiert“. Es war eine Ranking-Herabstufung, keine Deindexierung.
• Kein (reines) Algorithmus-Update. Das Core Update vom März 2026 war tatsächlich um den 8. April abgeschlossen — acht Tage vor unserem Absturz — und wir tun nicht so, als wäre dieser Reprocessing-Kontext irrelevant gewesen. Aber ein Core Update, das über Wochen ausgerollt wird, erklärt nicht, warum tägliche Impressionen zwischen zwei aufeinanderfolgenden Tagen kollabieren. Etwas von uns passte auf die Stunde genau ins Bild.
• Nicht primär „Thin Content“ — auch wenn der Vorwurf berechtigt ist. Wenn überhaupt, hatten wir mehr Inhalte, als unsere Autorität rechtfertigte: ~150 Modulseiten in sechs Sprachen, dazu Blog, Doku, FAQ. Wir glauben, dass dieser Fußabdruck die Erholung erschwert hat, und behandeln die Wahrnehmung als „skalierter Low-Value-Content“ als offene, ungelöste Hypothese — nicht als etwas, das man wegwischen kann.
• Nicht die offensichtlichen technischen Dinge. robots.txt war sauber, die Sitemap erreichbar, Canonicals und hreflang (sechs Locales + x-default) korrekt.

Das Indiz, das alles neu einordnete: Bing rankte exakt denselben Content in seinen Top 3 — bei einem so dünnen Profil verweisender Domains, dass unser externer „Authority“-Score praktisch null ist. Dieselben Seiten, zwei Suchmaschinen, gegensätzliche Ergebnisse. Das ist der Fingerabdruck eines Vertrauens-/Autoritätsurteils, das ein technischer Fehler ausgelöst hat — kein isoliertes Content-Qualitäts- oder Geschwindigkeitsproblem.

Die Ursache: Wir haben den Bug selbst ausgeliefert (Konfidenz etwa 80%)

Hier kommt der Teil, den die meisten Anbieter-Post-Mortems verstecken würden. Der Auslöser war unser eigenes Deployment.

Zwischen dem 13. und 18. April haben wir an unserem Digitalprodukt-Modul gearbeitet — ein neuer Download-Controller, ein Fix für „duplicate slug on install“, ein serverseitig gerenderter Download-Button. Irgendwo in dieser Arbeit begann die Produkt-URL-Generierung, PrestaShops Invalid product vars-Exception zu werfen (in classes/Link.php). Unsere Exception-Logs zeigen die Korrelation auf die Stunde genau:

Das Timing ist brutal. Wir waren gerade in die „Honeymoon“-Phase einer jungen Site hineingeschossen — rund 4,000–5,400 Impressionen pro Tag bei ungefähr Position 10 Anfang April. Genau in dieser Phase bewertete Google uns am strengsten. Und genau in diesem Fenster traf der Googlebot auf ~1,000 kaputte interne Produktlinks pro Tag. Für einen Crawler ist ein interner Linkgraph, der während der intensivsten Bewertungsphase plötzlich auf kaputte Produkt-URLs zeigt, ein starkes Signal: „Diese Site hat sich gerade verschlechtert.“

Wir sprechen von ~80% Konfidenz statt Gewissheit, weil das Ganze in ein wirklich verrauschtes Fenster fiel — das abgeschlossene Core Update, ein Spam Update, das Ende der Honeymoon-Phase und wiederkehrende Server-/DB-Ausfälle bei uns selbst (Mitte März, 14.–16. April und erneut im Juni). Jeder dieser Faktoren verstärkt einen Vertrauensschaden. Aber nur die Link.php-Fehlerzahl deckt sich Tag für Tag mit dem Absturz. Das ehrliche Urteil: ein selbst verursachter technischer Auslöser, detoniert im Kontext einer jungen Site mit geringer Autorität kurz nach einem Core Update.

Der Bucket, der ein −95% wirklich erklärt: „Gecrawlt – zurzeit nicht indexiert“

Wenn Sie aus diesem Text eine einzige diagnostische Lektion mitnehmen, dann diese. Im Indexabdeckungs-Bericht der Search Console ist der entscheidende Bucket nicht „404“ oder „5xx“. Es ist „Gecrawlt – zurzeit nicht indexiert“ — rund 22,800 URLs.

Eine ehrliche Nuance, weil wir unsere eigene Historie geprüft haben: Dieser Bucket ist in der Crash-Nacht nicht „explodiert“. Wir sahen ihn erstmals im Februar 2025, er erreichte seinen Höchststand nahe 60k und ist seitdem langsam auf ~22.8k abgeschmolzen. Der Absturz über Nacht selbst war eine Ranking-Herabstufung von Seiten, die indexiert blieben — tägliche Impressionen von ~5,400 bei Position ~10 fielen am nächsten Tag auf 161 bei Position 27. Der Crawled-not-indexed-Bucket ist nicht der Mechanismus des nächtlichen Einbruchs; er ist der Ort, an dem das längerfristige Vertrauensurteil sichtbar wird. Wir haben eine Stichprobe dieser 22.8k Seiten verifiziert: 200, index,follow, self-canonical, inhaltlich substanziell. Google hat Zehntausende technisch saubere Seiten gecrawlt und sich entschieden, sie nicht zu indexieren.

Erholung, Teil 1: eine wirklich saubere technische Basis schaffen

Man kann Google nicht um eine Neubewertung bitten, während die Site noch über Fehler stolpert. Phase eins war also rücksichtslose Hygiene — jeder behebbare technische Defekt behoben und live verifiziert, nicht nur „deployt“ (der Vertrauens-Bucket im nächsten Abschnitt ist ein separates, nicht-technisches Problem):

• Der Link.php-Auslöser: zuerst behoben — 0 Fehler seit Mai, Produkte rendern volles 200-HTML.
• 404s: echte 404 von umbenannten Slugs getrennt; alte Slugs per 301 auf die aktuellen Canonicals (ein Hop, lokalisiert).
• Facetten-URLs: gültige Kombinationen auf 200 + noindex,follow, veraltete auf 301 — Menschen filtern, Crawler ertrinken nicht.
• 5xx: ein sprachübergreifender Autoload-Fatal durch abweichende Groß-/Kleinschreibung, behoben mit einem Fail-Safe.
• Redirect-Ketten: auf einen einzigen Hop kollabiert, aufgelöst zum Zeitpunkt der Ausgabe.
• Strukturierte Daten: exakt ein brand pro Produkt und die Beschreibungslänge gedeckelt (die zwei Fehler, die uns tatsächlich Rich Results kosteten).
• Assets: das ?v=-Cache-Busting pro Datei entfernt, damit PrestaShops natives Combine-Minify funktioniert.
• Überschriften-Hierarchie: ein <h1> pro Seite, sauberes H1 → H2 → H3.

Erholung, Teil 2: nicht ins Chaos re-crawlen lassen — das „Freeze Gate“

Hier kommt die Disziplin, die die meisten Recovery-Geschichten überspringen. Bevor wir irgendetwas erneut bei Google einreichen, behandeln wir Sitemap und Indexierungs-Pipeline als Gate: Nichts wird zur Indexierung angemeldet, was nicht nachweislich sauber ist.

• Die Sitemap wird neu generiert und jede URL unabhängig verifiziert — 200, index,follow, self-canonical, korrektes hreflang, valides Schema. Bei uns pendelte sie sich bei 4,952 URLs in sechs Sprachen ein.
• Die Indexierungs-Queue reicht ausschließlich URLs ein, die aktuell indexierbare Canonicals sind, mit einem Guard pro URL zum Zeitpunkt der Einreichung — kein blindes Dauerfeuer.

Der Audit jeder Sitemap-URL durch diesen Guard fand drei Bugs, die den gesamten Re-Crawl stillschweigend verschwendet hätten: In unserer internen Seiten-Registry fehlten 918 Sitemap-URLs — darunter das komplette Dokumentationsset mit 882 URLs; drei FAQ-Seiten waren wegen einer fehlenden Shop-Zuordnungszeile fälschlich als noindex markiert; und Blogposts wurden von einem Klassifizierer, der support-ähnliche Keywords vor der Blog-Route matchte, fälschlich auf noindex geleitet. Wir haben ein Zero-Blocked-Ergebnis verlangt — jede einzelne der 4,952 URLs muss den Guard passieren — bevor wir das Gate als geschlossen betrachteten.

Die Lektion: Vertrauen zurückzugewinnen heißt: Das Nächste, was Google sieht, muss makellos sein. Noch eine Runde „bitte indexiert unsere kaputten Seiten“ gräbt das Loch nur tiefer.

Was uns jetzt sofort alarmiert

Der Fehler blieb tagelang unsichtbar, weil nichts Alarm schlug. Was wir jetzt überwachen:

• Alerting auf Exceptions der Killer-Klasse auf Link.php / Dispatcher-Slug-Miss — jeder Ausschlag alarmiert uns sofort, statt wöchentlicher Log-Lektüre.
• GSC- und Bing-Crawl-Statistiken wöchentlich nebeneinander beobachtet — die Bing/Google-Divergenz ist unser frühestes Vertrauenssignal.
• Availability-Watchdog auf dem Origin — unsere Ausfälle waren Teil der Wunde, Uptime ist jetzt eine SEO-Metrik erster Klasse.
• Sitemap/Registry-Paritätscheck — der Guard, der die fehlenden 918 fand, läuft kontinuierlich.

Was ehrlicherweise (noch) NICHT wiederhergestellt ist

An dieser Stelle werden die meisten „So habe ich mich erholt“-Posts unehrlich. Wir nicht.

• Rankings und Traffic sind nicht zurückgekehrt. Die technische Basis ist sauber und verifiziert, aber Google lehnt es weiterhin ab, das meiste Gecrawlte zu indexieren, und die Position driftet weiter, statt zurückzuschnappen.
• Off-Page ist unsere eigentliche Decke. Unser Profil verweisender Domains ist dünn — denselben Content, den Bing in den Top 3 rankt, will Google nicht. Eine saubere Site mit schwacher externer Validierung ist exakt das, wonach „gecrawlt, nicht indexiert“ aussieht.
• Unsere nicht-englischen Sprachversionen sind Ballast. Sie sammeln Impressionen, aber kaum Klicks; nur Englisch und Polnisch konvertieren wirklich. Maschinell übersetzte Seiten zu skalieren war Teil des zu großen Fußabdrucks, kein Asset.
• Der Fix ab hier ist nicht technisch. Es geht um Autorität und Zeit: echte Signale für Erfahrung und Expertise, verdiente Links aus dem PrestaShop-Ökosystem — und einer sauberen Site die Chance geben, sich zu beweisen, sobald wir die Indexierung über die bewachte Queue wieder öffnen.

Wir veröffentlichen das jetzt, mitten in der Erholung — genau weil ein Post-Mortem, das erst nach vollständiger Erholung geschrieben wird, ein Märchen mit Survivorship-Bias ist. So sieht es von innen tatsächlich aus.

Wenn das gerade Ihrem PrestaShop-Shop passiert

• Prüfen Sie Bing. Wenn Bing Ihren Content rankt und Google nicht: Hören Sie auf, Content und Speed zu beschuldigen — es ist Vertrauen, und ausgelöst hat es vermutlich etwas Technisches.
• Legen Sie Ihr Deploy-Log neben Ihren Traffic-Graphen. Unsere Smoking Gun war eine Exception-Zahl, die sich auf den Tag genau mit dem Absturz deckte. Ihre vielleicht auch.
• Lesen Sie die Indexabdeckungs-Buckets, nicht nur die Traffic-Linie. „Gecrawlt – nicht indexiert“ in großem Maßstab ist ein Qualitätssignal, kein Bug zum Fixen.
• Fixen und live verifizieren — direkt am Origin, nicht „müsste jetzt behoben sein“.
• Nicht ins Chaos re-crawlen lassen. Beweisen Sie, dass Sitemap und Einreichungsset makellos sind, bevor Sie Google um einen zweiten Blick bitten.
• Dann: Geduld und Autoritätsaufbau. Es gibt keinen Code-Fix für Vertrauen.

Wenn Ihr Shop dasselbe Muster zeigt — oberflächlich sauber, von Google ignoriert, auf Bing in Ordnung — zeigt unser PrestaShop SEO Audit exakt, welcher dieser Fehlermodi Sie trifft, on-site wie off-site. Es ist derselbe forensische Prozess, den wir oben auf uns selbst angewendet haben.