Getting content indexed by search engines has twenty years of methodology behind it. Getting content cited by AI is a methodology that has barely started growing.
The biggest difference: a search engine's reader is a crawler; an AI's reader is a reader that reasons. A crawler looks at structure. A reasoner looks at whether your content can support a sentence it's willing to say out loud.
That difference has a very practical consequence — you now have more ways to fail, and they look alike.
Separate the two failures first
When your content doesn't show up in an AI's answer, there are only two possibilities, and their fixes are opposites:
One: it never fetched you. You're not in the index, or what it fetched was an empty shell — the page renders through JavaScript and the server returns HTML with nothing in it. How well you write is irrelevant here; the problem is plumbing, not content.
Two: it fetched you and didn't cite you. You're in the index, the content was read, and it chose not to use it — because there was no quotable definite statement, because a number carried no timestamp and it wouldn't vouch for it, because somewhere else said the same fact more clearly.
Externally these look identical: you weren't mentioned. But the first calls for infrastructure work and the second for rewriting. Conflating them produces the familiar frustration of "I wrote all this good content and it did nothing" — when the actual cause may be a server returning an empty div.
Telling them apart isn't hard: look in your server logs for those AI fetcher user agents, which URLs they hit, how many bytes came back. Whether a fetch happened is a matter of fact, not speculation.
Server-readable is the precondition for everything
This sounds like advice from ten years ago, but its weight has changed.
Search engines have enough incentive to execute your JavaScript, and have invested years of engineering in doing so. Most AI fetchers won't — they send one request and take whatever comes back.
So the test has become very plain: curl your page and see whether the returned HTML contains the article. If it doesn't, you effectively don't exist over there, no matter how refined the design or how smooth the interaction.
Freeze your numbers
A specific hole I fell into.
What an AI fears most when citing a number is that the number will move. "Up 12% year over year this month" — which month? Is this sentence still true three months from now? A careful model won't cite it, because it can't establish what period it would be describing.
So numbers should freeze into snapshots: state the definition, the time range and the generation date, and don't change the figure once it exists. Next month's data gets a new snapshot; the old one stays as it was.
This runs exactly counter to dashboard instinct, where the panel always shows the latest value. Quotable content needs a fixed point that won't betray the reader.
Leave agents a shorter path than the browser
The last thing, which I didn't see coming.
At VOLO we built a service interface for AI, and then ran into an awkward fact: no agent could discover it. It existed, it worked, and it wasn't anywhere an agent would look.
So we added a command-line entry point. It looks like a step backwards — a CLI, in 2026 — but for an agent it's better: nothing to render, nothing to click, no guessing where the button is, text in and text out, and a clear exit code when something fails. For the same task, an agent going through the CLI spends an order of magnitude fewer tokens than driving a browser, and fails less often.
The conclusion is slightly counterintuitive: optimizing for agents usually means making the interface thinner, not thicker. The hints, progressive disclosure and visual hierarchy people need are all noise to an agent.
Boundaries
Don't write in order to be cited. Content optimized for AI that reads strangely to humans probably won't last — models will only get better at recognizing material produced for retrieval, and that road is the same road keyword stuffing was.
And don't expect it to pay off quickly. There's a long delay between fetching, indexing and being chosen, and what you change today may take weeks to surface in an answer. That means you need a mechanism that can run for a long time, not a sprint.