Why AI assistants do not cite your site

What an assistant looks for, and it is not a page

In short: A search engine returns addresses; an assistant looks for attributable passages. The useful unit is no longer the page but the paragraph that answers on its own.

When an assistant handles a question, it does not need a whole page: it needs a fragment that answers, and a source to attach that fragment to. Everything else — navigation, layout, sales arguments — is useless at that moment. A paragraph that only makes sense alongside the three before it is hard to extract; a paragraph that answers a phrased question is directly citable.

That is the main reversal. Classic search optimisation rewards a page that is coherent on a subject. A generated answer rewards a sentence that stands alone, outside its context, and stays true once removed from the page. The two do not conflict, but optimising for one does not automatically produce the other.

The practical consequence is a way of writing, not a technique. Name the question in a heading, answer it in the lines that follow, then develop: the answer is available before the argument. A reader in a hurry gains as well, which is a good sign — optimisations that serve only machines age badly.

Content that does not exist in the served HTML

In short: Some agents do not run JavaScript. Anything that appears only after execution — tabs, script-driven accordions, load-on-demand — is invisible to them.

A browser runs the page’s JavaScript, downloads the rest, opens tabs on demand. Many programs that collect content do none of that: they take the server’s response and read it as it is. If the text is not there yet, it does not exist for them.

This is the most common defect and the quietest, because proofreading never catches it: the page looks complete in a browser. The usual shapes are question blocks whose answer is only injected on click, lists loaded on scroll, content rendered client-side only, and tab sets where only the first is present in the source.

Checking takes barely more than one command: fetch the page without a browser — any command-line tool that prints the raw response will do — and look for a sentence you want to see quoted. If it is not there, no later optimisation will make up for it. Native HTML disclosure elements, on the other hand, keep their content in the source even when collapsed: that is the simple way to have a folded interface and readable text.

Write answers, not pages

In short: A heading that names a benefit matches no question anyone asked. A heading that echoes how a real question is phrased becomes its anchor.

Marketing headings — “Our expertise”, “Tailored solutions” — match nothing a person types into a search bar or dictates to an assistant. They describe the seller, not the problem. A real question looks more like “how do I know my backups actually work” or “should we rebuild the site or fix it”: it carries the doubt of whoever is asking.

Reusing that phrasing as a section heading has two effects. The first is mechanical: the match between question and heading becomes direct. The second is editorial: an interrogative heading forces an answer in the next paragraph, where a noun-phrase heading lets you circle indefinitely.

The same principle applies to frequently asked questions, provided they are not treated as a writing exercise. A good question is one you actually get asked, including when the answer does not flatter you. A FAQ containing only comfortable questions is spotted instantly and adds nothing: it removes no doubt, so it answers no search.

Structured data: what it does and what it does not

In short: Markup does not make content better: it makes it unambiguously interpretable. It never compensates for text that is missing or false.

Structured data describes, in a machine-readable format, what the page already contains: an organisation, a service, a question and its answer, an article and its date. Its value is removing interpretation. Without it, a program has to guess that this block is a question and the next paragraph its answer; with it, it knows.

Its limit is just as clear. It creates no content. Markup declaring a question whose answer is not in the page describes something that does not exist, and that inconsistency is detectable. The rule is simple: what is declared must be visible, and what is visible deserves to be declared.

One practical point is often missed: one coherent data block per page beats several partial declarations that contradict each other. Declaring the same organisation twice with different details forces an arbitrary choice, and the choice will not necessarily be yours.

What you can check yourself

In short: Four checks, none of them requiring paid tooling, rule out the most common causes of invisibility.

The first is the served HTML, already described: the sentence you want quoted must be present in the server’s raw response. The second concerns access: check that your robots.txt does not exclude the agents you want reading you, and that nothing blocks them at hosting level — a broad block put up against unwanted crawlers often sweeps up the rest.

The third is reading a single paragraph aloud, taken out of its page. If it does not make sense alone, nobody will cite it alone. It is a check with no technology in it, and it is the one that changes the most.

The fourth is to ask an assistant the question, watching not your ranking but what it cites: which sources, and for which passage. That shows what counts as attributable in your field — and most often it is pages explaining a mechanism, not pages praising a service.

None of these checks guarantees being cited. They remove the causes that prevent it, which is not the same promise. Visibility with assistants also depends on what other people write about you, and that part cannot be optimised from your own site.