**TL;DR** — Across 30 client sites through June 2026 we audited a structural choice that lives in whether the answer sentence states its sequence: whether the passage that answers a "how do I" or "how does X work" query is written as a **process-structured sentence** that names the steps in order ("First audit the current layout, then optimise the hero image, finally validate the CLS score.") or as a **single declarative summary** that states the endpoint without the sequence ("Optimising the hero image fixes layout shift."), and whether stating the process changes how often the AI Overview lifts that sentence into the card. Across 7,750 cited-passage events on process-shaped queries we joined each cited sentence to whether its main clause stated an explicit sequence. The headline is that the process-structured sentence is a real citation lever on these queries, and it is really an answer-completeness lever wearing a "first, then" costume. A process-structured sentence that named the sequence was cited 2.0× more often than a matched declarative summary stating the same endpoint on the same process query. The strongest predictor was sequence-in-clause — a sentence that put the steps in the same sentence as the outcome was lifted far more than one that described the result and left the how to be inferred. The second was step-count accuracy — a sentence whose stated step count matched the steps it named was lifted more than one promising "three steps" and delivering two. The third, and the warning, was over-sequencing — bolting a "first, then" onto a query whose answer is a single fact ("What is CLS" answered with "First you measure it, then it tells you…") was cited no more, and on 6% of pages the composer paired the over-sequenced sentence with a competitor's clean definition. One change — rewriting declarative summary answer sentences on process queries into a process-structured sentence that names the steps in order — lifted cited-passage rate by 19% 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 method rather than a fact. "How do I fix layout shift", "how does RAG work", "what are the steps to deploy a schema" — each wants the sequence, the first-then-finally, and a sentence that states only the result ("optimise the hero image") or jumps straight to the definition ("RAG grounds models in documents") hands the composer a true statement that still does not answer the question that was asked. A human reading the surrounding page assembles the process from the paragraph that follows the summary; the composer extracting one sentence cannot, and a sentence that says only "the fix is image optimisation" is, to it, a restatement of the solution rather than the path to it. We had spent weeks on the shape of the answer sentence — its polarity, its condition, whether it named a cause — and process structure is the natural next structural variable, because a "how" query is one whose answer is a sequence, and a sentence that describes the endpoint without the steps answers a different question than the one asked.
The second motivation was a writing habit that abstracts the process. A page opens with a clean declarative summary and pushes the step-by-step into a numbered list or a later paragraph — "To fix CLS, optimise your images" reads as a tight lead-in, and the detailed steps follow in bullet points. The composer, hunting for one sentence that answers "how do I fix CLS", finds the declarative opener and lifts it, and a result-only statement is not a method, so the card answers "what fixes CLS" to a user who asked "how do I fix it". We needed to know whether abstracting the steps into a summary cost the citation on process queries, because if it did, the fix is nearly free — fold the sequence into the lead sentence — and it costs only the tidiness of a summary that stands alone.
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 process-shaped queries ("how do I X", "how does X work", "what are the steps to X", "way to do X") where the answer is a sequence of actions. Twice daily through June 2026 we captured every AI Overview card, and for cards citing a client page on a process query we identified the specific lifted sentence and classified its shape: process-structured (the main clause states the steps via "first", "then", "next", "finally", "step 1"), partial (a sequence gestured at with "start by" or "begin with" but not completed), or declarative summary (the endpoint stated with no sequence). For each cited sentence we built a matched control: a comparable sentence on a similar process query whose shape differed but whose underlying process was the same, so the comparison was process-vs-summary rather than good-page-vs-bad-page. The cited cohort was 7,750 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 a declarative summary that reads as obviously complete inside a section headed "How to fix this" reads as a result-only statement 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 sequence is not just the process pages being better written overall. The 2.0× and 1.6× figures are from those matched comparisons, not raw averages.
The shape of the process-structured pattern
The flat headline first. On process queries, process-structured sentences are cited more. A sentence that stated the sequence was lifted 2.0× more often than a matched declarative summary on the same query. The effect held through the quality match and the citability control: among sentences our rubric scored as equally liftable, the sequence-naming ones were lifted far more than the result-only ones. The composer behaves as though it prefers a sentence that answers the question the query actually asked — the steps, the how — over one that describes the outcome and leaves the method unstated.
The most decision-relevant cut was that this is about answering the "how", not about the word "first" appearing. We tested whether the win came from a process marker being present or from the sentence actually carrying the steps, and the second was the whole story: a sentence with a decorative "first" that led nowhere ("First, understand that optimising images is important") was cited no better than a bare declarative summary, while a sentence that named the actual steps ("First, set image dimensions, then compress, finally serve in modern format") was lifted far more. The process-structured shape wins when the sentence names the steps the method actually has. State the sequence, not a process-looking opener.
Driver one: put the steps in the same sentence as the result
The single strongest predictor was whether the answer sentence carried the sequence in its main clause. Holding the process constant, a sentence that stated the steps was lifted at 2.0× the rate of one that described only the endpoint. The composer extracts a sentence and reads it as the answer to "how do I fix X"; a sentence that says "First set image dimensions, then compress, finally validate" answers the question, while one that says "optimising images fixes CLS" describes the solution and leaves the composer to find the method elsewhere — which, lifting one sentence cold, it cannot. A human reader reads on to the next paragraph for the steps; the composer matching a "how" query rewards the sentence that already carries them.
We ran a structural test on 26 answer sentences across 14 clients, each a declarative summary on a process query that named the result without the steps. We rewrote each to fold the sequence into the same sentence as the endpoint, changing no underlying process — only moving the steps that lived in the bullet list up into the lead sentence. Over the 45 days that followed, 19 of the 26 sentences began being lifted on at least one process query where the summary-only version had been skipped. The lever was not new content; it was joining the endpoint and its steps into the single sentence the composer would extract, so the sentence answered the "how" on its own.
Driver two: the step count must match the steps
Holding sequence-in-clause constant, the second driver was whether the stated step count matched the steps actually named. A sentence whose count was accurate ("Three steps fix CLS: set dimensions, compress, validate") was cited more than one whose number and steps disagreed ("Four steps fix CLS: set dimensions, compress, validate" — promising four, 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 steps it can see, and a mismatch reads as a broken or incomplete answer — the card would promise four and show three — so it skips the sentence for one whose number and steps agree. An accurate count is a completeness signal; an inaccurate one is a defect the composer routes around.
We ran a structural test on 15 mismatched sentences across 9 clients, each stating a step count that did not equal the steps in the lifted sentence — usually because the page listed more steps in a later paragraph than the lead sentence carried. We rewrote each so the stated number matched the steps present in the same sentence, changing no facts. Over the 60 days after the change, 11 of the 15 sentences improved their cited-passage rate. The two drivers compound: a result-only summary is one failure mode and a step count that disagrees with its own steps is the other — the sentences that won stated a number and then delivered exactly that many steps in the same breath.
Driver three: over-sequencing, and the process the query did not ask for
The third driver was the warning. A sequence helps only when the query asks how, and bolting a "first, then" onto a query whose answer is a definition backfires. A sentence like "First you measure CLS, then it tells you about layout shift" — a process wrapped around a "what is CLS" query — was cited no more often than the clean definition ("CLS measures layout shift as the page loads"), and on 6% of audited pages the composer paired the over-sequenced sentence with a competitor's direct definition 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 sequence that carries real information about the method, and a fake process on a definitional answer reads as noise around a statement that was meant to be flat. A query with a "how" answer wants the steps; a query with a "what" answer wants the thing named.
We confirmed this on 13 sentences across 8 clients where an earlier optimisation pass had added sequences to answers for definitional queries. We rewrote each back into a clean definition for the "what is" query while keeping the process-structured sentence on the adjacent "how do I" query, matching shape to what each query asked. Over the following 45 days the definitions regained their solo citation while reading directly, and none drew a shared-citation pairing. The actionable rule is blunt: state the sequence when the query asks how, and state the definition flat when it asks what — a needless process reads as a qualifier the composer will pass over for a cleaner sentence.
What changed in our content checklist
Three changes. We added a sequence pass for process queries: before publishing, we read each section's lead answer sentence and check that, where the query asks how, the steps sit in the same sentence as the endpoint — because the composer lifts a sentence whole and reads a process-structured sentence as the answer to "how do I X", while a summary split from its steps answers a different question. We added a step-count check to the same pass: the number stated equals the steps in the same sentence, with the lead sentence carrying every step it counts, because the composer checks the count against the steps and skips a mismatch. And we added an over-sequencing guard: we strip sequences off answers to definitional queries, so a needless "first, then" never clutters a sentence whose answer is a concept, not a method.
We dropped one habit. For years our pages had led with a clean declarative summary and pushed the steps into a numbered list below, on the belief that the summary read better and that the step-by-step in the lead sentence felt clumsy. The audit removes that default for the answer sentence on process queries: the one sentence the composer would lift has to carry the sequence, and a result-only summary spends the citation to read tidy. So declarative summary answer sentences left our playbook for process queries — we now write the lead answer sentence to name the steps in order, accepting that the cited sentence reads more procedural than a prose stylist would choose because it is built to answer the "how" on its own.
- 01State the sequence in the answer. A process-structured sentence was cited 2.0× more than a declarative summary on the same "how" query — the composer reads a sequence-naming sentence as the answer and a result-only one as a statement of the endpoint.
- 02Name the steps, not just a process marker. A decorative "first" with no real steps was lifted no more than a bare summary — the win comes from the sentence actually carrying the method.
- 03Match the step count to the steps. A sentence promising "three steps" and listing two was cited less than one whose number and steps agreed — the composer checks the count and skips a mismatch.
- 04Do not over-sequence. Bolting a "first, then" onto a definitional query was cited no more, and on 6% of pages the composer shared the citation with a competitor that answered flat.
Where this argument breaks
For queries whose answer is a definition or a fact — "what is layout shift", "what does prerendering do" — there is no sequence to state and the process-structured shape is irrelevant, so the lever is for queries whose answer is a method. 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 sequence is a rhetorical and structuring choice, not a citation lever, and the sequence pass is for the answer sentences on process queries only. For some languages the effect may differ — in our parallel Chinese-language audit (文心一言, 元宝, 通义) the sequence-in-clause win was present but the placement was less sensitive, since Chinese commonly leads a process with a «首先……然后……最后……» frame the composer read reliably wherever it sat. The 6% shared-citation figure is small and noisy; we are confident an over-sequenced sentence 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 a process-structured answer sentence — the steps stated in the sequence, the count accurate to the steps, used only where the query asks how — more readily than a declarative summary that states the endpoint but leaves the method unstated, the unit is the individual answer sentence rather than the page, and the cheapest citation win on a "how do I" query is to fold the sequence into the sentence that states the result.