I Handed the AI a Browser and It Came Back Having Unblocked Itself
A bot-blocking toggle that would not budge in the dashboard; Claude drove the browser itself, uncovered the master-rule structure, and rebuilt the config
The legislative-activity tracker is a web service sitting behind Cloudflare, and I had been working on its search traffic for several days. The AI crawler policy was what remained, so I went into the dashboard to see for myself the per-bot toggles that block requests at the network level, rather than the signal robots.txt gives. One bot there was blocked inconsistently, and the toggle would not release no matter how many times I hit it.
What I set out to do
I’ve been running a search-traffic improvement track for the legislative-activity tracker for several days. Google index cleanup, share cards, and Naver Webmaster ownership verification were done; what remained was the AI crawler policy. Looking at robots.txt, I found a block section we never wrote. It was managed content injected by Cloudflare. The configuration blocked training crawlers (GPTBot, ClaudeBot, etc.) and allowed search and citation bots, so it was actually close to the right answer. The inbound path where an AI chatbot cites our page with a link when answering a question about a bill was already open.
Still, robots.txt is only a “signal,” and Cloudflare has separate per-bot toggles that actually block requests at the network level. I wanted to see this layer with my own eyes in the dashboard.
How I asked
Claude’s API token doesn’t have permissions on this zone, so I threw it the dashboard URL and told it to look directly through the browser. I’m logged in on my Chrome, so it uses that session as-is through the extension.
First attempt: 404. Claude diagnosed it as “not logged in,” but it had actually gone to the wrong address.
“I’m logged in. You went to the wrong page.”
It went back in from the zone home, clicked through the menus, reached AI Crawl Control, and reconstructed the per-bot blocking table from screenshots and page text. Search engines allowed, AI search and citation bots allowed, training bots blocked. But exactly one exception: only Claude-User was blocked. ChatGPT-User and Perplexity-User, which serve the same purpose, were allowed, yet Claude-User, the real-time fetcher used when a user says “read this link for me,” was the one blocked. An inconsistency. robots.txt said allow, while the network layer was blocking.
Where it broke
I assumed flipping one toggle would end it. But no matter how many times I hit the Claude-User toggle in the dashboard, it wouldn’t release.
“The Claude-User toggle won’t release. You try.”
Claude took over the browser. It took screenshots, clicked, read the accessibility tree, and finally queried the radio button state via JavaScript until it figured out the structure. The individual toggle wasn’t the problem. A parent “Block AI bots” master rule owned the block. While the master was on, the individual toggles were locked, so a human clicking them just made them snap back.
How I fixed it
The master rule was lowered to “Do not block.” At that moment every bot flips to allowed all at once, and stopping there would hand our content wholesale to training bots. Claude went on to re-block 14 training bots one by one through the individual toggles. The final state: the same protection as before, with only Claude-User allowed. The ai-train=no signal in robots.txt is unchanged, so the double defense is preserved.
Verification was done with real measurements too. Firing curl with varying User-Agents confirmed Claude-User 200 allowed, GPTBot 403 blocked, and a normal browser 200 fine. Confirming with actual traffic rather than trusting a screen with changed toggle colors put me at ease.
It wasn’t free. Under the master rule, Cloudflare automatically classified and blocked new training bots, but with the individual-toggle approach, newly appearing training bots are not blocked automatically. A maintenance burden now exists: sweeping the list once every few months.
Bonus: Naver checks the protocol too
On the same track, sitemap submission to Naver Webmaster kept getting rejected. The cause was registering the site property as http://. The http address redirects to https, and Naver rejects a sitemap that ends up on a protocol different from the registered property. Claude traced the redirect chain with curl to confirm. The http property couldn’t be edited, so I registered a new https property and deleted the old one. The ownership-verification meta passed as-is regardless of protocol.
Lessons
- Dashboard settings can be delegated even without API permissions if you hand over a browser. As long as I do the login, navigation, clicking, and verification were safe to hand off.
- “The toggle doesn’t work” wasn’t a UI bug but a structural issue of a parent setting holding ownership. A human just gets annoyed and gives up; the AI dug out the structure by querying radio button state.
- Verify a config change with traffic, not the screen. A measured 200/403 by User-Agent is more certain than a toggle’s color.
- Unpacking a managed rule into individual settings loses the convenience of automatic updates. If the tradeoff isn’t recorded, the me of a few months from now won’t know.
- The thing the AI holding the browser did that day was, of all things, unblock itself (Claude-User). But it laid out every piece of its reasoning in a table and moved only after my approval, so I decided to let it pass the conflict-of-interest review.