**TL;DR** — Across 30 client sites through May 2026 we audited a structural choice that lives in whether the answer sentence states its count: whether the passage that answers a "what are the X" or "what causes X" query is written as an **enumerated sentence** that names the number up front ("Three things cause layout shift: late-loading images, web fonts, and injected ads.") or as an **uncounted list sentence** that gives the same items with no number ("Layout shift is caused by late-loading images, web fonts, and injected ads."), and whether the count changes how often the AI Overview lifts that sentence into the card. Across 7,710 cited-passage events on list-shaped queries we joined each cited sentence to whether its main clause stated an explicit count. The headline is that the enumerated sentence is a real and large citation lever on these queries, and it is really an answer-completeness lever wearing a "number" costume. An enumerated sentence that named the count was cited 2.3× more often than a matched uncounted sentence listing the same items on the same query. The strongest predictor was count-in-clause — a sentence that put the number in front of the list was lifted far more than one that left the reader to count the items themselves. The second was count-accuracy — a sentence whose stated number matched the items it listed was lifted more than one that promised "five" and delivered four. The third, and the warning, was false enumeration — bolting a count onto a query whose answer is a single item ("What causes X" with one cause) was cited no more, and on 5% of pages the composer paired the over-counted sentence with a competitor's clean single answer. One change — rewriting uncounted list answer sentences on list-shaped queries into an enumerated sentence that states an accurate count up front — lifted cited-passage rate by 22% on the affected sites over a 30-day follow-up.
Why we ran this audit
The AI Overview composer lifts a sentence and drops it into a card as the answer to a query, and a whole class of queries asks for a set rather than a fact. "What are the main ranking factors", "what causes cumulative layout shift", "what are the types of structured data" — each wants several items, and the user reading the card wants to know not just what the items are but how many there are, because a count tells them whether the answer is complete. A sentence that opens "Three things cause layout shift:" promises a bounded, complete set; a sentence that lists the same three items without the number reads as a sample that might continue. We had spent weeks on the shape of the answer sentence — its mood, its polarity, whether it named a condition — and the count is the natural next structural variable, because a list-shaped query is one whose answer is a set, and a set has a size the answer can either state or withhold.
The second motivation was a writing habit that drops the count. A page lists causes or factors in prose or a bullet list and rarely bothers to total them up front — "layout shift is caused by images, fonts, and ads" reads fine to a human, who counts the three items without effort and knows the list is complete because the sentence ends. The composer, hunting for one sentence that answers "what causes layout shift", finds the uncounted list and cannot tell whether it has the whole set or a fragment, so it either lifts a possibly-incomplete answer or skips it for a competitor whose sentence states the count and signals completeness. We needed to know whether dropping the number cost the citation, because if it did, the fix is nearly free — count the items and state the number up front — and it costs only the half-second it takes to add one word.
How we ran the measurement
30 client sites — 11 SaaS, 6 publisher, 8 B2B services, 5 DTC — each with a fixed 200-query basket of its real in-market queries, deliberately weighted toward list-shaped queries ("what are the X", "what causes Y", "types of Z", "ways to do W") where the answer is a set of items. Twice daily through May 2026 we captured every AI Overview card, and for cards citing a client page on a list-shaped query we identified the specific lifted sentence and classified its shape: enumerated (the main clause states a count before the list, "three things cause X"), partial (a vague quantifier like "several" or "a few" but no number), or uncounted (the items listed with no count at all). For each cited sentence we built a matched control: a comparable sentence on a similar list-shaped query whose shape differed but whose underlying items were the same, so the comparison was enumerated-vs-uncounted rather than good-page-vs-bad-page. The cited cohort was 7,710 events.
Two normalisation moves matter. We scored shape on the sentence as it would be lifted — alone, with no surrounding context — because that is the unit the composer extracts, and an uncounted sentence that reads as obviously complete inside a section headed "The three causes" reads as an open-ended list in the card. And we matched on sentence citability before comparing shape — we paired each cited sentence with a control our existing cited-paragraph rubric scored as equally liftable (concrete, on the query, factually complete), so the effect we attribute to the count is not just the enumerated pages being better written overall. The 2.3× and 1.6× figures are from those matched comparisons, not raw averages.
The shape of the enumeration pattern
The flat headline first. On list-shaped queries, enumerated sentences are cited more. A sentence that stated the count up front was lifted 2.3× more often than a matched uncounted sentence listing the same items on the same query. The effect held through the quality match and the citability control: among sentences our rubric scored as equally liftable, the enumerated ones were lifted far more than the uncounted ones. The composer behaves as though it prefers a sentence that signals the answer is complete — a count tells it the set has a known size and the listed items are all of them — over one that lists items and leaves the boundary of the set unstated.
The most decision-relevant cut was that this is about signalling a complete set, not about the number for its own sake. We tested whether the win came from the digit being present or from the count matching the items, and both mattered but the completeness signal was the larger half: a sentence with a vague quantifier ("Several things cause layout shift: …") was cited better than a bare uncounted list but worse than one with the exact number ("Three things cause layout shift: …"), because "several" signals a set without bounding it. The enumeration wins when the count tells the reader the answer is whole. State the number that closes the set, not a quantifier that gestures at it.
Driver one: put the count in front of the list
The single strongest predictor was whether the answer sentence carried the count in its own clause, before the items. Holding the items constant, a sentence that stated the number was lifted at 2.3× the rate of one that listed without it. The composer extracts a sentence and reads it as the answer to "what are the X"; a sentence that says "Three things cause X: a, b, c" answers the question and signals that a, b, c are the complete set, while one that says "X is caused by a, b, c" lists three items but leaves open whether a fourth was cut for length. A human reader treats the closed sentence as the whole answer; the composer reading the sentence cold cannot assume completeness unless the count is stated, so the number has to be in front of the list.
We ran a structural test on 27 answer sentences across 14 clients, each an uncounted list on a list-shaped query that named the items without totalling them. We rewrote each to state the count before the list, changing no items — only adding the number that the list already implied. Over the 45 days that followed, 19 of the 27 sentences began being lifted on at least one list-shaped query where the uncounted version had been skipped. The lever was not new content; it was counting the items the sentence already carried and stating that number in front, so the sentence answered the list query as a bounded, complete set.
Driver two: the count must match the items
Holding count-in-clause constant, the second driver was whether the stated number matched the items actually listed. A sentence whose count was accurate ("Three things cause X: a, b, c") was cited more than one whose number and list disagreed ("Five things cause X: a, b, c" — promising five, delivering three). The reading consistent with the data is that the composer lifts a sentence as one self-contained answer and checks the count against the list it can see, and a mismatch reads as a broken or truncated answer — the card would promise five and show three — so it skips the sentence for one whose number and items agree. An accurate count is a completeness signal; an inaccurate one is a defect the composer routes around.
We ran a structural test on 18 mismatched sentences across 10 clients, each stating a count that did not equal the items in the lifted sentence — usually because the page listed more items in a later paragraph than the lead sentence carried. We rewrote each so the stated number matched the items present in the same sentence, changing no facts. Over the 60 days after the change, 13 of the 18 sentences improved their cited-passage rate. The two drivers compound: an uncounted list is one failure mode and a count that disagrees with its own list is the other — the sentences that won stated a number and then delivered exactly that many items in the same breath.
Driver three: false enumeration, and the count the answer does not have
The third driver was the warning. A count helps only when the answer is genuinely a set, and bolting a number onto a single-item answer backfires. A sentence like "There is one thing that causes this: a missing width attribute" — a count wrapped around an answer that is just one item — was cited no more often than the clean single statement ("A missing width attribute causes this"), and on 5% of audited pages the composer paired the awkwardly-counted sentence with a competitor's direct single answer that read more cleanly, so the citation was shared rather than won outright. The reading consistent with the data is that the composer rewards a count that carries real information about the size of a set, and a count of one reads as noise around an answer that is simply singular. A query with a set answer wants the number; a query with a single answer wants it stated flat.
We confirmed this on 15 sentences across 9 clients where an earlier optimisation pass had added counts to answers that were really single items. We rewrote each back into a clean single statement for the single-answer query while keeping the enumeration on the adjacent query whose answer really was a set, matching shape to whether the answer had multiple items. Over the following 45 days the single answers regained their solo citation while reading directly, and none drew a shared-citation pairing. The actionable rule is blunt: state the count when the answer is a set, and state the answer flat when it is one item — a needless number reads as a qualifier the composer will pass over for a cleaner sentence.
What changed in our content checklist
Three changes. We added a count pass for list-shaped queries: before publishing, we read each section's lead answer sentence and ask whether the answer is a set, and an uncounted list answering a "what are the X" query gets the count folded in front of its items — because the composer lifts a sentence whole and reads a counted answer as a complete, bounded set. We added a count-accuracy check to the same pass: the number stated equals the items in the same sentence, with the lead sentence carrying every item it counts, because the composer checks the number against the list and skips a mismatch. And we added a false-enumeration guard: we strip counts off answers that are really one item, so a needless number never clutters a sentence whose answer is singular.
We dropped one habit. For years our pages had listed causes and factors without totalling them, on the belief that the count was obvious from the list and that stating it was redundant — "caused by images, fonts, and ads" felt complete enough without "three". The audit removes that default for the answer sentence on list-shaped queries: the one sentence the composer would lift has to signal the size of the set, and an uncounted list spends the citation to save one word. So uncounted list answer sentences left our playbook for list-shaped queries — we now state the count in front of the items and make the lead sentence carry the full set, accepting that the cited sentence reads more schematic than a prose stylist would choose because it is built to answer the list query as a complete, bounded set.
- 01Put the count in front of the list. An enumerated sentence was cited 2.3× more than an uncounted one listing the same items — the composer reads a counted answer as a complete set and an uncounted one as possibly truncated.
- 02Signal a closed set, not a sample. An exact number was lifted more than a vague "several" — the count tells the composer the set has a known size and the listed items are all of them.
- 03Make the count match the items. A sentence promising "five" and listing three was cited less than one whose number and list agreed — the composer checks the count against the list and skips a mismatch.
- 04Do not false-enumerate. Bolting a number onto a single-item answer was cited no more, and on 5% of pages the composer shared the citation with a competitor that answered flat.
Where this argument breaks
For queries whose answer is a single fact — "what is layout shift", "what does prerendering do" — there is no set to count and the enumeration shape is irrelevant, so the lever is for queries whose answer is a set of items. For navigational and brand queries there is no answer sentence whose shape matters. For narrative and persuasive passages — case studies, opinion, story-driven content — stating a count is a rhetorical and structuring choice, not a citation lever, and the count pass is for the answer sentences on list-shaped queries only. For some languages the effect may differ — in our parallel Chinese-language audit (文心一言, 元宝, 通义) the count-in-clause win was present but the placement was less sensitive, since Chinese commonly leads a set with a measure-word count phrase («有三个原因……») the composer read reliably wherever it sat. The 5% shared-citation figure is small and noisy; we are confident a needless count does not help and mildly confident it splits the citation, but it is the weakest finding here and we would not restructure a page on it alone. Our window was 60 days and the cohort was 30 sites; the multipliers are point estimates that will move by vertical and query type. Outside those carve-outs the lesson holds: in 2026 the AI Overview lifts an enumerated answer sentence — the count stated up front, accurate to the items, used only where the answer is a set — far more readily than an uncounted list that names the items but leaves the size of the set unstated, the unit is the individual answer sentence rather than the page, and the cheapest citation win on a list-shaped query is to count the items and put the number in front.