How to write pages that AI answers can cite

The articles on leej.uk are written this way because I am tired of pages that hide the answer behind a preamble. I also built the Answer Engine Structure Analyser and the Readability Checker to test the shape of a page, not to game a particular product. What follows is the writing method, not a guarantee.

One page, two kinds of reader

Every public page now has at least two kinds of reader. One is a person, often on a phone, who arrived with a question and will leave if the first screen is vague. The other is a machine that is trying to represent that page in a short result or a spoken answer: a search snippet, a knowledge panel, an assistant, a preview card. The machine will not “get the gist” of a section you planned to write later. It will use the words that are actually there, in an order it can parse.

You should not write two pages, one for humans and one for models. You should write one honest page that both can use. The person still comes first. If the prose is only a list of fragments designed to be quoted, people will not stay, and you will have given assistants a thin source to copy.

This is the same standard I use when I write about how to choose an iOS developer or when I describe a small, focused Apple app: say what is true, in an order a busy reader can use, and do not dress it up.

Answer the question in the first paragraph

The first paragraph should do the job the title promises. If the title is “How to write pages that AI answers can cite”, the opening should say how, not that the topic is more important than ever, and not that “in this article I will explain”. A search snippet and an assistant often have little more than that opening and the title to work with. A person deciding whether to stay has even less patience.

A useful opening:

• States the answer, or the method, in one or two sentences.
• Names the limits in the same breath when the limit is part of the truth (“this is a convention, not a standard”; “this does not notify Google”).
• Avoids a teaser. If the reader has to click to learn the actual advice, you have written an advertisement, not an answer.

The rest of the page then earns the opening. Examples, exceptions, steps and tools belong in the sections that follow, not in a delayed reveal.

I also write a short meta description that can stand alone, and I sometimes add a one- or two-sentence summary for structured data. Those should agree with the opening, not invent a stronger claim. The Snippet Control Tester is relevant when you want to limit how much of a page may be previewed; it does not replace a first paragraph that is already fit to quote.

Structure that a crawler can lift

Assistants and snippets do better with a page they can outline:

• One H1 that matches the job of the page.
• H2s that are real questions or real steps, in a sensible order, with H3s only where a section needs a sub-topic.
• Short paragraphs, lists where a list is the natural form, and tables only when the comparison is genuinely tabular.
• Descriptive link text, so a lifted sentence still names the destination.
• Important meaning in the first HTML response, not only after JavaScript, as I describe in why Google and AI see different HTML.

The Answer Engine Structure Analyser looks for that kind of skeleton: a visible answer, headings that can be lifted, and questions that actually appear on the page. It cannot tell you whether the advice is correct.

Do not fetishise a particular heading formula. “What is X?”, “How to Y” and “When not to Z” are useful when they match the section. A page of twelve identical “Best X for Y in 2026” headings is a pattern, not a structure. The Word Counter will tell you if a section has bloated; it will not tell you if the heading is doing work.

JSON-LD can label an article, a breadcrumb and a visible FAQ, which I cover in the JSON-LD guide. Markup helps when it matches the page. It will not supply a missing answer.

Facts, limits and the things you will not invent

The fastest way to make a page unusable as a source is to fill it with unearned certainty: invented percentages, anonymous “studies”, prices you have not checked, quotes nobody said, and product rankings with no method. If an assistant repeats those, it is repeating your fiction, and a careful reader will eventually notice.

A better habit:

• State facts you can check, and say where they come from, preferably a primary document (Google, Apple, HMRC, the ICO, a specification).
• When a number can change — a VAT threshold, a Core Web Vitals figure, a list of crawlers — date it and point to the place to confirm it. Do not present it as permanent.
• Say when you do not know, or when a behaviour varies by product and week.
• Prefer a worked example, with imaginary but clearly labelled details, over a fake case study.
• If you use first-person experience, make it specific and inspectable: this site, this tool, this app, this release habit. “In my years in the industry” is not evidence.

The llms.txt guide is the same rule applied to a site index: only checkable facts and working links. Writing for answers is that rule applied to paragraphs.

