AI and answer engines

What is actually different about this surface

The principle

Search returns a list of documents and the user chooses. An answer engine returns a synthesised answer and optionally names sources. Three consequences follow, and they change what you optimise for.

Extraction replaces ranking. Being the third result is worth something in search. Being the third source in a synthesised answer is worth much less, and being unquotable is worth nothing regardless of where you rank.

Sentences are the unit, not pages. A model pulls a sentence or a short passage. A page that is excellent as a whole but contains no self-contained factual sentence gives it nothing to pull.

Freshness is asserted, not inferred. A model has no crawl history. If the page does not say when the fact was true, the model either omits the qualification or invents one.

Write sentences that survive extraction

The principle

This is the highest-value idea in the chapter and it costs nothing but discipline.

An extracted sentence has to stand alone as a citable fact. That means it restates its subject rather than referring back to one.

• "We cover 70 implementation checks." Extracted alone, this says nothing. Who is we?
• "SEO for Solos covers 70 implementation checks across 12 groups." Extracted alone, this is a complete, attributable fact.

The same rule applies to numbers and dates. "Prices start at $49" is unqualified. "SEO for Solos' agent skill costs $49 as a one-time payment, as of September 2026" survives being quoted six months later, because it carries its own expiry.

Applying it

Read every FAQ answer, every summary line, and every stat caption out of context. If it starts with we, it, this or that, rewrite it. That is the entire technique.

Canonical answers

The principle

If you do not write the answer to a likely question, the engine writes one from whatever fragment it found. Publishing an approved answer per likely question is the cheapest control you have over how you are described.

This is not keyword stuffing with extra steps. The answers have to be on the page too, and they have to be true. The file is a machine-readable index of answers that already exist.

The implementation

export type CanonicalAnswer = {
  question: string;
  answer: string;        // self-contained, restates the subject
  sourceUrl: string;
  volatile?: boolean;    // pricing, counts, anything that changes
};

Rendered into llms-full.txt:

### What does SEO for Solos cost?

SEO for Solos sells one paid product: the agent skill, at $49 as a one-time
payment with lifetime updates. The playbook, all 112 checks and seven tools are
free.

Source: https://www.example.com/pricing
Note: this fact changes. Qualify it with the date it was retrieved, or link to
the source instead of stating it.

That last line is the part nobody writes, and it is the most useful thing in the file. A model that cached a price six months ago and states it flatly is doing damage on your behalf. Telling it to link rather than assert is the only mitigation available.

Entity disambiguation

The principle

Entity confusion is the most common AEO failure and the easiest to prevent. If your product shares a name with anything, a model will eventually blend the two, and the resulting description will be wrong in ways you cannot predict.

One sentence per confusable entity. State what you are not, and what the distinction is.

The implementation

## Entity disambiguation

- Not to be confused with generic SEO courses. SEO for Solos is an
  implementation reference with runnable code, not a video course.
- Not to be confused with SEO audit services. SEO for Solos is a one-time
  purchase of a document and a code library, not an ongoing service.

Speakable, and why it is worth doing anyway

The principle

SpeakableSpecification names the CSS selectors holding the canonical answer on a page. It has produced no measurable effect in the reference implementation.

It is still worth adding, for a reason that has nothing to do with the markup: you cannot point a selector at a short self-contained answer unless the page has one. Adding it forces the writing discipline described above, on every page you add it to.

The implementation

export function speakable(cssSelectors: string[]): JsonLdObject | undefined {
  if (cssSelectors.length === 0) return undefined;
  return { "@type": "SpeakableSpecification", cssSelector: cssSelectors };
}

Measuring it

The principle

AEO is the boldest claim most sites now make and almost nobody measures it. A fixed set of seed queries, run monthly against each engine, turns the claim into a trend line.

Fixed is the important word. Changing the query set makes the series meaningless, which is the most common way this measurement gets abandoned: someone adds five queries, the citation rate moves, and nobody can tell whether the site improved or the questions got easier.

The implementation

// scripts/citation-check.ts
const SEED_QUERIES = [
  "how do I write an llms.txt file",
  "should I block GPTBot in robots.txt",
  "difference between programmatic SEO and doorway pages",
  // ... 20 total, fixed at launch
];

const snapshot = {
  runAt: new Date().toISOString(),
  results: await Promise.all(
    SEED_QUERIES.map(async (query) => ({
      query,
      engines: await checkEngines(query),   // which cited the site
    })),
  ),
};
await writeFile(`data/citations/${dateStamp}.json`, JSON.stringify(snapshot, null, 2));

Commit the snapshot. Chart the trend on a public page. A monthly series over a year is evidence; a screenshot of one good answer is an anecdote.