Mein Error Tracker explodierte um 2 Uhr nachts. Der Angreifer war ein SEO-Tool.

Mein Handy hat um 2 Uhr nachts vibriert. Fünf neue Issues im Error Tracker einer Kundenseite. Fünf. Die Seite gehört einem US-Vermieter von Sanitäranhängern, die Art Kunde, die anruft, wenn ein Formular kaputt ist. Mein erster Gedanke: Das Deployment von gestern hat etwas zerschossen, und morgen früh wartet ein Postfach voller wütender Mails.

Ich bin aufgestanden. Ich habe Kaffee gemacht. Ich habe alle fünf Issues triagiert.

Kein einziges davon war ein echter Bug. Ich erzähle dir, was wirklich passiert ist, denn wenn du Websites für Kunden betreust, wird dir das auch passieren. Und der naheliegende Fix, Bots bei Cloudflare zu blocken, entpuppt sich als Falle.

Fünf Fehler, null Bugs

Kurz zum Setup: Der Kunde betreibt eine Next.js-Seite mit hunderten Location-Landingpages. Für Error Tracking nutze ich Bugsink, ein selbst gehostetes, Sentry-kompatibles Tool, weil ich lieber meinen eigenen Server bezahle als noch ein SaaS-Abo. Gleiches SDK, gleiche Dashboards, gleiche 2-Uhr-Alerts.

Hier die komplette Liste dessen, was mich geweckt hat:

1. "Google Maps failed to load", zweimal, auf einer Location-Seite
2. "Failed to fetch ct.pinterest.com", neunmal, auf der Google-Ads-Landingpage
3. Minified React error #454, einmal
4. Minified React error #418, ein Hydration-Fehler, einmal
5. "Can't find variable: data", einmal, in einer Funktion namens refreshToken

Der letzte hätte mich fast erwischt. Die Seite hat keine refreshToken-Funktion. Nirgendwo. Ich habe um 2:30 Uhr die komplette Codebase durchsucht, um sicherzugehen.

Vierzehn Events. Null echte Nutzer betroffen. Null Zeilen meines Codes schuld. Kommt dir das bekannt vor?

Die Triage: Jeder "Fehler" im Einzelnen

Der Pinterest-Fehler war der einfachste, und der ironischste. Neun Events, alle von Besuchern über bezahlte Google Ads. Deren Adblocker killen das Pinterest-Tracking-Pixel, der Fetch des Pixels schlägt fehl, das SDK meldet es brav. Denk mal drüber nach: Die teuersten Besucher der Seite, die, für die der Kunde Google bezahlt, werfen die meisten Fehler. Weil sie Adblocker nutzen. Die Fehler sind buchstäblich ein Zeichen dafür, dass das Marketing funktioniert.

Der "Can't find variable: data"-Fehler hat länger gedauert. Der Stack Trace zeigte auf webkit-masked-url://hidden/. Falls du diesen String noch nie gesehen hast: WebKit versteckt damit absichtlich die URL von Safari-Extension-Code, damit Websites nicht fingerprinten können, welche Extensions ein Nutzer installiert hat. Das heißt: Ein Fehler mit diesem Stack Frame kann nicht dein Code sein. Irgendeine Extension auf irgendeinem Mac hat eine kaputte refreshToken-Funktion, und mein Error Tracker hat sie eingefangen, als wäre es mein Problem.

Der Maps-Fehler und die beiden React-Fehler hatten denselben Verursacher. Beide Maps-Events kamen vom selben User Agent: SEBot-WA.

Ich kannte ihn auch nicht.

Darf ich vorstellen: SEBot-WA, das SEO-Tool, das meine Nacht ruiniert hat

SEBot-WA ist der Crawler hinter SE Rankings Website-Audit-Tool. Er ist legitim, er benimmt sich, und er hat eine Eigenschaft, die ihn unter SEO-Crawlern besonders macht: Er rendert JavaScript in einem Headless Browser, statt nur HTML abzurufen.

Genau deshalb hat er meine Alarme ausgelöst. Ein Headless Browser, der eine React-App nur teilweise, in falscher Reihenfolge oder mit blockierten Skripten ausführt, produziert Fehler, die kein menschlicher Besucher jemals sieht. Das Maps-Skript läuft in einen Timeout, mein onerror-Handler feuert, das SDK meldet es. Der Crawler rendert eine Seite nur halb, React gerät in Panik, Fehler #454 landet in meinem Dashboard.

Und hier das Detail, über das ich um 3 Uhr nachts lachen musste: SEBot-WA crawlt nur Seiten, die jemand explizit zu einem SE-Ranking-Audit-Projekt hinzugefügt hat. Ich habe diese Seite nicht hinzugefügt. Der Kunde auch nicht. Das heißt: Wahrscheinlich lässt gerade ein Wettbewerber ein SEO-Audit über die Seite meines Kunden laufen. Irgendjemand da draußen hat für ein SEO-Tool bezahlt, und ich habe den Pager-Alert bekommen.