Experience that is specific and checkable

Experience is how a page earns the right to be cited over a generic rewrite of the documentation. It is not a biography at the top of every article, and it is not a claim to be the leading expert. It is the detail a documentation page does not have:

• The sequence you actually run before a release.
• The trap you fell into, such as noindex plus Disallow, and how you check for it now.
• The split you use on this site between a tool page and a guide, or between a short llms.txt and a generated full file.
• A limit of the work: what the tool does not validate, what a ping does not guarantee, what you cannot test on a phone from a particular desktop.

That is E-E-A-T in practice: experience, expertise, authoritativeness and trust, shown in the work, not asserted in an author box. If you have not done the work, do not fake the anecdote. Write a careful summary of the official docs, and say that is what it is. An honest summary of a specification is more useful than a pretend war story.

The same bar appears in the iOS app MVP checklist: ship the smallest thing that is real, not a slide that claims a product you do not have.

FAQs, summaries and what belongs on the page

A FAQ section is useful when it answers questions a person would actually ask after the main explanation, in words that already appeared or that add a genuine short variant. It is a poor place to hide the real article, and a poor place to stuff extra keywords.

Write the questions in the page, as visible headings with answers beneath them. If you also mark them up as FAQPage, the markup must match those visible answers. Do not maintain a second set of questions that exists only in JSON-LD.

A short “Key takeaways” list at the end is a convenience for a scanner. It should not introduce new claims, and it should not be the first time the answer appears. The opening paragraph still has to do that job.

Summaries in meta tags, in llms.txt and in social previews should be consistent with the page. If any of them is more extreme than the article, you have created a source of drift.

The padding, bait and thin rewrites to avoid

A few patterns make a page worse for both kinds of reader:

• Preamble. “In today’s fast-paced digital world” and its cousins delay the answer and give a snippet nothing to use.
• Keyword stuffing and synonym loops that repeat the same sentence with different nouns.
• Thin rewrites of official docs, especially when they go stale and the documentation does not. If you cannot add a method, an example or a limit, link the primary source and keep your page to what you are adding.
• Clickbait titles that the first paragraph cannot support. The person and the model will both notice the gap, and the model may still quote the title.
• Fake completeness: a list of “50 tools” with no method, a “study” with no citation, a price or a ranking with no date or source.
• Doorway or interchangeable pages that only exist to catch a variant of the same query. That is also how you cause keyword cannibalisation.
• Content that is not in the first response. If a crawler or a fetcher never sees the paragraph, it cannot cite it.

I would rather publish fewer, complete pages than a cluster of thin ones. That choice also keeps the site easier to maintain.

A short editing pass before you publish

Before a page goes live, I read it once as if I were going to quote it in someone else’s answer:

1. Does the first paragraph answer the title, including the important limit?
2. Can I outline the page from the H2s alone, and do those headings match the sections?
3. Is every number, product claim and “always” or “never” either checkable or qualified?
4. Is the first-person experience specific, or could I delete it without losing a fact? If I could delete it, it may be decoration.
5. Would I be comfortable with an assistant repeating any sentence out of context? If a sentence is dangerous without its neighbour, tighten it.
6. Run the structure and readability checks, and fix real problems, not scores for their own sake.
7. Confirm the main text is in the raw HTML, the title and description are accurate, and the visible FAQ, if any, is the one you meant to ship.

That is enough. You do not need a separate “AI optimisation” pass that adds more headings and more FAQs after the writing is done. If the page is already a clear, honest answer, you have done the work that still holds when the products change.

Key takeaways

• Write one page for a person and for a machine that might quote it. The person still comes first, and no method can promise a citation in an AI answer.
• Answer the title in the first paragraph, including the limit that belongs in the truth, then use headings a crawler can lift.
• Include only checkable facts, dated where they can change, and experience that is specific to work you have actually done.
• Keep FAQs and summaries consistent with the visible page, and put the meaning in the first HTML response.
• Cut preamble, invented statistics and thin rewrites. Edit once as if a stranger were about to quote you.

If you want a second pair of eyes on a page before you ask anyone to cite it, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.