My Error Tracker Blew Up at 2 AM. The Attacker Was an SEO Tool.

My phone buzzed at 2 AM. Five new issues in the error tracker for a client site. Five. This is a site I maintain for a US trailer rental company, the kind of client who calls you when a form breaks, so my first thought was: the deploy from yesterday broke something, and tomorrow morning I'll have an inbox full of angry emails.

I got up. I made coffee. I triaged all five issues.

Not one of them was a real bug. Let me walk you through what actually happened, because if you maintain websites for clients, this is going to happen to you too. And the obvious fix, blocking bots at Cloudflare, turns out to be a trap.

Five Errors, Zero Bugs

Quick setup: the client runs a Next.js site with hundreds of location landing pages. I run Bugsink for error tracking, a self-hosted, Sentry-compatible tool, because I'd rather pay my own server than another SaaS subscription. Same SDK, same dashboards, same 2 AM alerts.

Here's the full list of what woke me up:

1. "Google Maps failed to load", twice, on a location page
2. "Failed to fetch ct.pinterest.com", nine times, on the Google Ads landing page
3. Minified React error #454, once
4. Minified React error #418, a hydration error, once
5. "Can't find variable: data", once, in a function called refreshToken

That last one almost got me. The site doesn't have a refreshToken function. Anywhere. I grepped the whole codebase at 2:30 AM to be sure.

Fourteen events. Zero real users affected. Zero lines of my code at fault. Sound familiar?

The Triage: Walking Through Every "Error"

The Pinterest one was the easiest, and the most ironic. Nine events, all from visitors landing through paid Google Ads. Their ad blockers kill the Pinterest tracking pixel, the pixel's fetch fails, the SDK dutifully reports it. Think about that: the most expensive visitors on the site, the ones the client pays Google for, throw the most errors. Because they run ad blockers. The errors are literally a sign the marketing is working.

The "Can't find variable: data" one took longer. The stack trace pointed to webkit-masked-url://hidden/. If you've never seen that string: it's WebKit deliberately hiding the URL of Safari browser extension code, so websites can't fingerprint which extensions a user has installed. Which means an error with that stack frame cannot be your code. Some extension on some visitor's Mac has a broken refreshToken function, and my error tracker caught it like it was my problem.

The Maps failure and the two React errors shared a culprit. Both Maps events came from the same user agent: SEBot-WA.

I'd never heard of it either.

Meet SEBot-WA, the SEO Tool That Crashed My Night

SEBot-WA is the crawler behind SE Ranking's Website Audit tool. It's legitimate, it's well-behaved, and it has one property that makes it special among SEO crawlers: it renders JavaScript in a headless browser instead of just fetching HTML.

That's exactly why it set off my alarms. A headless browser executing a React app partially, or out of order, or with certain scripts blocked, trips errors that no human visitor will ever see. The Maps script times out, my onerror handler fires, the SDK reports it. The crawler half-renders a page, React panics, error #454 lands in my dashboard.

Here's the detail that made me laugh at 3 AM: SEBot-WA only crawls sites that someone explicitly added to an SE Ranking audit project. I didn't add this site. The client didn't either. Which means a competitor is probably running an SEO audit on my client's site right now. Someone out there paid for an SEO tool, and I got the pager alert.

If you want to verify it's the real bot and not someone spoofing the user agent, its IPs reverse-DNS to sr-srv.net. And it honors robots.txt under User-agent: SEBot-WA, which becomes relevant in a minute.

Decoding React #418, #454, and the Masked URL

Since I had to look all of these up at 3 AM, here's the decoder ring so you don't have to.

React error #454 unminifies to: "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." A half-executing headless crawler is precisely the "other script" scenario. No human browser produces a document without a body.

React error #418 is a hydration mismatch: the server-rendered HTML doesn't match what React renders on the client. React's own documentation lists "a browser extension installed which messes with the HTML before React loaded" as a known cause. One event, from iOS Safari, never repeated. That's an extension injecting DOM, not a broken page.

webkit-masked-url://hidden/ means Safari extension code, full stop. Both TrackJS and the Sentry community say the same thing: filter it, it's not yours.

None of this is documented in one place. You learn it by getting paged.

Half the Internet Isn't Human Anymore

Here's the zoom-out that explains why this is getting worse, not better. According to Imperva's 2025 Bad Bot Report, automated traffic hit 51% of all web traffic in 2024. For the first time in a decade, bots outnumber humans on the web. I wrote about what that means for SEO in my dead internet theory post, but the error tracking angle is simpler: your monitoring samples the whole firehose, and half the firehose isn't human.

And the AI crawlers are the fastest-growing slice. Same report: GPTBot traffic grew 305% in a year. ChatGPT-User grew 2,825%. PerplexityBot grew 157,490%, which is the kind of number that looks like a typo but isn't. I've covered how aggressive AI bots have gotten with crawling, and every one of these crawlers is a potential source of phantom errors in your tracker.

