What answer engine optimization means
An answer engine takes a question and returns a composed answer, citing or paraphrasing sources it retrieved along the way. Assistants, AI overviews in classic search, and the shopping and research agents built on top of them are all answer engines. Answer engine optimization, usually shortened to AEO, is making your page one of the sources that survives that process intact.
The distinction that matters is not a new ranking factor. It is that the thing reading you has changed shape. A browser renders; a parser does not. A human skims past navigation to find a price; a parser spends context on every byte of that navigation before it reaches the price, and may stop first. Most of AEO is a consequence of that single difference.
How answer engine optimization works, mechanically
Being quoted in an answer requires four things to go right in sequence. Each one can fail on its own, and a failure early makes everything after it irrelevant, which is why the order below is also the order to fix them in.
- The fetch is allowed. The agent requests your URL and your infrastructure answers. A
robots.txtline, a CDN bot filter, or a challenge page written years ago against scrapers ends the process here, silently, with no error anyone on your side will see. - The response is parseable. What comes back is text the model can read. Anything that appears only after JavaScript runs does not exist, because the fetch runs no JavaScript.
- The facts are cheap to reach. The answer engine reads under a token budget. If your first substantive fact sits behind tens of thousands of characters of markup, it may be summarised badly or dropped for something shorter elsewhere.
- The facts agree with themselves. Your text, your structured data, and your feed say the same thing. A page whose JSON-LD covers hours but omits fees produces a confident, incomplete answer, which is worse for you than no answer at all.
Notice what is absent from that list: keyword placement, word count, and heading density. There is no position in a generated answer to compete for, so the tactics built around occupying one have nothing left to act on. The levers are all on the serving side.
Where AEO and SEO diverge
AEO is not a replacement for SEO and the two rarely conflict. Classic search still sends most of the traffic on most sites, and the crawlability work it rewards is the same work an answer engine needs. What changes is which properties of a page carry weight once it has been retrieved.
| Classic SEO | Answer engine optimization | |
|---|---|---|
| The reader | A crawler on its own schedule | A parser answering a question asked seconds ago |
| The unit of success | A ranked position | Being usable as a source |
| What layout does | Helps the human who clicks through | Costs context before the facts arrive |
| Client-side content | Often rendered and indexed | Absent from what the fetch returns |
| Response size | Affects speed scores | Directly limits how much of you is read |
| Feedback loop | Weeks | One request |
The label question comes up constantly and is worth settling once: AEO, GEO and LLM SEO describe overlapping work under different names, sold by different people. GEO vs SEO takes the comparison apart properly, and the pillar guide covers where all four names land.
The method, in order
Cheapest first. Each step either finds the problem or rules it out, and the first three are usually enough to explain a site that answer engines never quote.
- Take the baseline before touching anything. Score a page of each template against a published spec and keep the number. Teams that skip this are the ones who cannot later prove the work was worth doing.
- Audit the bot rules as a decision. Read every
robots.txtline and CDN filter and ask whether you would write it today. Most blocks on assistants were inherited, not chosen. - Answer
Accept: text/markdown. This is the single change with the largest effect, and it is serving-layer work rather than content work. A mid-2026 study across 300k domains found roughly 4.2x more accurate retrieval from content negotiation than from a static index file alone. - Move the first fact forward. For each template, find the character offset of the fact a person would actually ask about and cut what sits above it. Price, hours, fees, eligibility, contact.
- Make the structured data agree. Same fields, same values as the prose. Fix disagreements rather than adding more markup.
- Publish a curated index. A generated
/llms.txtthat lists your real pages. Ship it, but do not treat it as the strategy: on its own it did not move retrieval accuracy in that study. - Read the miss log. Once agents are being answered, the list of URLs they asked for and did not get is the highest-value document in the project, because it names the next fix in the order the market is asking for it.
What the change is worth, measured
Two reference captures, both deterministic and rebuilt from committed fixtures on every build. They are quoted separately rather than averaged, because a product page and a services page carry different amounts of chrome and a blended figure would describe neither.
| Capture | Before | After | First fact moves |
|---|---|---|---|
| Commerce product page | 91,226 bytes | 1,315 (−98.6%) | Character 23,185 → line 4 |
| Clinic services page | 13,581 bytes | 1,412 (−89.6%) | Character 10,152 → line 8 |
That is roughly 69× less context on the commerce capture and 9.7× fewer tokens on the document one, for the same facts. Quote whichever matches your own site rather than the more impressive one.
- Conversion lift, AI-referred visitors vs search
- ~38%
- Cyber Week 2025 retail data
- Content negotiation vs llms.txt, accurate retrieval
- ~4.2x
- 300k-domain study, mid-2026
What you can measure, and what nobody can promise
This is the part of AEO most likely to be oversold, so it is worth being precise about three tiers. They belong in a proposal in this order.
| Tier | Examples | How to treat it |
|---|---|---|
| Measurable and controllable | Whether the fetch is answered, response size, first-fact position, readability score | Commit to it. These are properties of your own server and they move the week you ship |
| Measurable, not controllable | Agent visits by platform, answer rate, the miss log, AI-referred sessions | Report it, with a baseline taken before you start |
| Neither | Being named in a given assistant’s answer to a given prompt | Never promise it. Assistants are not deterministic and no vendor controls their output |
Four mistakes that cost the most
- Buying visibility tracking before fixing serving. A tracker tells you that you are not being quoted. It cannot make you quotable, and the fix is nearly always upstream of it.
- Shipping facts client-side. A price or fee table that appears only after JavaScript runs is invisible to every answer engine, and this single item explains more bad scores than the rest combined.
- Treating
/llms.txtas the deliverable. Publish it, then keep going. On its own it did not move accurate retrieval in the 300k-domain study. - Promising citations. No vendor controls an assistant’s output. Selling a guaranteed mention is the fastest way to make the whole discipline look like a scam.