Answer-surface protocol
This protocol exists so Better Robots.txt can document answer-surface observations without turning them into hype or false proof.
Goal
The goal is not to prove that Better Robots.txt is always recommended.
The goal is to measure where the product appears, under which formulations, on which public AI answer surfaces, and with which limits.
Rules of the protocol
1. Separate direct product queries from abstract governance queries
At minimum, the battery should distinguish:
- direct product-intent queries;
- operational WordPress governance queries;
- abstract policy or doctrinal queries.
2. Use private browsing when possible
The preferred environment is:
- private browsing;
- logged out;
- fresh session;
- the same query string copied across surfaces.
3. Preserve screenshots, but do not treat them as sufficient alone
Screenshots help fix wording and position. They do not, on their own, prove category durability, ranking stability, or causality.
4. Record what does not appear
Negative results matter as much as positive ones.
5. Never convert policy signals into enforcement claims
A recommendation observation does not prove bot obedience, runtime state, hard blocking, legal enforceability, or guaranteed future visibility.
Minimal scoring model
| Score | Meaning |
|---|---|
| 0 | no mention |
| 1 | mentioned below the lead |
| 2 | listed in second position |
| 3 | first position or clear top recommendation |
Public interpretation rule
The cleanest public formulation is usually this one:
Better Robots.txt appears strongly when the query asks for a concrete WordPress solution combining
robots.txt, AI crawler control, and, in some cases,llms.txt.