Answer engine optimization is the work of structuring a page so a machine can lift a correct answer out of it — a direct response near the top, headings shaped like real questions, unambiguous entities and markup that parses. It is narrower than GEO: AEO is about the page, GEO is about your presence across answers.
Almost none of it is new. What is new is the cost of getting it wrong. A ranking algorithm would forgive a page that buried its answer under four paragraphs of introduction; an engine looking for a passage to quote simply takes someone else's.
What an answer engine is
An answer engine responds with the answer rather than with a list of places the answer might be. That covers featured snippets, voice assistants, Perplexity, ChatGPT and Google's AI Overviews — a range wide enough that the term is doing a lot of work. They divide into two behaviours, and the difference decides what you optimise for:
- Extractive — the engine finds an existing passage and shows it. Featured snippets work this way. Here the passage on your page is literally the output, so how it is written is the whole game.
- Generative — the engine writes new prose grounded in several sources. Your passage is not shown; it is read. What matters is whether it is clear enough to be understood and attributed.
AEO and GEO are not rivals
They get sold as competing disciplines. They are a layer and a scoreboard.
- Is the answer stated, early and completely?
- Can a parser tell what this page is about?
- Is the markup valid and honest?
- Checkable on one URL, deterministically
- Entirely within your control
- Are you named in the answers people get?
- On which engines, and how consistently?
- Who is named when you are not?
- Only measurable by sampling, over weeks
- Partly decided by pages you do not own
You can do the left column perfectly and still be absent from the right — that is the normal case for a new site, and it is why the GEO guide spends its time on sources you do not control. But the left column is the part you can finish this week, and skipping it makes everything after it harder.
The structural checklist
One direct answer, near the top
A single paragraph, roughly 40 to 320 characters, that answers the page's question outright and survives being lifted away from its surroundings. No “in this article we will explore”. If the paragraph needs the one before it, it is not the answer yet.
Headings that are the questions
How much does it cost beats Pricing. What it does not do beats Limitations. Each heading should mark a passage that can be quoted on its own, because that is the unit an engine extracts.
One H1, and a real hierarchy
Heading levels are the outline a parser reads. Skipping from H1 to H4 because it looked right is the most common structural fault on otherwise good pages.
Facts, in a form that survives summarising
Numbers, dates, named limits, prices, constraints. An adjective cannot be attributed to you; a figure can. This is also the difference between a page a model cites and a page it paraphrases without credit.
A visible date
Not only in metadata — on the page, where a reader sees it. It is a trust signal for people and a freshness signal for machines, and it costs one line.
Schema that earns its place
Structured data does one job: it removes ambiguity about what a page is and which entity it belongs to. It is not a ranking lever and treating it as one leads to markup that describes a page nobody wrote. Four types carry most of the value:
- Organization — who publishes this. The link between a site and a brand entity, and the one most often missing.
- Article — author, published and modified dates. What lets an engine date your content without guessing from the copy.
- FAQPage — question and answer pairs, the shape extraction likes most.
- BreadcrumbList — where this page sits. Cheap, and it makes the site structure explicit rather than inferred.
E-E-A-T, read by a machine
E-E-A-T — experience, expertise, authoritativeness, trust — is Google's framework for its human quality raters. It is not a score, there is no E-E-A-T field, and no engine exposes one. What it is, usefully, is a list of things that happen to be machine-readable when you do them properly:
- A named author with a real biography, on a page that exists, linked from the article. “Admin” and “Editorial Team” carry nothing.
- Citations to primary sources, linked. A statistic with a link is checkable; the same statistic bare is a claim.
- Stated limits. A page that says what it does not cover reads as written by someone who knows the subject — to a reader and to a model.
- A findable organisation behind the site: contact details, terms, a real address. The unglamorous pages are trust signals.
llms.txt, and its honest status
llms.txt is a proposed file at your site root that lists your key pages in Markdown, so a model can find what matters without crawling everything. The idea is sound and the implementation is trivial.
No major engine has committed to reading it. It is a proposal, not a standard, and treating it as required is overselling. Publish one because it takes ten minutes and costs nothing — not because you expect a measurable change from it alone. Our generator builds one from your real sitemap rather than asking you to write it, and it says the same thing about adoption that this paragraph does.
What our audit checks, and why
Everything above is checkable on a single URL without asking a model anything, which is why we made it free. The audit runs 31 deterministic checks in 7 groups — the same HTML always produces the same score, and every check reports the value it actually found rather than a pass or fail.
Every check reports the value it found, not just a pass or a fail — and a check that cannot apply to a page is removed from the score rather than failed.
A factor that cannot be measured on a given page is removed from the score rather than counted as a failure — a page with no images should not lose points on image alt text. That sounds like a detail; it is the difference between a score you can act on and one you learn to ignore.
Run it on any URL, including one that is not yours: the free 31-check audit.
Questions people ask
Is AEO different from SEO, or is it a rebrand?
It is a narrower discipline that sits inside SEO rather than beside it. AEO is specifically about making a page's answers extractable — a direct response near the top, headings shaped like questions, unambiguous entities, markup that parses. All of that has always been good SEO. What the label adds is a reason to prioritise it, because an engine quoting a passage is less forgiving of a page that buries its answer than a ranking algorithm was.
Does FAQ schema still work?
As a rich result in Google, largely not any more — that display was restricted to a small set of sites. As a machine-readable statement of question-and-answer pairs, it still does exactly what it always did, and question/answer is the shape engines extract most readily. Add it because it describes your content accurately, not because you expect stars in the results.
Will marking up content that is hidden on the page help?
No, and it is the fastest way to get structured data penalised. Every question and answer in your markup must be visible to a reader. This is the single most common structured-data violation and no validator can catch it from the markup alone — including ours, which says so rather than pretending otherwise.
Do I need llms.txt?
It is cheap and harmless, and no engine has committed to reading it. It is a proposal, not a standard, and anyone telling you it is required is overselling. Publish one because it takes ten minutes and costs nothing; do not reorganise your site around it or expect a measurable change from it alone.
How long should an answer paragraph be?
Roughly 40 to 320 characters — long enough to be a complete thought, short enough to be quoted whole. Our audit uses that band. The underlying principle matters more than the number: the passage has to stand on its own when lifted away from everything around it.
Does E-E-A-T apply to AI answers?
The signals do, even though the acronym is Google's own framework for human raters rather than a machine-readable specification. A named author with a real biography, a visible date, citations to primary sources and a clear organisation behind the site are all things a model can parse and a reader can verify. That is worth doing regardless of what any one engine calls it.