What an Agent Needs Before It Will Quote You

The advice on writing for AI systems has converged fast, and most of it is fine: answer the question early, keep claims self-contained, structure the page, use clear headings. All true, all shallow.

It is shallow because it describes how to be readable. The interesting constraint is not readability. It is that a system quoting you inherits your errors, and — increasingly — is expected to say where its answer came from.

That changes what a page has to provide.

Citation is a liability transfer

When a model summarises your page without attribution, your mistakes cost you nothing. When it cites you, your mistakes become visible failures attached to your name, and the system doing the citing has an interest in not making that trade blindly.

So the question a page has to answer is no longer “is this clear?” It is:

Is there enough here for a machine to decide this is worth standing behind?

Three things move that needle, and none of them is prose quality.

1. A claim that is dated

An undated claim is unusable for anything that changes. “The conference runs 14–16 September” is either current or a year out of date, and a page that does not say which is asking a consumer to gamble.

The fix is not a “last updated” stamp on the template, which usually just reflects the last time the site was deployed. It is a per-record assertion of when that specific fact was last checked — which means your content model has to carry it, which means it has to be a field rather than a footer.

The distinction matters because the two are wildly different in value. A site-wide deploy timestamp tells a consumer that the CSS changed. A per-record lastVerifiedAt tells it the fact itself was looked at.

2. A source that is named and typed

“Verified” is not a claim, it is a mood. What a consumer can use is: verified against what.

And the sources are not equivalent. An organiser’s own announcement, a reputable press report, and a third listing site that scraped one of the first two are three different grades of evidence, and flattening them into a single array of URLs destroys the only information that made them worth listing.

Typing them fixes it:

"verificationSources": [
  { "url": "https://example.org/2027", "role": "official" },
  { "url": "https://aggregator.example/listing", "role": "aggregator" }
]

Now a rule is expressible that was not before: a page may not claim more confidence than its own sources support. If the strongest source is an aggregator, the page cannot describe itself as confirmed by the organiser. That is a build-time assertion, not an editorial habit.

It also stops a specific and embarrassing failure: a “verified” record whose evidence is four directory listings that all copied each other.

3. Provenance a machine can read AND a human can

Schema.org has no vocabulary for “we checked this”. It has dateModified, sdPublisher and citation, which between them get you: when the structured data changed, who produced it, and what it rests on. That is genuinely useful and it is as far as the vocabulary goes.

Which means the rest of the claim has to be a sentence on the page, in ordinary language, linking the source. Not because sentences are quaint, but because it is the only form of the claim that every consumer — human, crawler, model — can interpret without a schema extension nobody has agreed on.

The two are complements, not alternatives. The markup is the structured half and the sentence is the interpretable half, and a page that has one without the other is making half a claim.

The failure mode worth naming

The failure is not writing badly. It is asserting confidently and being wrong, at scale, because a pipeline filled in a field it did not actually know.

An inferred US state on an event listing looks like completeness. Portland is in Oregon, unless it is the one in Maine. A model that inherits that guess and cites you has now produced a confident wrong answer with your name on it — and the next time, it may weight you lower.

The rule that prevents it is unglamorous and absolute: an absent field is honest; a guessed one is corruption. Leave it out. A consumer can handle missing data. It cannot handle data that is present and wrong, because nothing in the page marks it as different from the data that is present and right.

What this actually asks of you

Not a rewrite. A content model that can carry provenance, a gate that stops a record claiming more than it can support, and the discipline to ship empty fields rather than plausible ones.

Do that and you are not “optimising for AI”. You are producing something that is checkable — which happens to be what every consumer has always wanted, and what only some of them could previously insist on.