On 16 July 2026 a working, well built website scored 60 out of 100 on our audit. The next day the same site scored 93. Nothing changed in its pages. Two Cloudflare settings were turned off.
The site in this case study is vonzie.studio, the agency site of our own operator. That is exactly why we can publish it: we hold the before audit, the after audit, and a re-check two weeks later, all produced by the same engine that scores every business on this site. We found the problem by auditing ourselves, which is also how this publication works.
Score: 60 out of 100, with two hard failures. The first was crawler access. The site’s robots.txt, the file that tells automated readers what they may look at, was telling the AI crawlers to leave:
User-agent: * Content-Signal: search=yes,ai-train=no,use=reference Allow: / User-agent: Amazonbot Disallow: / User-agent: Applebot-Extended Disallow: / User-agent: Bytespider Disallow: / User-agent: CCBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: GPTBot Disallow: / User-agent: Google-Extended Disallow: /
GPTBot is how OpenAI reads the web. ClaudeBot is how Anthropic does. Google-Extended, CCBot, Bytespider, Amazonbot, Applebot-Extended: all the named AI readers, all told Disallow: /, nothing at all. The site’s owner had written none of this. It is Cloudflare’s managed robots.txt, a protection the platform applies for you, built to keep content out of AI training sets.
The second failure was stranger. The audit read all five sampled pages and found no contact signals: no phone, no email, no address. A human visitor saw the email address plainly. The cause is Cloudflare’s email obfuscation, which rewrites every email address into a small script that reassembles it in the browser. A reader that does not run scripts, which is how AI crawlers read, gets nothing. The address was on the page and invisible at the same time.
On 17 July the two settings were switched off and the robots.txt was replaced with one that admits the AI crawlers. No copy was rewritten, no page was redesigned. The same engine, the same weights, the next day: 93 out of 100. Re-checked on 31 July: still 93.
This was not a one-site accident. In our 31 July sweep of the sites our operator manages, two more Cloudflare-fronted sites were serving the identical managed file, line for line, and both failed the same crawler-access check. The pattern travels with the platform, not with the site.
Neither setting is a bug. Blocking AI crawlers is a reasonable default for a publisher who does not want its writing absorbed into training data, and obfuscating email addresses fights scrapers that harvest them for spam. Cloudflare is doing what it says it does. The trouble is only that the same switch that keeps your content out of training sets also keeps your business out of the answers, and for a local business that lives on being found, those are opposite goals. The switch ships on, and nothing tells the owner which of the two games they are now playing.
Open your own domain followed by /robots.txt in a browser. If you see the block above and you want AI assistants to be able to recommend you, the setting lives in the Cloudflare dashboard as managed robots.txt, and email obfuscation sits under Scrape Shield. Both can be turned off, or replaced with rules you chose on purpose. Then put your contact details in the page as plain text and links, so every kind of reader can find them.
Or file your address with the free live audit on our front page. It reads your site exactly the way a no-script AI crawler does and shows you the score with the evidence quoted.