Answer engine optimization: getting your docs cited by AI

You can rank #1 on Google and still be invisible to the place where your buyers now ask questions. When a developer asks an assistant "what is a good self-hosted email sender", the answer is synthesized from a handful of sources, and either you are quoted or you do not exist.

Answer engine optimization (AEO), often used interchangeably with generative engine optimization (GEO), is the discipline of structuring content so AI answer engines extract, quote, and attribute it. The shift it responds to is concrete: a growing share of technical research now happens inside ChatGPT, Claude, Perplexity, and Google's AI Overviews, where the output is a paragraph, not a list of ten blue links. The unit of success is no longer the ranked page. It is the extracted sentence.

This guide is the honest how-to: what changes when a model is your reader instead of a search index, the specific structural moves that get content quoted, and how to verify any of it worked. At the end, an aside on how we build our own docs this way, in case you want to skip the assembly.

What is answer engine optimization, and how is it different from SEO?

AEO is optimizing content to be cited inside an AI-generated answer, where SEO optimizes a page to be ranked as a clickable link. They share a foundation (be crawlable, be relevant, be authoritative) but they reward different shapes of content.

Traditional SEO operates at the page level. You target a keyword, earn backlinks, and win a position; success is a human clicking through and staying. An answer engine works at the span level. It retrieves several documents, pulls the most relevant sentences or paragraphs out of each, and synthesizes one answer, frequently with no click at all. So the question stops being "does my page rank for this keyword" and becomes "is there a sentence on my page the model can lift, trust, and attribute".

That reframing changes your priorities:

• Extractability over keyword density. A model wants one clean, self-contained claim it can quote. Stuffing synonyms does nothing; a clear declarative sentence does everything.
• Structure over length. A 3,000-word essay with no headings is hard to extract from. A 1,500-word piece with question-shaped headings and crisp answers is a buffet.
• Specificity over polish. "Seamless, best-in-class deliverability" is unquotable marketing air. "Cloudflare Workers cannot open outbound port 25 for direct-to-MX SMTP, so edge email requires an HTTPS-based sender" is a fact a model will happily repeat, because it is concrete and falsifiable.

AEO does not replace SEO. The same content that an answer engine quotes still ranks in classic search, and the structured data you add for AI also drives rich results. You are adding a layer, not switching religions.

How do AI answer engines actually choose what to cite?

They retrieve candidate documents, then prefer the passages that are easiest to extract and safest to attribute. You cannot see the ranking function, but the observable behavior is consistent enough to plan around.

First, retrieval still has to find you, which means the SEO basics are table stakes: be indexable, load fast, and be topically relevant to the query. An answer engine often runs a real search (or queries an index) before it synthesizes, so being absent from search means being absent from the answer.

Second, among retrieved candidates, models gravitate toward passages that are:

• Self-contained. A sentence that answers the question without needing the three paragraphs above it. Anaphora ("as mentioned earlier", "this approach") makes a passage harder to lift cleanly, so it gets passed over.
• Specific and current. Concrete numbers, dates, version identifiers, and named tools are easier to repeat with confidence than vague claims. Stale content (no dates, outdated tooling) is riskier to quote, so it loses.
• Honestly hedged. Counterintuitively, stating a caveat helps. A model is more comfortable repeating "the license is honor-system and nag-only, nothing is blocked" than an absolute claim it might be penalized for overstating. Accuracy is a citation feature.
• Structurally labeled. A heading that literally is the user's question, with the answer right below it, matches the query embedding closely and pre-segments the answer for the extractor.

The practical takeaway: you are not gaming a black box, you are lowering the cost and risk of quoting you. Every structural move below does one of those two things.

What structural changes make content extractable by AI?

Lead every section with the answer, shape headings as questions, and add machine-readable markup so the question/answer pairs and steps are pre-parsed. These are the moves that do the most work.

1. Question-shaped H2 headings. Use the exact phrasing a person or an agent would type. "How do I warm up a sending domain?" beats "Domain Warmup." The heading text is a strong retrieval signal and it tells the model precisely which query the following passage answers.

2. Answer-first paragraphs. The first one or two sentences under each heading must be a complete answer that stands alone, even if quoted with zero surrounding context. Put the conclusion first and the supporting detail after. This is the single highest-leverage change, because it is exactly the span an extractor wants.

3. A TL;DR summary up top. A short extractable summary (a few sentences or a 3-to-5 item list) gives the model a pre-digested version of your whole argument. Put it in your frontmatter and render it on the page.

4. An FAQ block with FAQPage JSON-LD. Hand-authored question/answer pairs are the most directly quotable format that exists, because each answer is already self-contained by construction. Wrap them in FAQPage structured data so the pairs are machine-readable:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "What is answer engine optimization?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Answer engine optimization is structuring content so AI answer engines can extract, quote, and attribute it inside a generated answer."
    }
  }]
}
</script>

