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

Every content page the author writes begins as prose before transforming into primarily tables. This was not the initial plan but emerged after observing which parts of the content readers actually engaged with. The author now adheres to a specific data structure that consistently yields successful results, along with understanding common table shortcomings.

When someone uses the site through a search engine, they typically have a single question in mind. If the answer is between 2 to 3 square feet of space per bird, a paragraph would require them to read three sentences to extract the information. However, a table can convey this same data in a single glance. For instance, consider the following two ways of presenting 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."

vs.

"**Space Per Bird**"

"**Inside the Coop:** 2–3 sq ft"

"In the Run: 8–10 sq ft"

The table format proves more scannable, quotable, and retains its usability even when read on a phone at an inconvenient time, such as 7am in a garden center. The optimal table structure consists of two columns, each representing a single axis of variation. The depth of a raised bed, for example, varies from 15 cm for lettuces, herbs, and radishes, to 30 cm for carrots, peppers, and tomatoes. This depth chart also covers what to do if your bed is already built with the incorrect depth.

One column represents the element that the reader controls, while the other represents the resulting consequence. Adding a third column is only justified if it is genuinely supplementary. For example, a food pantry table listing the storage duration of different grains shows that white rice lasts two years, brown rice lasts 3–6 months, and so on. However, this table has five columns and includes a search box because storage times have a third dimension (sealed vs. unsealed).

Failure Mode 1: Tables that Behave Like Paragraphs

If a table cell contains a sentence with "however" in it, it is no longer tabular data but rather a paragraph in a table costume. This format results in poor readability. To test this, try to read the table by scanning only its first column. If you cannot, the axis may be incorrect.

Failure Mode 2: Tables that Do Not Adapt to Mobile Devices

A 700px wide table on a 390px screen forces the entire page to scroll horizontally, which is an undesirable user experience. The solution is to wrap the table inside a container with the class "table-scroll":

<div class="table-scroll">

<table>

...

</table>

</div>

The .table-scroll CSS rule ensures that the table scrolls horizontally without affecting the rest of the page. Shrink the font instead, as scrolling the entire page is not an ideal solution.

Failure Mode 3: Absence of Caption or Context

A bare table assumes the reader already understands what each column signifies. Adding a one-sentence caption above the table eliminates this assumption. For example:

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

This sentence provides essential context for interpreting the table data. Properly marking up the table with <thead> and <th> elements is essential for accessibility. Screen readers will announce the table content as "Space, in the run: 8–10 sq ft," rather than just "8–10 sq ft."

While tables are ideal for lookup, prose is necessary for reasoning. The most useful pages often combine both formats, providing a table for the numbers, a short paragraph explaining the reasoning behind those numbers, and a section discussing exceptions. The companion planting chart is an excellent example, where the chart itself is a table, but the accompanying paragraph explains that most pairings are based on folklore, with only structural effects like shade, support, and trap cropping being reliable.