Falls du prüfen willst, ob es der echte Bot ist und nicht jemand, der den User Agent fälscht: Seine IPs lösen per Reverse DNS auf sr-srv.net auf. Und er respektiert robots.txt unter User-agent: SEBot-WA, was gleich noch wichtig wird.

React #418, #454 und die maskierte URL entschlüsselt

Weil ich das alles um 3 Uhr nachts nachschlagen musste, hier der Decoder, damit du es nicht musst.

React error #454 heißt entschlüsselt: "React expected a body element (document.body) to exist in the Document but one was not found... the cause is likely in some other script running on this page." Ein halb ausführender Headless Crawler ist genau dieses "andere Skript". Kein menschlicher Browser produziert ein Dokument ohne Body.

React error #418 ist ein Hydration Mismatch: Das serverseitig gerenderte HTML passt nicht zu dem, was React im Client rendert. Reacts eigene Dokumentation nennt "eine Browser-Extension, die das HTML verändert, bevor React lädt" als bekannte Ursache. Ein Event, von iOS Safari, nie wiederholt. Das ist eine Extension, die DOM injiziert, keine kaputte Seite.

webkit-masked-url://hidden/ bedeutet Safari-Extension-Code, Punkt. TrackJS und die Sentry-Community sagen dasselbe: Filtern, es ist nicht deiner.

Nichts davon ist an einem Ort dokumentiert. Man lernt es, indem man nachts geweckt wird.

Das halbe Internet ist nicht mehr menschlich

Hier der Blick aufs große Ganze, der erklärt, warum das schlimmer wird, nicht besser. Laut Impervas Bad Bot Report 2025 lag automatisierter Traffic 2024 bei 51% des gesamten Web-Traffics. Zum ersten Mal seit einem Jahrzehnt gibt es im Web mehr Bots als Menschen. Was das für SEO bedeutet, habe ich in meinem Post zur Dead Internet Theory geschrieben, aber der Error-Tracking-Blickwinkel ist simpler: Dein Monitoring sampelt den ganzen Feuerwehrschlauch, und die Hälfte davon ist nicht menschlich.

Und die AI-Crawler sind das am schnellsten wachsende Stück. Gleicher Report: GPTBot-Traffic wuchs in einem Jahr um 305%. ChatGPT-User um 2.825%. PerplexityBot um 157.490%, eine Zahl, die wie ein Tippfehler aussieht, aber keiner ist. Ich habe schon darüber geschrieben, wie aggressiv AI-Bots beim Crawlen geworden sind, und jeder dieser Crawler ist eine potenzielle Quelle für Phantom-Fehler in deinem Tracker.

Die Fehler sind also keine Anomalie. Sie sind die neue Baseline.

Der Reflex: Einfach alles bei Cloudflare blocken

Mein erster Instinkt, in der Küche mit kaltem Kaffee, war der offensichtliche: Die Seite läuft hinter Cloudflare. Ein Schalter und das Bot-Rauschen hört auf.

Cloudflare macht das inzwischen sehr einfach. Seit dem 1. Juli 2025 blocken sie AI-Crawler standardmäßig für neue Seiten, was rund 20% des öffentlichen Webs betrifft, und sie verkaufen obendrauf ein Pay-per-Crawl-Produkt, bei dem Bots ein HTTP 402 Payment Required bekommen, bis sie zahlen. Cloudflare hat eigene Gründe, das zu pushen, aber der Pitch verfängt, weil die Rechnung so einseitig wirkt.

Wie einseitig? Cloudflares eigene Crawl-zu-Referral-Zahlen vom Juni 2025: Anthropics Crawler haben rund 71.000 Seiten pro einem einzigen Referral-Klick abgerufen. OpenAIs Verhältnis lag bei etwa 1.700 zu 1. Als Seitenbetreiber bezahlst du Bandbreite, Serverlast und offenbar meinen Schlaf für Crawler, die fast niemanden zurückschicken.

Alle blocken. Einfache Entscheidung, oder?

Das Dilemma: Dieser Kunde will von ChatGPT zitiert werden

Hier ist das Problem. Genau dieser Kunde hat mich vor zwei Monaten gefragt, wie er in ChatGPT-Antworten auftaucht. Er will AI-Sichtbarkeit. Seine Kunden fragen ChatGPT Dinge wie "restroom trailer rental near Corpus Christi", und er will die Firma sein, die genannt wird.

Und pauschales Bot-Blocking killt genau das, still und leise. Das Detail, das die meisten übersehen: Die Trainings-Bots und die Zitations-Bots sind unterschiedliche User Agents. OpenAI betreibt drei separate Crawler. GPTBot sammelt Trainingsdaten. OAI-SearchBot speist die Zitate in der ChatGPT-Suche. ChatGPT-User ruft Seiten ab, wenn ein Nutzer direkt nach deiner Seite fragt. Du kannst GPTBot blocken und trotzdem zitiert werden. Aber wenn du OAI-SearchBot blockst, fliegst du komplett aus den ChatGPT-Suchantworten. Anthropic spiegelt das mit ClaudeBot, Claude-SearchBot und Claude-User.

