Our own checker gave us 10/100 tonight. The bug class is probably on your site too.

Tonight the owner of this site ran geoplaybooks.com through our own 5-signal checker and got 10/100 — "Largely invisible." AI-crawler reachability: FAIL, HTTP 522. robots.txt: "not found." The site that publishes GEO playbooks, flagged as unreadable by AI engines, by its own tool. We're publishing the post-mortem because the bug class is common, the misdiagnosis is even more common, and the fix took one code path.

What the 10/100 actually meant

The checker probes five signals, and the first one — can an AI crawler fetch your homepage at all — gates the other four. When that probe returned HTTP 522, the robots.txt and llms.txt fetches died the same way, so a site that serves both got scored as having neither. One infrastructure-level block, cascading into four false failures.

That cascade is not a bug in the scoring. It's the point of the scoring. GPTBot experiences your site exactly the way the failed probe did. If a fetch from a datacenter IP with a bot user-agent gets a 4xx/5xx, it doesn't matter how good the content behind it is.

The actual bug

Our checker runs inside a Cloudflare Worker on the same domain it was asked to audit. Cloudflare refuses to let a Worker fetch its own zone — the platform sees a potential infinite loop and returns HTTP 522 instead of executing the request. Every external domain we've ever checked was probed correctly; the one domain the probe could never see honestly was our own.

The fix: when the target of a probe is our own hostname, route the fetch through a service binding — the Worker calling itself through the platform's front door instead of the public internet. One guard in the shared fetch function, covering the checker, the MCP tools, the paid-report crawler and the hourly Pulse probes at once. Re-run: 100/100, five of five signals PASS. The result is public: geoplaybooks.com's check result .

Why this is your bug class too

We keep meeting this exact shape in the wild, wearing different masks:

• The openai.com case from our logs: homepage returns 403 to plain probes while robots.txt politely welcomes crawlers. The block lives at the WAF, invisible one layer up.
• WAF bot rules that pass Googlebot but 403 GPTBot and PerplexityBot — the first finding in our sample audit report , because it's the most valuable thing an audit can catch.
• Loop protection and CDN misconfigurations — tonight's flavor — where the infrastructure answers before your site does.

In every variant, the site owner checks their browser, sees a working site, and concludes the audit tool is broken. Sometimes it is — ours was, for exactly one domain. But the way to know is to test the probe path, not the browser path: curl -A "GPTBot" https://your-site.com/ from a datacenter, not from your laptop on residential Wi-Fi.

The uncomfortable honesty part

A tool that audits reachability must itself be audited for reachability. Tonight our checker's blind spot was the one domain we care most about — and the public result page was showing 10/100 to anyone who looked. We fixed the probe, re-ran it in public, and wrote this up the same evening. That's the deal this site runs on: logged runs, disclosed methods , including the embarrassing ones.

If your site's reachability signal FAILs while everything "looks fine": run the check , copy the AI fix-it prompt from your result page, and hand it to your engineer or your AI agent — it includes the WAF/CDN checklist for this exact failure class.