Most of my content pages are secretly tables. Here is the data shape that works

Every content page I write starts as prose and ends up mostly tables. That was not the plan — it is what happened after watching which parts people actually used.

Here is the data shape that kept working, and the three ways tables fail.

Why tables win for reference content

A reader arriving from a search query has one question. If the answer is "2 to 3 square feet per bird", a paragraph makes them read three sentences to extract it. A table gives it to them in one glance.

Compare the two forms for the same information:

Hens need roughly two to three square feet of floor space inside the coop, and eight to ten square feet in the run. Crowding is the single biggest cause of pecking.

versus:

Same content. The table is scannable, quotable, and — this matters — it survives being read on a phone at 7am by someone standing in a garden centre.

The shape that keeps working: two columns, one axis

The tables that perform best have a single axis of variation. Depth of a raised bed:

That is the full depth chart, which also covers what to do if your bed is already built at the wrong depth.

One column is the thing the reader controls; the other is the consequence. Three columns work if the third is genuinely supplementary:

The full version of that one has five columns and a search box, because storage times have a genuine third dimension (sealed vs not).

Failure mode 1: tables that are really paragraphs

If a cell contains a sentence with "however" in it, it is not tabular data. It is a paragraph wearing a table costume, and it reads badly.

The test: can you read the table by scanning only the first column? If not, the axis is wrong.

Failure mode 2: tables that break on mobile

A 700px table on a 390px screen forces the whole page to scroll horizontally. The fix is one wrapper:

<div class="table-scroll"><table>…</table></div>

.table-scroll { overflow-x: auto; -webkit-overflow-scrolling: touch; }

Do not shrink the font instead. Scrolling one element is fine; scrolling the page is not.

Failure mode 3: no caption or context

A bare table assumes the reader already knows what the columns mean. One sentence above it removes that assumption:

Storage times assume an airtight container in a cool, dark place. Heat roughly halves every number here.

That sentence is doing more work than any row in the table.

The markup that matters

Use real <thead> and <th>. It costs nothing and it gives screen readers the column association, so a cell is announced as "8–10 sq ft, in the run" rather than just "8–10 sq ft".

<table>
  <thead><tr><th>Space</th><th>Per bird</th></tr></thead>
  <tbody><tr><td>Inside the coop</td><td>2–3 sq ft</td></tr></tbody>
</table>

I did not do this on my first twenty pages and had to go back through all of them.

Where prose still wins

Tables are for lookup. Prose is for reasoning. The most useful pages I have end up as both:

• A table for the numbers
• A short paragraph for why the numbers are what they are
• A section for the exceptions, which are almost never tabular

The companion planting chart is the clearest example. The chart is a table. But the useful part is the paragraph after it explaining that most of the pairings are folklore and only the structural effects (shade, support, trap cropping) are reliable. That paragraph could not be a table.

A quick test before publishing

Read only the H2s, then only the first column of every table, then only the first sentence of every paragraph. If those three passes together do not answer the page's title question, the structure is wrong — regardless of how good the writing is.