How AI assistants choose what to cite.

An assistant answering a question is working from one of three things: material it was trained on, a page it fetched while answering, or a search index's version of a page. The paths differ, and every one of them has the same two steps in it.

Something extracts the text, and something decides the page answers the question. Almost everything usefully done about this is making those two steps easy, which is why the advice below is unexciting and why most of what is sold as optimisation for this is not.

In rough order of how often the absence of each is the actual problem.

• Text that exists without running anything

  If the content is assembled in the browser, a fetcher can receive an empty shell. This is the most common reason a page that looks completely fine to a person is never quoted, and it is invisible unless you go and look at what a fetch returns.

• The answer in the first paragraph

  A page that defines its subject before arguing about it hands over a sentence that stands on its own. A page that opens with a story offers nothing that can be lifted without the paragraphs around it.

• Questions written as questions

  A heading that is the question somebody actually typed, with the answer immediately under it, is the easiest shape there is to quote correctly. It also forces you to find out whether you can answer it in a sentence.

• Short paragraphs and real lists

  A unit that gets lifted has to be small enough to lift. Three sentences is a quotable paragraph. Twelve is a section that will be summarised instead, and a summary is where the meaning moves.

• Structured data that matches the page

  Marking up what is genuinely there helps a machine agree with you about what the page is. Marking up what is not there is worse than doing nothing, because the disagreement is now on the record.

• Corroboration somewhere that is not you

  A claim appearing only on the client's own site is a claim by an interested party. This is the hardest of these to influence and probably the one that matters most, which is an uncomfortable combination.

There is a convention for publishing a file that lists your pages for assistants to read. It takes very little effort to produce, and no major provider has committed to using it.

Publish it if you want to. Treat it as cheap rather than as effective, and do not let it take priority over anything in the list above, because the list above describes how the text actually gets read.

Writing more pages on the same subject, which splits whatever authority the subject had across several weaker pages. Repeating a phrase for its own sake. Publishing a page that exists to rank and answers nothing in particular.

The mechanism selects for content that can be quoted accurately and without risk. A page with nothing specific in it fails both tests at once, and no amount of it adds up to one page that would have passed.

Citation is not reported to you, and the traffic that arrives is a fraction of the citations that occurred, so the feedback loop you would want does not exist.

Judge this the way you would judge any structural work. Do the things that are obviously true on inspection, such as making sure a page's text is actually in the response a fetcher receives. Do not design a test whose result you have no way of reading, and do not promise a client a result nobody can measure. Be suspicious of anybody selling you the result of such a test.

Honestly, not here. SightShark does not write a client's pages and it does not track who cites them, and a guide on this subject that ended by implying otherwise would be worth less than the paragraphs above it.

The one real connection is adjacent. If you already sample which prompts return a client and record the results, that log is a source like any other: it can be ingested from a spreadsheet or a file and land in your warehouse beside that client's traffic figures, so the sampled measure and the visits sit in one place and can be compared over time. That is the extent of it.