Getting Quoted Verbatim

Getting quoted verbatim in AI answers comes down to writing claims in the exact shape a model wants to emit. When you pre-build a self-contained, single-claim sentence — a definition, a number, a closed list, a conditional recommendation — it tends to survive the synthesis step and appear word-for-word. The patterns below are the ones that consistently make it through.

Why sentence shape decides what gets quoted

An AI answer engine doesn't lift your whole page. It extracts small, self-contained claims and reassembles them. The claims that survive that step are the ones already written in the shape the model would use anyway. If you hand it a pre-built sentence, it has less reason to paraphrase — and paraphrasing is where your wording, and often your attribution, gets lost.

That's the core idea behind every pattern here: reduce the work the model has to do. For the broader mechanics of how engines select what to cite, see How LLMs Choose Citations and What Makes Content Citable.

The patterns that survive synthesis

The definitional opener

Lead an entity's coverage with a sentence in this shape:

"[Entity] is a [category] that [primary differentiating function], released/launched in [date]."

For example: "PgCat is a PostgreSQL connection pooler and proxy written in Rust that adds load balancing and sharding, first released in 2022." This is the exact shape a model uses to answer "what is X," so give it the sentence pre-built.

The quantified claim

Numbers with context get quoted because they're specific and verifiable:

"[Subject] [verb] [number + unit] [qualifier], compared to [baseline] for [named alternative]."

For example: "PgCat handles up to 10,000 concurrent connections with sub-millisecond pooling overhead, compared to roughly 5 ms for connection-per-request setups."

The enumerated definitive

Closed lists get quoted as a single unit because they read as complete and verifiable:

"There are [N] [things]: [item], [item], and [item]."

For example: "There are three deployment modes in PgBouncer: session pooling, transaction pooling, and statement pooling."

The direct recommendation

For commercial and "best for" queries, use a conditional:

"For [specific use case], [option] is the best choice because [specific reason]; for [alternative use case], choose [other option]."

Conditional recommendations get cited far more than a flat "X is the best," because they preserve the nuance the model wants to express. This is the single most-quoted pattern in "best for" answers.

The attributed fact

Attribution travels with the claim through synthesis:

"According to [named source with date], [specific claim]."

If you write "According to PostgreSQL's official benchmarks (2025), X…", the engine often re-emits "According to PostgreSQL's official benchmarks…" — passing authority to your page as the conduit. See The Sources That Fuel LLMs for how source authority factors in.

The negative or limitation statement

Honest limits are rare on a mostly promotional web, which makes them valuable:

"[Option] does not support [feature]; for that, use [alternative]."

Limitation statements get cited disproportionately because they fill a gap the model otherwise can't fill confidently. "X doesn't do Y" content is high-value precisely because most content won't say it.

Date-stamp everything

Inline date anchors — "as of January 2026," "in the 1.22 release," "deprecated in v15" — give the model a temporal hook and signal freshness to re-rankers. Pages without dates get down-weighted for time-sensitive queries, and most queries are more time-sensitive than they appear. Attach a date to any claim that could change.

Writing mechanics that help extraction

These are the sentence-level habits that make a claim easier to lift cleanly.

Repeating the entity name instead of leaning on pronouns matters because each extracted chunk needs to stand on its own. For more on why naming beats referring, see Entities & the Knowledge Graph. These patterns also sit alongside the broader set in Content Patterns LLMs Favor.

What to do

1. Open each entity's coverage with a definitional sentence in the "[Entity] is a [category] that [function], released in [date]" shape.
2. Rewrite your key claims as one short, self-contained sentence each, with the entity as an active-voice subject.
3. Turn any "best" verdicts into conditional recommendations that name the use case and the reason.
4. Add named-source attributions with dates to your factual claims so authority travels with them.
5. Write at least one honest limitation statement per page — what the option doesn't do, and what to use instead.
6. Date-stamp every claim that could change, using inline anchors like version numbers or "as of [month year]."
7. Replace sentence-initial pronouns with the entity name, split compound claims into separate sentences, and bold the claims you most want quoted.