Eine Standard-Einstellung "AI-Bots blocken" am Edge unterscheidet da nicht. Sie blockt den Bot, der dich zitiert hätte, zusammen mit dem Bot, der dich scrapt. Der Kunde, der von ChatGPT zitiert werden will, und der Maintainer, der einen ruhigen Error Tracker will, ziehen also am selben Hebel in entgegengesetzte Richtungen. Dieselbe Spannung erlebe ich ständig bei GEO-Anfragen von Kunden: Alle wollen AI-Sichtbarkeit, niemand will AI-Traffic.

Ein sauberes Postfach und AI-Zitate gibt es nicht mit einem einzigen Schalter. Du musst Bot für Bot entscheiden.

Im Tracker filtern, nicht am Edge

Hier also, was ich tatsächlich gemacht habe, und das ist der Teil, den du kopieren kannst.

Das Rauschproblem und das Bot-Zugriffsproblem sind zwei verschiedene Probleme. Löse das Rauschen dort, wo es entsteht: im Error-Tracking-SDK. Lass den Edge in Ruhe, solange du keine bewusste Sichtbarkeits-Entscheidung getroffen hast.

Das gehostete Sentry hat in den Projekteinstellungen einen eingebauten Inbound-Filter namens "Filter out known web crawlers". Schalte ihn ein. Aber neue Crawler rutschen ständig durch, es gibt ein GitHub-Issue von 2019 zu eigenen User-Agent-Filtern, das immer noch offen ist, und SEBot-WA stand nicht auf der Liste. Der zuverlässige Fix ist deshalb beforeSend, das auch in Bugsink funktioniert, weil es SDK-seitig läuft:

Sentry.init({
  // ...deine Config
  ignoreErrors: [
    /Failed to fetch.*ct\.pinterest\.com/,
  ],
  denyUrls: [
    /ct\.pinterest\.com/,
  ],
  beforeSend(event) {
    // Events von bekannten Crawlern verwerfen
    const ua = navigator.userAgent || "";
    if (/SEBot-WA|bot|crawler|spider|headless/i.test(ua)) {
      return null;
    }
    // Safari-Extension-Fehler verwerfen
    const frames =
      event.exception?.values?.[0]?.stacktrace?.frames || [];
    if (frames.some((f) => f.filename?.includes("webkit-masked-url"))) {
      return null;
    }
    return event;
  },
});

Das war's. Sentry-Fehler von Bot-Crawlern erreichen das Dashboard nicht mehr, die Crawler crawlen weiter, und an der Sichtbarkeit der Seite ändert sich nichts. Die Bot-Blocking-Frage bleibt, was sie sein sollte: eine geschäftliche Entscheidung pro Bot. Blocke GPTBot, wenn dein Kunde keine Trainingsdaten liefern will. In Ordnung. Aber blocke niemals reflexhaft die SearchBot-Varianten, denn damit löschst du dich aus AI-Antworten, nur um ein Dashboard aufzuräumen.

Der beste Rat, den ich bei der Recherche gefunden habe, stammt aus einem Sentry-Best-Practices-Post: Melde nur Fehler, die du auch wirklich fixen wirst. Alles andere ist Alert Fatigue, und Alert Fatigue ist der Grund, warum man den echten 2-Uhr-Vorfall verpasst.

Was ich wirklich gemacht habe (und was ich immer noch nicht weiß)

Die Bilanz: Ich habe den beforeSend-Filter eingebaut, das Pinterest-Pixel-Rauschen stummgeschaltet, bei Cloudflare nichts geblockt und dem Kunden eine kurze Zusammenfassung geschickt. Seine Seite hatte null echte Fehler. Sein Wettbewerber auditiert ihn wahrscheinlich gerade, was der Kunde seltsam schmeichelhaft fand.

Was ich immer noch nicht weiß: ob es für diesen Kunden langfristig ein guter Deal ist, Anthropic 71.000 Seiten pro Referral-Klick crawlen zu lassen. Die Crawl-Kosten sind real, und der Zitations-Traffic ist bisher ein Rinnsal. Vielleicht dreht sich die Rechnung in einem Jahr. Vielleicht wird Pay-per-Crawl normal und dieser Post liest sich dann wie eine Postkarte aus einer seltsameren Zeit. Ich habe darauf keine saubere Antwort, und ich bin misstrauisch gegenüber jedem, der behauptet, eine zu haben.

Was ich weiß: Wenn dein Error Tracker das nächste Mal um 2 Uhr nachts explodiert, prüf die User Agents, bevor du deinen Code prüfst.

Ein stilles Dashboard kann ich dir nicht versprechen. Was ich anbieten kann: Ich sage dir, welche deiner Fehler echt sind, welche von Bots kommen und welche Bots es wert sind, zu bleiben. Lass uns reden, wenn dein Monitoring schreit und du nicht weißt, warum.