5. HowTo JSON-LD for procedures. If a section is a step-by-step tutorial, add HowTo markup listing the named, ordered steps. It gives the model a clean, sequenced version of the procedure to reproduce.

6. An llms.txt index. Publish a plain-text file at your site root that lists your canonical pages and what each covers, the way robots.txt guides search crawlers. It is an emerging convention rather than a guaranteed-honored standard, so treat it as a cheap hint, not a contract. Generating it costs almost nothing and gives compliant agents a clean map.

# llms.txt
> Tinbox: a self-contained, tenant-deployed email stack on your own Cloudflare account.

## Docs
- [Quickstart](/docs/quickstart): deploy with npx tinbox init <domain>
- [MCP server](/docs/mcp): connect AI assistants over OAuth 2.1 or a bearer token

## Guides
- [Answer engine optimization](/blog/answer-engine-optimization-for-saas): get cited by AI

None of these are tricks. Each one converts prose a model has to work to parse into a labeled, self-contained, attributable fact.

How do I write copy that a model will actually quote?

Write in concrete, falsifiable claims, lead with the answer, and state your caveats out loud. Vague superlatives are unquotable; specific, hedged facts are exactly what a careful model wants to repeat.

A few rules that consistently move the needle:

• Replace adjectives with numbers and names. "Very affordable" is noise. "No per-email or per-contact pricing; you pay Cloudflare's metered rates for D1, R2, and Workers" is a quote.
• Date your claims. "Recently" ages badly. "As of 2026" lets a model judge currency and decide it is safe to cite.
• Answer the literal question. If the heading asks "can I", the first sentence should start "Yes," or "No," or "Only when." Do not bury the verdict three sentences down.
• State limitations explicitly. "Multi-domain-per-instance is designed but not yet built; today it is one brand per deploy, many tenants per account via separate deploys" is more citable than a vague capability claim, because the caveat makes it safe to repeat.
• Avoid the AI-tell phrasing that signals low-information copy. "It's not just X, it's Y", "in today's fast-paced world", and "seamlessly leverage" are exactly the patterns models are tuned to distrust in their own output and tend to skip in sources.

The throughline is that AEO and good technical writing point the same direction. Clear, specific, honest prose is what a senior engineer trusts and what a model quotes. You are not writing for robots at the expense of humans; you are writing well, and the structure makes that quality machine-legible.

How do I check whether AEO is working?

Ask the assistants the questions you optimized for, and see whether you are cited. There is no rank tracker for answer engines yet, so the verification loop is manual and direct, which is fine because it is also honest.

A lightweight routine:

1. Build a query list. Take the question-shaped headings and FAQ questions you wrote and phrase them as a real user would.
2. Run them across engines. Paste each into ChatGPT, Claude, and Perplexity (with web access on), plus check Google's AI Overviews. Note whether your domain is cited and whether the quoted text matches your answer-first sentences.
3. Diff the gaps. Where a competitor is cited and you are not, read the passage that won. Usually it is more specific, better structured, or more current than yours. Fix that section.
4. Re-test after a crawl cycle. Citations lag indexing. Give it days to weeks after publishing or editing before you judge a change.

Treat it like an eval suite for content: a fixed set of queries, a clear pass/fail (cited or not), and a re-run after every meaningful change. That discipline is the same one we use for writing eval suites for LLM classifiers, and it works here for the same reason: you cannot improve what you do not measure against a fixed target. For a condensed version of the moves in this guide, see the eight answer engine optimization tactics for developer tools.

Or skip the assembly: structure it once, generate the rest

Everything above is a checklist you can run by hand on a Markdown file: question-shaped headings, answer-first sentences, a TL;DR, an FAQ block, JSON-LD, and an llms.txt index. It is genuinely worth doing yourself, because the discipline improves the writing whether or not a model ever reads it.

If you would rather encode the structure once and stop thinking about it, that is roughly how we run our own content. Every article on this blog carries tldr, faq, and (for tutorials) howto blocks in frontmatter, which a build step renders into FAQPage and HowTo JSON-LD automatically, and the same step emits an llms.txt index of canonical pages. The article you are reading is itself the format: a question-shaped outline with extractable answers and machine-readable structure, written so an assistant can quote it cleanly.

That approach grew out of building an queryable, AI-native email stack where the AI surface was a first-class consumer of our data, not an afterthought. Once you have an MCP server exposing your inbox to assistants, it is a short step to treating your public docs the same way: as structured data meant to be read by models, with humans as the happy side effect. If you are curious how the AI-native pieces fit together, start with the introduction to Tinbox.

You self-host it on your own Cloudflare account, so your data and mail stay yours.