**TL;DR** — Across 30 client sites through May 2026 we audited a structural choice that lives in whether the answer sentence states its cause: whether the passage that answers a "why" query is written as a **causal sentence** that names the mechanism in the same clause as the effect ("Cumulative layout shift happens because images load without a reserved width, so the browser reflows the page when they arrive.") or as a **bare-effect sentence** that states the symptom and leaves the cause to a later paragraph ("Cumulative layout shift is when the page reflows as content loads."), and whether stating the cause changes how often the AI Overview lifts that sentence into the card. Across 7,680 cited-passage events on "why" and "what causes" queries we joined each cited sentence to whether its main clause named a cause. The headline is that the causal sentence is a real and large citation lever on these queries, and it is really an answer-completeness lever wearing a "because" costume. A causal sentence that named the mechanism was cited 2.4× more often than a matched bare-effect sentence describing the same thing without the cause on the same query. The strongest predictor was cause-in-clause — a sentence that put the mechanism in the same sentence as the effect was lifted far more than one that described the effect and left the reason to be inferred. The second was single-mechanism scope — a sentence naming one clear cause was lifted more than one chaining four links of a causal sequence. The third, and the warning, was false causation — bolting a "because" onto a query that asks what something is, not why, was cited no more, and on 5% of pages the composer paired the over-explained sentence with a competitor's clean definition. One change — rewriting bare-effect answer sentences on "why" queries into a causal sentence that names the mechanism in the same clause — lifted cited-passage rate by 23% 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 reason rather than a fact. "Why does my page reflow", "what causes cumulative layout shift", "why is my LCP slow" — each wants the mechanism, the because, and a sentence that describes the symptom without naming the cause hands the composer a true statement that still does not answer the question that was asked. A human reading the surrounding page assembles the cause from the paragraph that follows the description; the composer extracting one sentence cannot, and a sentence that says only "the page reflows as content loads" is, to it, a restatement of the problem rather than its explanation. We had spent weeks on the shape of the answer sentence — its count, its polarity, whether it named a condition — and causality is the natural next structural variable, because a "why" query is one whose answer is a mechanism, and a sentence that describes the effect without the cause answers a different question than the one asked.
The second motivation was a writing habit that separates effect from cause. A page describes the phenomenon first in a clean definitional sentence and then explains the reason in the paragraph below — "Layout shift is when the page jumps as it loads. This happens because…" — because that order reads well to a human, who holds the definition and then receives the cause as the next beat. The composer, hunting for one sentence that answers "why does the page jump", finds the definitional sentence first and lifts it, and a definition is not a cause, so the card answers "what is layout shift" to a user who asked "why". We needed to know whether splitting the cause off into the next sentence cost the citation on "why" queries, because if it did, the fix is nearly free — fold the mechanism into the same sentence as the effect — and it costs only the tidiness of a definition 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 causal queries ("why does X happen", "what causes Y", "why is X slow", "reason for Z") where the answer is a mechanism. Twice daily through May 2026 we captured every AI Overview card, and for cards citing a client page on a causal query we identified the specific lifted sentence and classified its shape: causal (the main clause names the mechanism via "because", "since", "due to", "caused by", "as a result of"), partial (a cause gestured at but not named), or bare-effect (the effect or definition stated with no cause). For each cited sentence we built a matched control: a comparable sentence on a similar causal query whose shape differed but whose underlying explanation was the same, so the comparison was causal-vs-bare-effect rather than good-page-vs-bad-page. The cited cohort was 7,680 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 bare-effect sentence that reads as obviously explained inside a section headed "Why this happens" reads as an unexplained restatement 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 cause is not just the causal pages being better written overall. The 2.4× and 1.6× figures are from those matched comparisons, not raw averages.
The shape of the causal pattern
The flat headline first. On causal queries, causal sentences are cited more. A sentence that named the mechanism was lifted 2.4× more often than a matched bare-effect sentence on the same query. The effect held through the quality match and the citability control: among sentences our rubric scored as equally liftable, the causal ones were lifted far more than the bare-effect ones. The composer behaves as though it prefers a sentence that answers the question the query actually asked — the because, the mechanism — over one that describes the thing the query is asking about and leaves the reason unstated.
The most decision-relevant cut was that this is about answering the "why", not about the word "because" appearing. We tested whether the win came from a causal connective being present or from the sentence actually carrying the mechanism, and the second was the whole story: a sentence with a connective but no real cause ("The page shifts because of how it loads") was cited no better than a bare-effect one, while a sentence naming the actual mechanism ("…because images load without a reserved width") was lifted far more. The causal shape wins when the sentence names the mechanism the effect actually has. State the cause, not a connective that gestures at one.
Driver one: name the mechanism in the same clause as the effect
The single strongest predictor was whether the answer sentence carried the cause in the same clause as the effect. Holding the explanation constant, a sentence that named the mechanism was lifted at 2.4× the rate of one that described the effect and left the cause to the next sentence. The composer extracts a sentence and reads it as the answer to "why does X happen"; a sentence that says "the page reflows because images load without a reserved width" answers the question, while one that says "the page reflows as it loads" describes the symptom and leaves the composer to find the reason elsewhere — which, lifting one sentence cold, it cannot. A human reader reads on to the next sentence for the cause; the composer matching a "why" query rewards the sentence that already carries it.
We ran a structural test on 28 answer sentences across 15 clients, each a bare-effect statement on a causal query that described the phenomenon without its mechanism. We rewrote each to fold the cause into the same sentence as the effect, changing no underlying explanation — only moving the mechanism that lived in the next paragraph up into the answer sentence. Over the 45 days that followed, 20 of the 28 sentences began being lifted on at least one causal query where the bare-effect version had been skipped. The lever was not new content; it was joining the effect and its cause into the single sentence the composer would extract, so the sentence answered the "why" on its own.
Driver two: name one mechanism, not a four-link chain
Holding cause-in-clause constant, the second driver was how many links of the causal chain the sentence carried. A sentence naming one clear mechanism ("LCP is slow because the hero image is unoptimised") was cited more than one chaining the whole sequence ("LCP is slow because the hero image is unoptimised because the build skips compression because the CI step was removed because the config was reverted"). The reading consistent with the data is that the composer lifts a sentence as one self-contained answer, and a single-mechanism sentence is a clean answer to "why is X slow", while a four-link chain is a causal regression the composer cannot resolve into a card — so it skips it for a sentence carrying the one cause that most directly explains the effect.
We ran a structural test on 18 over-chained sentences across 11 clients, each stacking three or more "because"s into one answer. We rewrote each to lead on the single proximate cause and move the deeper links to a following sentence or list, changing no facts. Over the 60 days after the change, 13 of the 18 lead sentences improved their cited-passage rate. The two drivers compound: a bare-effect sentence with no cause is one failure mode and a sentence buried under a four-link causal chain is the other — the sentences that won named exactly one mechanism, the one nearest the effect, and left the deeper chain to the prose around them.
Driver three: false causation, and the "because" the query did not ask for
The third driver was the warning. A cause helps only when the query asks why, and bolting a mechanism onto a query that asks what something is backfires. A sentence like "Lazy loading is a technique, because it defers off-screen images" — a cause wrapped around a query that wanted a definition — was cited no more often than the clean definition ("Lazy loading defers off-screen images until the user scrolls near them"), and on 5% of audited pages the composer paired the over-explained 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 matches the answer shape to the question: a "why" query wants the mechanism, and a "what is" query wants the definition, and a because forced onto a definitional query reads as noise around an answer that was meant to be flat. A query that asks why wants the cause; a query that asks what wants the thing named.
We confirmed this on 15 sentences across 9 clients where an earlier optimisation pass had added causes to answers for definitional queries. We rewrote each back into a clean definition for the "what is" query while keeping the causal sentence on the adjacent "why" query, matching the answer 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: name the mechanism when the query asks why, and state the definition flat when it asks what — a needless because reads as a qualifier the composer will pass over for a cleaner sentence.
What changed in our content checklist
Three changes. We added a cause pass for causal queries: before publishing, we read each section's lead answer sentence and check that, where the query asks why, the mechanism sits in the same sentence as the effect — because the composer lifts a sentence whole and reads a causal sentence as the answer to "why does X happen", while a definition split from its cause answers a different question. We added a single-mechanism check to the same pass: the lead sentence names one proximate cause, with the deeper chain moved to a following sentence, because the composer cannot resolve a four-link regression into a card. And we added a false-causation guard: we strip causes off answers to definitional queries, so a needless because never clutters a sentence whose query wanted a flat definition.
We dropped one habit. For years our pages had led with a clean definitional sentence and pushed the cause into the paragraph below, on the belief that defining the thing before explaining it read best and that the reader would reach the cause in the next beat — "Layout shift is when the page jumps. This happens because…" felt better ordered than folding the cause into the first sentence. The audit removes that default for the answer sentence on "why" queries: the one sentence the composer would lift has to carry the mechanism, and a definition that stands alone spends the citation to read tidy. So bare-effect answer sentences left our playbook for causal queries — we now write the lead answer sentence to name the cause in the same clause as the effect, accepting that the cited sentence reads heavier than a stylist would choose because it is built to answer the "why" on its own.
- 01Name the cause in the same clause as the effect. A causal sentence was cited 2.4× more than a bare-effect one describing the same thing on the same "why" query — the composer reads a sentence with the mechanism as the answer and one without it as a restatement of the problem.
- 02State the mechanism, not a connective. A "because" with no real cause was lifted no more than a bare-effect sentence — the win comes from naming the actual mechanism, not from the word.
- 03Name one mechanism, not a chain. A single proximate cause was cited more than a four-link causal regression the composer cannot resolve into a card.
- 04Do not false-cause. Bolting a because onto a definitional query was cited no more, and on 5% of pages the composer shared the citation with a competitor that answered with a clean definition.
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 mechanism to state and the causal shape is irrelevant, so the lever is for queries that ask why. For navigational and brand queries there is no answer sentence whose shape matters. For narrative and persuasive passages — case studies, opinion, story-driven content — naming a cause is a rhetorical and structuring choice, not a citation lever, and the cause pass is for the answer sentences on causal queries only. For some languages the effect may differ — in our parallel Chinese-language audit (文心一言, 元宝, 通义) the cause-in-clause win was present but the placement was less sensitive, since Chinese commonly leads with the cause in a «因为……所以……» frame the composer read reliably wherever it sat. The 5% shared-citation figure is small and noisy; we are confident a needless because 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 causal answer sentence — the mechanism named in the same clause as the effect, one proximate cause, used only where the query asks why — far more readily than a bare-effect sentence that describes the thing but leaves the reason to the next paragraph, the unit is the individual answer sentence rather than the page, and the cheapest citation win on a "why" query is to fold the cause into the sentence that states the effect.