Skip to content
pageinspection

Lists, tables and definitions: choosing the shape of an answer

Some questions have a shape. "What are the steps" is a sequence, "which should I pick" is a comparison, "what does this term mean" is a definition. Answering any of them in flowing prose is a choice to make the reader do the structuring themselves.

The short answer

The shape of your answer decides which result format you can win. A comparison across two or more dimensions belongs in a table, an ordered process or an unordered set belongs in a list, and prose wins neither. Real markup is required: a table drawn with divs is not a table to anything reading the page.

ImportantAudit check · Structured answers

Matching the shape to the question

The mapping is not subtle once stated. A sequence of steps wants an ordered list. A set of options with the same attributes wants a table. A term and its meaning want a definition list, or at minimum a bolded term followed by its explanation. A set of unordered items wants a bulleted list.

Prose is the right container for argument, nuance and anything where the connective tissue between points is the value. It is the wrong container for four products with three attributes each, and a sentence like "the standard model is 40mm and rated to 12 bar while the compact is 25mm and rated to 9 bar" is a table that has been flattened for no reason.

What the check counts

The presence of ordered lists, unordered lists, tables and definition blocks on a page, against the volume of prose around them, and whether content that reads as structured is actually marked up as structured.

That second clause is where most pages fail. A page can be full of visual lists, built from divs with a bullet glyph and a margin, and score zero here. Rendered output and parsed structure are different things, which is the same distinction semantic markup is about at a larger scale.

A table that counts as a table

The difference between a table and a grid of divs is whether a machine can tell which cell belongs to which column heading. That relationship is what a table encodes and what a grid cannot.

comparison.html
<!-- Looks like a table. Parses as twelve unrelated
     strings: nothing connects "12 bar" to "Pressure". -->
<div class="grid">
  <div class="cell head">Model</div>
  <div class="cell head">Bore</div>
  <div class="cell head">Pressure</div>
  <div class="cell">Standard</div>
  <div class="cell">40mm</div>
  <div class="cell">12 bar</div>
</div>

<!-- Same rendering with the right elements. Every cell
     is now addressable by its column, and scope="col"
     states which heading governs which. -->
<table>
  <caption>Widget models compared</caption>
  <thead>
    <tr>
      <th scope="col">Model</th>
      <th scope="col">Bore</th>
      <th scope="col">Pressure</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Standard</th>
      <td>40mm</td>
      <td>12 bar</td>
    </tr>
    <tr>
      <th scope="row">Compact</th>
      <td>25mm</td>
      <td>9 bar</td>
    </tr>
  </tbody>
</table>

Three parts do the work: th with scope for the headings, a caption so the table has a name when it is extracted away from its surrounding text, and a real theadso the header row is not just the first data row. A screen reader user can then hear "Compact, Pressure, 9 bar" instead of "9 bar" with no context.

Definition lists are the underused one. A glossary section, a set of parameters, a list of error codes and their meanings are all dl with paired dt and dd, and the pairing is the information.

Reading your own markup back

Quick manual read: use your browser's reader mode on the page. It rebuilds the document from structural elements, so a list that survives is a real list and a list that dissolves into a paragraph was never one.

This one needs the full crawl

This counts the lists, tables and definition blocks on a page against the volume of prose around them, which is a shape only visible when the whole page is parsed.

The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.

Run the full audit, free

Why the shape decides which result you can win

Featured snippets come in distinct formats, and the format is chosen from your markup rather than negotiated. A paragraph snippet, a list snippet and a table snippet are three different presentations, and a page with no list has no route to the list snippet no matter how well it answers the question.

This is the concrete, mechanical reason the shape matters, and it is more useful than any general claim that structure is good. For a "how to" or "best" or "steps" query, the surface that wins is usually a list, so a page answering in prose is competing for a slot it cannot fill. Which of the formats you are eligible for is part of what snippet readiness reports.

The overcorrection

Not everything is a list, and a page of bullets is not a structured page.

Fragmenting an argument into bullets removes the reasoning that connected the points, which is usually the part worth reading. A three-item bulleted list where each item is a full sentence fragment of a larger argument is worse than the paragraph it came from: it looks organised and says less.

The test is whether the items are genuinely parallel. If they are the same kind of thing, a list is right. If one of them depends on the one before it, you have written prose with bullet points in front of it.

Why format eligibility is a ceiling, not a wall

Because it changes which results you can compete for, without preventing you from competing at all. A prose-only page answering a comparison question still ranks and still gets read; it is structurally ineligible for a class of result, which is a ceiling rather than a wall.

It clears Refinement because the fix is often mechanical and the gain is a specific eligibility, and it falls short of Critical because nothing is lost or hidden. Worth contrasting with markup semantics, which carries an accessibility harm alongside the extraction cost and is rated on both. The full reasoning is on the audit page.

Confirming the structure is real

Reader mode again, or the accessibility tree, where a real table announces its dimensions and a real list announces its item count. A structure that reports "table with 3 columns, 4 rows" is doing the job; one that reports nothing is still divs.

Then re-crawl for the aggregate. The number worth watching is not how many lists you have but whether the pages that answer comparative and procedural questions are the ones that have them, since that is where the eligibility is won or lost.

Questions this check raises

When should I use a table instead of a paragraph?
When you are comparing two or more things across two or more attributes. That is precisely the shape a table exists for, and it is the shape prose handles worst, because a reader has to hold every value in memory to compare them.
Does a table built with divs count?
Not to anything reading the markup. A grid of divs is visually a table and structurally a pile of boxes, so a screen reader cannot announce row and column relationships and an extraction system cannot recover the data. Real table, thead and th elements are what make it a table.
Can I overuse lists?
Yes, and the overcorrection is common. Breaking connected reasoning into bullet points removes the connections that were doing the work, leaving a set of fragments that each look like a claim. Use a list when the items are genuinely parallel and a paragraph when they are not.