Six pieces of AI-readiness advice we tested and are telling clients not to bother with
Most AI-readiness checklists are a list of things to do. Ours has a section for what not to bother with, because we tested it rather than assumed it. Six items clear the bar so far. Four are changes a site owner would be told to make. Two are measurement practices a client would be told to start tracking. The count is a floor, not a ceiling: it grows when a sweep proves something else wrong, never when we decide to pad it.
1. Shipping an llms.txt. Across every zone where we have path-level visibility, /llms.txt was fetched four times in seven days. Not one of those four fetches was an AI agent. It's a plausible-sounding file to add and, on what we can actually see, nobody's reading it yet.
2. Adding a named User-agent: block per AI crawler. We wrote this one up in full separately, it's worth the longer read. Short version: nine domains added eleven named groups between them, every one identical to the default, and the naive version of this fix can silently open access it was meant to close.
3. Checking your Cloudflare AI-bot setting before the deadline everyone's citing. Also written up separately. The setting only matters if Cloudflare is actually in the request path, and on our own estate it never was.
4. Filtering Search Console for queries over 50 characters to find AI-search traffic. The logic sounds right, a long, fully-formed query looks like something an agent would generate rather than a person typing. The problem is Google Search Console omits rare queries below its anonymisation threshold, and a genuinely agent-shaped query is, by construction, usually one user. You're filtering for exactly the rows GSC has already hidden from you.
5. Tracking brand-mention percentage in AI answers as a KPI. We ran a variance decomposition on this one, it's the strongest single result in this set, and it has its own piece.
6. Adding a Content Signals block to robots.txt. This is the newest addition to the list. Content-Signal: is not a recognised field under the robots.txt standard (RFC 9309), and conforming parsers discard it. We tested this directly: 56 access decisions across two independent parsers, seven user-agents and four paths, and the field's presence changed none of them. On the one domain in our own estate carrying one, every crawler its ai-train=no addresses was already separately blocked by a Disallow: line that parsers do act on, so the signal was redundant where enforcement existed and decorative where it didn't. To be precise about the limit of this: the claim is about access decisions. We haven't tested whether the field carries legal or licensing weight, which is plausibly the point of it, and this isn't a criticism of Cloudflare, their own documentation is clear that the field isn't enforcement.
The pattern across all six is the same. Each one is advice that sounds reasonable and travels well, and none of it survived being pointed at real requests, real logs, or real response data. That's the test we're applying to everything on the list, including the things we're recommending you do.