A Comparison Table That Survives Extraction
Build tables so each cell means something on its own: label every column with a noun phrase rather than a symbol, put one fact per cell, never merge cells, never use a checkmark or a dash without a legend in the same cell, and repeat units inside cells rather than putting them in the header alone. Anything qualifying the data — the date it was checked, the plan tier it applies to, the source — belongs inside the table or immediately adjacent, because footnotes below a table are the first thing lost when a table is extracted. A row lifted out of its page should still be true.
Tables get extracted more readily than prose because their structure is explicit. That is an advantage until the structure carries meaning that the cells do not — at which point extraction produces something confidently wrong.
The rules
| Rule | Bad | Good |
|---|---|---|
| Label columns as nouns | "$" | "Starting price per month" |
| One fact per cell | "$20, annual only, 5 seats" | Three columns |
| No merged cells | One cell spanning three rows | Repeat the value in each row |
| No bare symbols | "-" | "Not offered" |
| Units inside the cell | Header says "(USD)" | "$20" in the cell |
| Qualifiers in the table | Footnote below | "Checked Sept 2026" column or cell text |
The merged-cell trap
A cell merged across three rows reads correctly to a person and is ambiguous to anything parsing structure — the value may be attached to the first row only, or repeated, or dropped. Since the rows most worth merging are usually the ones carrying a shared price or a shared limitation, the cost of getting it wrong is a factual error rather than a formatting one. Repeat the value; the redundancy is the point.
Checkmarks and dashes
A tick means supported. A dash means unsupported, or unknown, or not applicable, or that the writer ran out of time. Extracted without the surrounding page, none of that is recoverable. Use words. 'Not offered', 'Unknown', 'Included on paid tiers' each survive on their own, and they force the writer to know which one is true.
The row-alone test
Read any single row as if it arrived with no page around it. Does it say what product it is about, what the numbers mean, when they were true, and what a blank means? If not, the row needs more in it. This takes a minute per table and catches nearly everything in this guide.
FAQ
Should I use table markup or a formatted list? — Real table markup, where the data is genuinely tabular. Lists styled to look like tables lose the column relationships that make tables extractable in the first place.
How many columns is too many? — Past about five, rows stop being readable on a phone and start getting truncated in extraction. If you need more, the table is probably two tables answering two questions.
Where should the as-of date go? — Inside the table, as a column or in the cells where values change often. Below the table it is a footnote, and footnotes are the first casualty of extraction.
Put this to work on your own website.
Fenn finds what your customers ask, drafts the articles and site fixes, and measures what ChatGPT, Claude, Gemini, Perplexity and Grok say about you — with every change waiting for your approval.