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

> geoplaybooks.com scored 10/100 on its own AI-visibility checker: HTTP 522 on reachability, "no robots.txt found". The root cause — a worker cannot fetch its own zone — and why reachability failures ar

Source: https://geoplaybooks.com/blog/2026-07-12-our-checker-gave-us-10/

# 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](/check/) 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.

> TL;DR Score went 10/100 → 100/100 with zero changes to content, robots.txt, schema, or llms.txt. The site was always fine — the probe couldn't reach it. Root cause: our checker runs on a Cloudflare Worker, and a Worker cannot fetch its own zone — the platform answers HTTP 522 to stop request loops. The general lesson: reachability failures live in infrastructure — WAFs, CDNs, loop protection, bot rules — and are invisible in your HTML, your robots.txt, and your browser.

## 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](/check/result/geoplaybooks.com/).

## 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](/blog/2026-07-12-openai-com-scores-20/) 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](/audit/sample/), 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](/methodology/), including the embarrassing ones.

If your site's reachability signal FAILs while everything "looks fine": [run the check](/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.