Answer engine optimization.

Answer engine optimization is the work of increasing the probability that a site is chosen as a source in the answers produced by ChatGPT, Perplexity, Google AI Overviews and similar generative systems.

For twenty years, search optimization had a single question: what position does this page rank at? Behind the question sat an assumption — the user would see a list of links, click one, and arrive at the site. Generative systems broke that chain. The user now asks a question and receives a single answer; inside that answer a few sources are mentioned, or none at all.

This page explains what can be done in that new situation. One boundary needs drawing from the start: most of what is described here is a continuation of SEO, not an alternative to it. Google’s own guidance points the same way — there is no separate technique for appearing in generative features, only a layer added on top of good SEO.

What changed, what did not

Here is what did not change: answer engines do not pull content out of thin air. Google’s generative features feed on its own index; ChatGPT’s search mode and Perplexity crawl in real time. A page that is not indexed, cannot be crawled, or cannot be read will appear in no answer engine. The foundation of technical SEO stands exactly where it stood.

What changed is the logic of selection. In classic ranking, a page competes as a whole; in an answer engine, the competing unit is the PASSAGE. When a model composes an answer, it does not take the whole page — it takes the one section that answers the question on its own. That is why a well-structured page made of self-contained sections holds a clear advantage over a page that scatters the same information.

According to industry reports, two trends make the difference concrete. First, the overlap between classic ranking and being cited in answer engines has narrowed visibly — once, most top-ranked pages were also the cited pages; that link is now weak. Second, a notable share of citations comes from pages ranked below the top five. Together they say one thing: citation and ranking are not the same race.

Citation and ranking are not the same race — but both feed on the same index.

This does not make ranking unimportant. Getting indexed is still the precondition, and ranking high still means visibility. But there is now a second race, and that race has different rules.

Five levers

What determines visibility in an answer engine can be gathered under five headings. The order is roughly by impact — but none of them substitutes for another.

1. Access — can the crawler reach the page? robots.txt permission, server response, dependence on JavaScript. If this layer is broken, the rest is meaningless.
2. Readability — page structure, heading hierarchy, passage boundaries. This is how the model knows where one thing ends and another begins.
3. Intelligibility — structured data, entity links, explicit definitions. It describes what the page is about not sentence by sentence but entity by entity.
4. Credibility — who wrote it, what it rests on, whether it can be verified. The answer-engine counterpart of E-E-A-T.
5. External corroboration — being mentioned in other sources. On-site excellence alone is not enough; models prefer information that several sources agree on.

Mind the last item: it is the only lever that lives entirely outside the site, and it is the most neglected one. However well a site is built internally, it cannot pass a certain ceiling if nowhere else talks about it.

Access: the most basic and most often broken layer

The first step of answer engine optimization is making sure AI crawlers can enter the site. On most sites this is already the case — a general allow rule covers all crawlers. But making a deliberate decision is different from permitting by accident.

On this site the crawler groups are written out one by one, and seventeen agents are explicitly welcomed: Googlebot and Bingbot on the search side; GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, Google-Extended, Applebot-Extended and others on the generative side. The general rule already allowed them all; writing the groups explicitly achieves two things — some crawlers only read their own group, and the intent is documented.

The second access question is JavaScript. Search engine crawlers can execute JavaScript, but most crawlers of generative systems do not, or do so in a limited way. A page whose content exists only client-side is an empty shell to those crawlers. If the real content is in the HTML that comes from the server, this risk never arises.

Readability: the passage boundary

When a model takes a citation from a page, it derives where the quoted section starts and ends from the document structure. A section gathered under a heading and complete in itself can be cited; a sea of text without headings cannot — the model does not know where to cut.

This is the direct counterpart of work already done for accessibility. The structure a screen reader user needs to jump from heading to heading is the same structure a model needs to find a passage boundary. A document organized for one is organized for the other.

The practical rule: let every section answer a single question, and let the first sentence of that answer be correct without context. A paragraph that begins with “as we explained above” collapses when quoted; a sentence that stands on its own survives quotation.

Intelligibility: the language of entities

Structured data is the layer that changes not a single pixel of the page yet is read most carefully by machines. It describes the site to a model not sentence by sentence but entity by entity: this is an organization, that is a person, this is a service, and here is how they connect.

On this site’s service pages sits a graph of eight nodes — organization, person, website, service, how-to, frequently asked questions, breadcrumb trail, and the page itself. The nodes are linked by identity, so a model can derive the answer to “who provides this service” straight from the graph.

The critical rule is this: everything written in the schema must also be on screen. Information that lives only in the schema is both a violation of search engine rules and a contradiction of the page itself. The correct practice is for the schema to translate into machine language what the screen already shows.

What is in the schema must be on the screen; telling a machine something that is not there is lying to one of your two readers.

Credibility and external corroboration

Before a model puts a piece of information into its answer, it weighs it — and consistency leads the criteria: if the same information appears in the same form in several independent sources, confidence rises. This signal is independent of how well any single site is built internally.

The practical consequence is that on-site work has a ceiling. To rise above that ceiling, you must exist off-site too: profile records, directories, open-source contributions, industry publications, community participation. Industry reports show community platforms among the sources most often cited by answer engines.

Author identity matters within the same frame. Who wrote a page, where else that person appears, and what the claims rest on — the three together determine the weight of the content. Declaring them in the schema and showing them on screen gives the same information to both readers at once.

Measurement: what to watch

Measuring answer engine visibility is harder than measuring classic ranking because there is no stable “position” — ask the same question twice and different sources may be mentioned. Still, there are things worth tracking.

1. Ask the target questions by hand — ask the fifteen questions of your field in the same engines every month and record which sources get mentioned.
2. Read the crawler logs — which pages are GPTBot, ClaudeBot and PerplexityBot fetching, and how often? This is the real evidence of the access layer.
3. Track brand mentions — answers where the name appears are a signal even without a link.
4. Keep the classic measurements — index status and query data are still the foundation; the answer engine rides on top of it.

A concrete example of the last item is this site’s own situation. The Search Console reading dated 22 August 2026 said: 57 pages indexed, 13 pages crawled but NOT indexed, one impression in total. Crawled-but-not-indexed is not a crawl error, it is a quality verdict — and a gap that must be closed before moving on to answer engine optimization. A page that is not in the index can be mentioned in no answer.

This also explains why the rest of the cluster is built in this order: access and readability first, then intelligibility, and external corroboration last. The order can be skipped — but when it is, the upper layers run on empty.