A lot of commentary about AI and search can’t turn out to be wrong. “AI search is growing.” “Publishers will need to adapt.” Nothing that happens next year could show either sentence was false, which also means neither tells you much.
When I want a claim to be checkable, I make sure it has four things.
The first is the date it was made. Without one, it’s hard to tell later what the writer actually said at the time.
The second is a fixed sample. “Most publishers” can be reinterpreted after the fact. “These ten named sites” can’t. If the sample can change after the claim is made, so can the answer.
The third is a date when it will be checked. “Eventually” can’t be checked. A named date can.
The fourth is a statement that could turn out false. A useful test is to write down what result would prove it wrong. If I can’t do that, I don’t have a claim yet.
An example
My October crawler study says I’ll re-run the same check every month against the same ten sites. That sentence has the parts that make later claims checkable. The sample is fixed and listed in the study. The first snapshot is dated 2 October 2026. Each re-run uses the same definition of blocked, set out in the method note. Any claim about how those files change can be checked against the next snapshot.
Why I do it this way
If a writer’s claims can never be wrong, readers have no way of telling which calls were good. Checkable claims make that possible. Writing them also changes what I publish. When I ask what would make a sentence false, quite a few drafts don’t survive, and they usually weren’t worth keeping.
I keep my own dated calls on the predictions page, each with the date it was made, a check date and a status. There are no new predictions in this post.