Built to be quoted.

Answer engines return passages, not pages

When a buyer asks ChatGPT, Gemini, Perplexity, or Google's AI Overviews a question, the engine assembles an answer from passages it can lift cleanly, then cites the sources it lifted from. Whole pages never appear in an answer; extracted fragments do. Answer Engine Optimization is the discipline of structuring your pages so those fragments are yours.

Ranking is no longer the finish line. A page can sit in the top ten, get retrieved, and still contribute nothing to the answer because no passage inside it survives extraction on its own. Industry studies put a top-ten Google ranking at roughly a one-in-four chance of appearing in AI answers; structure explains much of the gap.

We diagnose where a brand stalls with our 6-Phase AI Visibility Framework: Baseline, Extractability, Category Formation, Attribute Recall, Proof & Trust, Competitive Selection, Amplification. Each phase gets a pass or fail and a named fix. The most common wall: a brand AI describes accurately when asked directly, yet never surfaces in category questions. That is an extractability and evidence problem, and a fixable one.

The answer shape: five elements per money page

From reverse-engineering hundreds of AI Overviews, we standardized the block AI engines extract most reliably. Every commercial page opens with it: a one-sentence direct answer, three to five bullets that each start with the brand name, one numeric table or comparison row, one honest 'things to consider' caveat, and a citation set.

The caveat does real work: engines score objectivity, and pages that admit trade-offs get quoted where pure sales copy gets skipped. In our extraction testing, pages rebuilt into this shape are lifted at seven to nine times the rate of flowing prose.

Definitions follow the same logic. Glossary and explainer entries open in the dictionary shape, '[Subject] is a [category] that [does X]', marked up as DefinedTerm. Engines quote clean definitions verbatim and skip essays that circle the point.

Chunk cards: 250-token blocks built for retrieval

Retrieval systems split pages into chunks before a model ever sees them, so we write in the unit retrieval actually uses. Every H2 section becomes a self-contained card of roughly 250 tokens: a question-shaped heading, a one-sentence definition, three to five bullets, one numerical claim, one source link. The rule is blunt: if a chunk makes no sense alone, the engine rejects it.

The markup layer tells machines what the prose means. Speakable schema flags the sentences safe to quote verbatim; FAQ and DefinedTerm schema type the content; deterministic anchor IDs on every H2 let a citation land mid-page. All of it ships server-side rendered, because most AI crawlers read raw HTML and never execute JavaScript.

Trust density and the extraction test

AI engines hedge about brands they cannot verify: 'appears to be', 'according to its website', 'limited customer feedback'. Each hedge maps to one under-evidenced attribute. The fix is mechanical: place three independent confirming sources for the claim, retest, and the hedge disappears.

Review density is part of the same system. Below a floor of roughly 200 reviews at a 4.3+ average on the platforms AI checks, models qualify their answers, and review platforms sit inside the majority of AI comparison answers we log. Named author bylines, reviewed-by attribution, and a visible last-updated date complete the trust layer.

Nothing is assumed to work. We re-run the buyer prompt set engine by engine in fresh sessions and check that the new blocks are the ones being quoted. Extraction either happens or it does not; that is the acceptance test.