**TL;DR** — Across 31 client sites in late April and the first three weeks of May 2026 we audited a question that prose-focused content teams keep getting wrong: when Google's AI Overview renders its answer as a list or a table rather than a paragraph, where does that structure come from? Across 9,860 captured answer cards, 38% rendered in a structured format (a list or a table) rather than as prose; inside that structured population, 64% were lists and 36% were tables. The finding that reset our editorial briefs: when the card rendered structured, 58% of the time the composer lifted the structure predominantly from a single source's on-page `<ol>`, `<ul>` or `<table>` element rather than synthesising the structure across sources. The strongest predictor of single-source list lift was structural congruence — lists whose item count matched the query's implied answer shape (4–7 items for "steps to" and "ways to" queries) were lifted at 3.4× the rate of lists with 12+ items carrying the same content. The strongest predictor of table lift was column semantics — tables with one entity column plus two or three attribute columns were lifted at 2.6× the rate of wide tables with six or more columns. Two structural changes — converting prose "steps" and "comparison" content into well-formed HTML lists and tables with query-matched granularity, and capping list length at the answer's natural item count — lifted structured-card citation by 44% on the affected sites over a 30-day follow-up window.
Why we ran this audit
For most of the past year our editorial briefs have been prose-first. We optimised the answer-bearing sentence, the lead paragraph, the heading hierarchy — and we treated lists and tables as formatting decoration applied after the prose was written, if at all. The behaviour we kept seeing on client answer cards contradicted that priority. On a large and growing share of queries the AI Overview answer was not a paragraph at all — it was a numbered list of steps, a bulleted list of options, or a small comparison table — and on those cards the cited source was frequently a page whose prose we considered weaker than a competitor's, but whose list or table happened to match the shape of the answer the composer wanted to render. We had been losing structured cards to structurally-better but editorially-thinner pages, and we had no audit data on how often that was happening or what made the difference.
The second motivation was about wasted effort. Converting prose into a well-formed list or table is real editorial work — it is not free, and on a long content backlog it competes for time against writing new pages. If structured extraction were rare or unpredictable, that work would be hard to justify. If it were common and driven by identifiable on-page structure, then a targeted "structure pass" on the right pages would be one of the highest-leverage edits available, because it changes the format the composer can lift rather than just the words inside it. We wanted to put a number on how often structured cards appear, how often they come from a single source, and which structural properties decide the lift.
How we ran the measurement
31 client sites — 12 SaaS, 8 publisher, 6 DTC, 5 B2B services — and for each site a fixed 200-query basket. We captured every AI Overview answer card on each query, twice daily, across late April and the first three weeks of May 2026. For each card we logged its render format (prose, list, or table), and for structured cards we did the hard part: we traced the rendered structure back to source pages and classified the card as single-source lift (the rendered list or table tracked one cited page's on-page element item-for-item, allowing minor reordering and wording normalisation) or multi-source synthesis (the rendered structure merged items from two or more cited pages, identifiable when items appeared that no single cited page contained in list or table form). For single-source-lift cards we then recorded the source element's type, item count, and — for tables — column count and column semantics. The full card cohort came to 9,860 events; the structured subset came to 3,750.
Two normalisation moves matter for reading the numbers below. We excluded cards where the structured render was a recipe, a sports score, or a finance table served from a Google-owned structured-data feature rather than from open-web extraction, because those are populated by dedicated verticals and not by the general composer; they were 9% of structured cards and behave nothing like the open-web population. We also excluded cards on queries where the basket's structured-card rate was unstable across the window — a small set of queries flipped between prose and list rendering day to day, and including them would have inflated the apparent volatility of the format decision; those queries were 6% of the basket and we report on them separately under the breakdown of where this argument fails.
The shape of the structured-extraction pattern
The flat headline first. Across 9,860 cards, 38% rendered structured (list or table) and 62% rendered as prose. The structured share was strongly query-type dependent: "how to" and "steps to" queries rendered structured 71% of the time, "best X for Y" and "X options" queries rendered structured 64% of the time, "X vs Y" comparison queries rendered as a table 48% of the time, and definitional and "why" queries rendered structured only 11% of the time. The implication is that render format is largely decided by query shape before any page is consulted — the composer appears to choose a structured frame for procedural, enumerative and comparative intents, and a prose frame for definitional and explanatory intents — so the editorial question is not "should this page be structured" in the abstract but "does this page target a query type that renders structured."
Inside the 3,750 structured cards, the single-source-versus-synthesis split was the number that reset our briefs: 58% single-source lift, 42% multi-source synthesis. Lists skewed harder toward single-source lift (63%) than tables did (49%) — a coherent numbered procedure is more often lifted from one authoritative source, whereas a comparison table more often merges rows from several sources because no single page tends to compare every entity the query implies. The practical reading is that a list-rendering query is winnable by being the single best-structured source, while a table-rendering query is more often won by being one contributing row-set in a synthesised table — two different competitive games that call for two different page structures.
Driver one: structural congruence drives single-source list lift
The single strongest predictor of single-source list lift was structural congruence — whether the on-page list's item count and granularity matched the answer shape the query implied. For "steps to X" queries the composer wanted a procedure of typically 4–7 steps; on-page ordered lists in that 4–7 range were lifted at 3.4× the rate of lists carrying the same procedure but split into 12+ micro-steps, and at 2.1× the rate of lists that compressed the procedure into 2–3 over-broad steps. The composer appears to have an implicit target granularity for the answer and to prefer a source whose list already sits at that granularity over a source it would have to split or merge. Over-granular lists (every sub-action its own numbered step) and under-granular lists (the whole procedure in three giant steps) both lost to the source that matched the natural answer length.
We ran a structural test on 19 pages across 8 clients. Each page covered a procedural or enumerative topic but presented it as prose — the steps were embedded in narrative paragraphs with no list markup, or as an over-granular 12+ item list. We rewrote each into a well-formed `<ol>` or `<ul>` of 4–7 items, each item a single imperative clause, with any necessary nuance moved to a short sentence after the list rather than inside the list items. We changed nothing else — same lead paragraph, same heading, same schema. Over the 45 days after the rewrite, 13 of the 19 pages began appearing as the single-source-lifted list on at least one target query where they had previously not been cited at all; 4 pages saw partial improvement (cited but synthesised with another source); 2 saw no change. The editorial cost was a 10–15-minute restructure per page, and the payoff was the whole answer card rather than a single chip beneath a competitor's list.
Driver two: table column semantics decide table lift
For table-rendering queries the dominant predictor was not item count but column semantics — specifically whether the table had one clear entity column (the thing being compared) plus a small number of attribute columns the query actually asked about. Tables with one entity column and two or three attribute columns were lifted as single-source tables at 2.6× the rate of wide tables with six or more columns, even when the wide table contained the two or three relevant columns somewhere inside it. The composer appears to prefer a narrow, query-aligned table it can lift whole over a comprehensive table it would have to project columns out of; the wide "spec sheet" table that 2024-era SEO playbooks favoured for keyword coverage is actively disadvantaged in single-source table lift because the composer treats it as a table to mine rather than a table to lift.
We ran a structural test on 12 pages across 6 clients. Each page had a wide comparison or specification table (6–11 columns) that was being mined for one or two columns into synthesised cards but never lifted whole. For each page we added a second, narrow table immediately below the lead — entity column plus the two or three attribute columns the target query most often asked about — while leaving the comprehensive table in place further down the page for human readers. Over the 60 days after the change, 7 of the 12 pages began being lifted as the single-source table on their primary comparison query; the comprehensive table continued to be mined for long-tail attribute queries. The lesson is not "make tables smaller" — it is "publish a query-shaped narrow table for the lift and keep the comprehensive table for coverage," because the two tables serve two different extraction behaviours.
Driver three: HTML semantics beat visually-styled lists
A structural property that mattered more than we expected was whether the list or table was real semantic HTML or a visual imitation of one. Many client pages rendered "lists" as a series of styled `<div>` blocks with icons and headings, and "tables" as CSS-grid layouts of `<div>`s — visually a list or table, but with no `<ol>`, `<li>`, `<table>`, `<tr>` or `<td>` in the markup. Pages whose list was real `<ol>`/`<ul>`/`<li>` markup were lifted as single-source lists at 3.1× the rate of pages whose list was a visual imitation built from `<div>`s, holding content constant. For tables the gap was even larger — genuine `<table>` markup was lifted at 4.2× the rate of CSS-grid `<div>` tables — because the composer appears to rely on the table's row-and-cell structure to reconstruct the comparison, and a grid of `<div>`s gives it no reliable cell boundaries to read.
This was the cheapest and most reliable fix in the whole audit, because it changes no words at all. We re-marked 15 pages across 7 clients from `<div>`-based pseudo-lists and CSS-grid pseudo-tables into semantic `<ol>`/`<ul>` and `<table>` markup, keeping the visual rendering identical via CSS. Over the 30 days after the re-mark, 11 of the 15 pages saw structured-card citation appear or increase on their target queries, with no content change whatsoever. The caveat is that the markup has to be honest about the content — wrapping unrelated promotional blocks in `<li>` tags to fake a list produced no lift and on two pages produced a citation drop, consistent with the cross-checking behaviour we have seen the composer apply to overstated schema.
What changed in our content checklist
Three changes. We added a "render-format target" to every editorial brief: before writing, the brief now records whether the target queries render structured or prose (by running them and capturing the current card format), and pages targeting structured-rendering queries are built around a query-shaped list or table as the primary answer asset rather than around a prose answer paragraph. We added a "semantic markup" requirement to our front-end handoff: any list or table that is meant to be extractable must ship as real `<ol>`/`<ul>`/`<li>` or `<table>`/`<tr>`/`<td>` markup, not as a `<div>` imitation, and our page-template review now flags pseudo-lists and CSS-grid pseudo-tables on answer-bearing pages. And we changed our reporting: per-query render format and single-source-versus-synthesis status now appear in client reports alongside citation counts, so a page that is being mined into synthesised cards but never lifted whole is flagged as a structure-pass candidate.
We dropped one habit. Through 2024 and 2025 we built wide, comprehensive tables on the keyword-coverage theory that more columns meant more long-tail surface area. The audit shows that the wide table is a coverage asset, not a lift asset, and that the page also needs a narrow query-shaped table to win the single-source table lift on its primary query. We now treat the two as separate deliverables on the same page rather than trying to make one table do both jobs, because the comprehensive table optimises for mining and the narrow table optimises for lifting, and those are different extraction behaviours that reward different structures.
- 01Decide render format before you write. 38% of cards render structured; "how to" and "steps to" queries render structured 71% of the time, so a prose answer on a procedural query is the wrong asset for the card the composer wants to build.
- 02Match list granularity to the answer's natural length. 4–7-item lists were lifted at 3.4× the rate of 12+-item lists carrying the same procedure; 13 of 19 audited pages won the whole card after a 10–15-minute restructure.
- 03Publish a narrow query-shaped table for the lift and keep the comprehensive table for coverage. Narrow 1-entity + 2–3-attribute tables lifted at 2.6× the rate of 6+-column tables; the two tables serve two different extraction behaviours.
- 04Ship real semantic markup, not `<div>` imitations. Genuine `<ol>`/`<li>` lifted at 3.1× and genuine `<table>` at 4.2× the rate of visual imitations — the single cheapest fix in the audit, with no content change at all.
Where this argument breaks
For definitional and explanatory queries the structured-extraction framing barely applies — those queries render structured only 11% of the time, and forcing a list onto an explanatory answer can reduce citation by signalling a format mismatch to the composer. For YMYL queries (medical, financial, legal) the composer is more conservative about lifting a single source's list whole and synthesises across sources at a higher rate, so the single-source-lift lever is weaker there even on procedural queries. For comparison queries where no single page covers every entity the query implies, the table game is a synthesis game rather than a single-source-lift game, and the right move is to be the cleanest contributing row-set rather than to publish a comprehensive table you hope to get lifted whole. For Chinese-language AI search (文心一言, 元宝, 通义), structured rendering is less common — the parallel Chinese-language audit showed roughly 24% structured cards versus our 38% — and the semantic-markup lever still applies but the structural-congruence effect size is smaller. A small set of queries flipped between prose and list rendering day to day; on those the format decision was unstable and no on-page structure reliably won. Our window was 60 days and the cohort was 31 sites; the per-vertical numbers should be read as point estimates. Outside those carve-outs the lesson holds: in 2026 a large share of AI Overview answers are lists and tables, the structure is frequently lifted from a single source, and on-page list and table structure is a high-leverage and underused editorial control.