So the errors aren't an anomaly. They're the new baseline.

The Reflex: Just Block Everything at Cloudflare

My first instinct, standing in the kitchen with cold coffee, was the obvious one: this site sits behind Cloudflare. One toggle and the bot noise stops.

Cloudflare makes this very easy now. Since July 1, 2025, they block AI crawlers by default for new sites, which affects roughly 20% of the public web, and they sell a pay-per-crawl product on top where bots get an HTTP 402 Payment Required until they pay up. Cloudflare has its own reasons for pushing this, but the pitch lands because the math feels so lopsided.

How lopsided? Cloudflare's own crawl-to-refer numbers from June 2025: Anthropic's crawlers fetched roughly 71,000 pages for every one referral click they sent back. OpenAI's ratio was around 1,700 to 1. As a site owner you're paying bandwidth, server load, and apparently my sleep, for crawlers that send almost nobody back.

Block them all. Easy decision, right?

The Conundrum: This Client Wants ChatGPT to Cite Them

Here's the problem. This exact client asked me, two months ago, how to show up in ChatGPT answers. They want AI visibility. Their customers ask ChatGPT things like "restroom trailer rental near Corpus Christi" and they want to be the company that gets named.

And blanket bot-blocking quietly kills that. The detail most people miss: the training bots and the citation bots are different user agents. OpenAI runs three separate crawlers. GPTBot collects training data. OAI-SearchBot powers ChatGPT's search citations. ChatGPT-User fetches pages when a user asks about your site directly. You can block GPTBot and still get cited. But if you block OAI-SearchBot, you're removed from ChatGPT search answers entirely. Anthropic mirrors this with ClaudeBot, Claude-SearchBot, and Claude-User.

A default "block AI bots" setting at the edge doesn't distinguish. It blocks the bot that would have cited you along with the bot that scrapes you. So the client who wants to get cited by ChatGPT and the maintainer who wants a quiet error tracker are pulling the same lever in opposite directions. This is the same tension I keep running into with GEO requests from clients: everyone wants AI visibility, nobody wants AI traffic.

You can't have a clean inbox and AI citations by flipping one switch. You have to decide bot by bot.

Filter in the Tracker, Not at the Edge

So here's what I actually did, and it's the part you can copy.

The noise problem and the bot-access problem are two different problems. Solve the noise where the noise lives: in the error tracking SDK. Leave the edge alone unless you've made a deliberate visibility decision.

Hosted Sentry has a built-in inbound filter called "Filter out known web crawlers" in project settings. Turn it on. But new crawlers slip past it constantly, there's a GitHub issue from 2019 asking for custom user-agent filters that's still open, and SEBot-WA wasn't on the list. So the reliable fix is beforeSend, which works in Bugsink too since it runs SDK-side:

Sentry.init({
  // ...your config
  ignoreErrors: [
    /Failed to fetch.*ct\.pinterest\.com/,
  ],
  denyUrls: [
    /ct\.pinterest\.com/,
  ],
  beforeSend(event) {
    // Drop events from known crawlers
    const ua = navigator.userAgent || "";
    if (/SEBot-WA|bot|crawler|spider|headless/i.test(ua)) {
      return null;
    }
    // Drop Safari extension errors
    const frames =
      event.exception?.values?.[0]?.stacktrace?.frames || [];
    if (frames.some((f) => f.filename?.includes("webkit-masked-url"))) {
      return null;
    }
    return event;
  },
});

That's it. Sentry errors from bot crawlers stop reaching the dashboard, the crawlers keep crawling, and nothing about the site's visibility changes. The bot-blocking question stays what it should be: a per-bot business decision. Block GPTBot if your client doesn't want to feed training data. Fine. But never reflexively block the SearchBot variants, because that's deleting yourself from AI answers to tidy up a dashboard.

The best advice I found while researching this came from a Sentry best-practices post: only report errors you will actually fix. Everything else is alert fatigue, and alert fatigue is how you miss the real 2 AM incident.

What I Actually Did (and What I Still Don't Know)

The final tally: I added the beforeSend filter, muted the Pinterest pixel noise, blocked nothing at Cloudflare, and sent the client a short summary. Their site had zero real errors. Their competitor is probably auditing them, which the client found weirdly flattering.

What I still don't know: whether letting Anthropic crawl 71,000 pages per referral click is a good trade for this client long-term. The crawl costs are real and the citation traffic is, so far, a trickle. Maybe in a year the math flips. Maybe pay-per-crawl becomes normal and this whole post reads like a postcard from a weirder time. I don't have a clean answer for this one, and I'm suspicious of anyone who says they do.

What I do know: the next time your error tracker blows up at 2 AM, check the user agents before you check your code.

I can't promise you a silent dashboard. What I can offer: I'll tell you which of your errors are real, which are bots, and which bots are worth keeping around. Let's talk if your monitoring has been screaming and you can't tell why.