How to Write for AI Search: Quotable, Extractable Content
AI engines don't rank your page — they raid it. When ChatGPT or Perplexity builds an answer, it pulls a passage here, a definition there, maybe a row from a table, and stitches them into something new. Your page either survives that dismemberment or it doesn't. Most content doesn't, because it was written to be read top to bottom by a patient human, and no such reader is coming.
Writing for extraction is a learnable craft, and it's less alien than it sounds — most of it is just ruthless clarity. Here's how I approach it.
What "Extractable" Actually Means
A retrieval system splits your page into chunks, embeds them, and pulls the chunks that best match a question. The model then quotes or paraphrases from those chunks — usually a paragraph or two, rarely the whole page. This is the mechanical shift behind the whole AEO vs SEO conversation: the unit of competition dropped from the page to the passage.
That has a blunt implication. Every meaningful passage on your page is auditioning independently. A brilliant explanation that only makes sense after reading the three paragraphs above it will lose to a mediocre explanation that stands alone, because the retrieval step never sees your three paragraphs of setup. Context you assumed the reader carried with them simply isn't there.
So the test I apply to any paragraph I want engines to use: if this landed in front of a model with zero surrounding context, would it still make sense, name its subject, and answer a question? If not, it's furniture, not a candidate.
Lead With the Definition, Not the Wind-Up
The single highest-payoff habit: put the answer in the first sentence of the section, then elaborate. Journalists call it the inverted pyramid. Most marketing content does the exact opposite — it builds suspense toward a conclusion, like a dinner speech.
Compare two openings for a section on, say, cohort retention:
Wind-up version: "Retention has become a hot topic among SaaS operators, and for good reason. There are many ways to think about it..."
Definition-first version: "Cohort retention measures what percentage of users who signed up in a given period are still active after a set time — for example, how many January signups remain active in April."
The second version is quotable as-is. It defines the term, names the concept, and includes a concrete illustration in a single sentence pair. The first version could sit atop an article about literally anything and says nothing a model can use. When a retrieval system is choosing between your wind-up and a competitor's clean definition, you lose that passage every time, even if your full article is deeper.
This doesn't mean every paragraph reads like a dictionary. It means the first sentence of any section you care about does the work, and the color comes after. Humans skimming your page benefit from exactly the same structure, which is a recurring theme here.
Write Self-Contained Blocks
Beyond the first sentence, each section should be a sealed unit: subject named explicitly, claim made, support given, no load-bearing references to "as we saw above."
Practical habits that get you there:
- Restate the subject instead of leaning on pronouns. "The tool" or "this approach" is ambiguous inside an isolated chunk. Use the actual noun once per paragraph. It feels slightly repetitive when you write it; it reads fine and extracts far better.
- One idea per section. If a section answers two questions, split it. Chunks that mix topics match neither question well in retrieval.
- Keep the claim and its evidence adjacent. If the supporting example lives four paragraphs from the claim, an extracted chunk gets one without the other — an unsupported assertion, or orphaned evidence.
- Front-load specifics. Numbers, names, and concrete conditions early in the block. Vague generality is the least extractable substance on the internet.
Here's a deliberately hypothetical illustration. Imagine a project management tool — call it Taskfell — with a genuinely excellent guide to sprint planning. The guide opens with 400 words on the history of agile, refers to its own earlier sections constantly ("using the estimation method from chapter two..."), and buries its best insight in the final paragraph as a payoff. A competitor publishes a shallower piece where every section opens with a direct answer and stands alone. When users ask AI engines about sprint planning, the shallow competitor gets quoted and Taskfell doesn't — not because the content is better, but because it survives chunking. That's the unfair-feeling reality of extraction, and it's very common.
Use Tables and Lists Where the Content Is Actually Tabular
Structured formats are extraction gold — when they're honest. A comparison of plans, a step sequence, a set of criteria: these are naturally tabular, and putting them in a table or numbered list makes them trivially liftable. Models reproduce well-formed tables in answers remarkably often, sometimes near-verbatim, with attribution.
The failure mode is forcing structure onto prose that isn't structured. A "listicle" where each bullet is a three-sentence paragraph wearing a bullet costume helps nobody, and I'd argue it reads worse to humans too. My rule: if the information has consistent fields across items — name, price, limit, use case — it's a table. If it's a sequence of actions, it's a numbered list. If it's an argument, it's prose, and dressing it up as a list just chops your reasoning into disconnected fragments.
One more practical note: give tables real headers and give lists a lead-in sentence that names what the list contains ("The four fields every review request should include:"). That lead-in travels with the list when it's extracted, which is what keeps it comprehensible out of context.
Ask the Question in the H2, Then Answer It
Headings do double duty in AI search. They're chunk boundaries — retrieval systems often split on them — and they're strong relevance signals for matching. A heading phrased the way a user would ask ("How long does DNS propagation take?") aligns your chunk with the query far better than a clever one ("The waiting game").
I'd hedge this slightly: not every heading should be a question, or the page reads like an FAQ that swallowed an article. My working ratio is that the sections carrying your key answers get question-shaped or query-shaped headings, and structural sections (intros, transitions) can be plain. What matters most is the contract: whatever the H2 promises, the first sentence under it delivers. A question-shaped heading followed by three paragraphs of throat-clearing is worse than no question at all, because it's a matched chunk with no payoff.
Clever headings, puns, metaphors — I like them in essays. On a page competing for AI answers, they're camouflage. Save the wit for the sentences.
What Not to Do — Burying, Padding, and Hedging Everything
The mistakes are mostly the mirror image of the advice above, but a few deserve explicit warnings because they're so widespread:
- Burying the answer. The number-one killer. If a reader must scroll past your brand story, your "why this matters," and a stock photo to reach the actual answer, so must the retrieval system — and unlike the reader, it will just pick someone else's page.
- Intro bloat. Long preambles restating the question dilute the very chunks that should carry your answer. Two sentences of framing, maximum, then work.
- Hedging every sentence. Honest uncertainty is good — I use it plenty. But content where every claim is wrapped in "it depends" and "results may vary" gives a model nothing definite to quote. Commit to your answer for the common case, then note the exceptions once, specifically.
- Splitting one answer across many thin pages. Chunking already fragments you; don't help it. A single thorough page beats five stubs that each hold a fifth of the answer.
- Writing for extraction only. If your page becomes a soulless answer vending machine, humans bounce, nobody links to it or discusses it, and the third-party signals that drive much of AI visibility never accrue. Extractable structure and human voice aren't opposites — this article has opinions and rhythm precisely because that's what makes content worth citing in the first place.
How to Check Whether It's Working
Two feedback loops, one crude and one systematic. The crude one: paste a section into an AI engine and ask the question it's meant to answer, with the page as context — see whether the model's summary matches what you intended to say. It's a surprisingly effective smoke test for self-containedness. The systematic one: track whether your pages actually get cited and quoted in live answers across engines over time, which is what we measure in our scoring methodology. Structure is a hypothesis; citations are the evidence.
None of this is exotic. Lead with answers, seal your sections, structure what's truly structured, promise in the heading and pay off in the first sentence. It's mostly what good technical writing always was — the machines just made the stakes visible.