Make product comparison tables clear enough to verify: an editorial QA sheet

A product comparison table is clear enough to verify when every cell answers four questions on its own: what exactly is being claimed, in what unit, with what exception, and as of what date. A cell that says "Yes", "Unlimited" or "Included" fails all four. A reader who lands on the row alone, or an AI engine that lifts a single line from your page into an answer, cannot tell what the "Yes" refers to or whether it is still true. This post gives you an editorial QA sheet that turns each cell into a checkable statement, plus a plain-text equivalent of the table that carries the same facts.

In short

• Vague cells are the main defect. "Yes", "Unlimited" and "Supported" need a scope, a unit, an exception and a date before anyone can check them.
• Verify a table by turning each cell into one plain sentence and giving it an owner and a source.
• A plain-text equivalent of the table, in the page itself, helps readers who cannot use a grid and gives any summariser a sentence to quote instead of a cell to guess at.
• A table can be wrong in ways that look tidy. Alignment and neat ticks make a table feel more certain than its facts.
• Nobody can promise that a cleaner table earns more AI citations. The case for doing it is accuracy, and the effect on citations is a hypothesis to test.

Why do comparison tables fail verification?

Comparison tables fail because each cell is written to be scanned, not checked. Scannable cells are short, and short cells drop the qualifiers that make a claim true or false.

Think about how a table gets built. Someone in product marketing gathers a list of capabilities, someone else fills the cells from memory or an old sales deck, and design tidies the result into rows of ticks and dashes. Each step removes context. The final table looks authoritative, but nobody can say where "Included" came from, which plan it applies to, or when it was last true.

This matters twice. Buyers use tables to decide, and a cell that overstates a capability can turn into a support question or a broken expectation. And the same table may be read by an AI engine summarising your product for a buyer. If the engine states a capability that your table implied but never actually promised, the wrong claim can reach the buyer with your page as its apparent source. Our post on what to do when AI gets your pricing or product facts wrong is about the response once that has happened; this post is about not handing the engine an ambiguous cell in the first place.

What makes a table cell verifiable?

A verifiable cell is one you could hand to a colleague with the instruction "check this is true today" and they would know exactly what to check and where to look. That requires four properties.

A label that names the capability precisely. "Integrations" is a heading, not a capability. "Two-way sync with a named document store" is a capability.

A unit and a scope. "Unlimited" needs a noun and a boundary: unlimited what, per what, on which plan or tier. "50 MB" needs to say per file, per upload or per month.

An exception. Most capabilities have a condition: only on one plan, only in certain regions, only after a set-up step, only for a file type. If an exception exists and the cell omits it, the cell is overstated. If you cannot name any exception after honest checking, say nothing rather than inventing caution; overstating a limitation is also a defect.

A source date. A capability table is a snapshot. State when it was last verified and by whom, on the page, so a reader (or a summariser) can judge freshness.

A fifth check sits outside the cell: whether each competitor column is something you can defend. Comparisons that describe another company's product go stale without notice, and you cannot verify their internals. Describe what their public documentation states, cite the page and its date, or leave the column out.

How do you turn a table into checkable statements?

Rewrite every cell as one sentence in the form "subject, capability, scope, exception, date", then assign each sentence an owner and a source. If you cannot write the sentence, you have found a cell that fails.

Take the row and column headings together with the cell. "Row: Audit trail. Column: Quillstone. Cell: Yes." becomes "Quillstone records every edit to a reviewed document with the user and timestamp, verified 30 September." Now a colleague can go to the product, make an edit, and see whether the record exists.

Doing this for a whole table is tedious, which is the point. The rewrite surfaces the cells nobody in the company can source. Those are the ones to fix first, either by finding the evidence or by changing the cell to say less.

Enlarge image

The editorial QA sheet

Copy this sheet into a spreadsheet and fill one row per table cell. A table with 6 rows and 4 columns has 24 cells; not every cell needs the full treatment, but every capability cell does.

TABLE QA SHEET
Table name and page URL:
Reviewed by:                     Review date:
Next review due (set a date):

Per cell, one row:
 1. Table position (row label / column label):
 2. Cell text as published:
 3. Plain-sentence rewrite (subject, capability, scope):
 4. Unit stated?                        (yes / no / not applicable)
 5. Scope stated? (plan, region, limit)  (yes / no / not applicable)
 6. Exception stated or confirmed none?  (stated / confirmed none / MISSING)
 7. Source of truth (product page, docs page, contract, engineer's name):
 8. Source date:
 9. Owner who can confirm it:
10. Verdict: verified / needs rewording / needs evidence / remove
11. Claim wording: any superlative or promise that the source does not back?
12. Competitor cell only: public page cited, and date read:

Whole-table checks:
 A. Every column heading names a plan or product exactly as it is named elsewhere.
 B. Every symbol (tick, dash, dot) has a legend, and the legend is on the page.
 C. "As of" date printed near the table.
 D. Plain-text equivalent present and matches the table cell for cell.
 E. Table is real text in the page, not an image of a table.
 F. Cell wording agrees with the pricing page, the docs and the FAQ.
 G. Review owner and next review date recorded.

Two rules keep the sheet honest. First, "MISSING" in item 6 is a failure, not a formality: someone must say either what the exception is or that they checked and there is none. Second, the verdict column is written by someone other than the person who wrote the cell.

What should the plain-text equivalent look like?

The plain-text equivalent is a short list, next to the table, that states each column's facts in full sentences. It serves two audiences: readers who cannot use a grid comfortably (for example someone using a screen reader, or reading on a narrow phone), and any system that summarises your page.

Build the table itself as a real table with proper header cells, not as an image or a set of styled boxes, so assistive tools can announce which row and column a cell belongs to. Then add the text equivalent under it. Use this pattern:

Plain-text equivalent (as of [date]):

[Column name]:
- [Capability]: [full sentence with scope, unit and exception].
- [Capability]: [full sentence].

[Next column name]:
- ...

Not included in [column name]: [list what is absent, in words, so a dash is not the only signal].

The last line matters. A dash in a cell can mean "not available", "not applicable", "coming soon" or "ask us". Say which, in words.

Worked example: Quillstone's capability table

Illustrative example: Quillstone and its competitors are fictional, and the numbers are made up to show the method.

Quillstone sells document-review software to mid-sized legal and compliance teams. Its comparison page has this table, which the team considers finished.

An editor runs the QA sheet and rewrites each Quillstone cell as a sentence. Here is what happens.

The example shows the pattern: four of the five problems are a missing scope, unit or exception, and the fifth is a source problem. The checked arithmetic is small: 12 interface languages minus 9 review languages leaves 3 languages that are interface-only, which is worth saying in the plain-text equivalent so a reader does not assume 12.

The plain-text equivalent for the Quillstone column reads:

Plain-text equivalent (as of 30 September):

Quillstone:
- Audit trail: records every edit and export of a reviewed document with user
  and timestamp; views are not recorded.
- Storage: no total storage cap; a single file can be up to 2 GB.
- Redaction: included on the Team and Enterprise plans, not on Basic.
- Languages: interface in 12 languages; document review in 9. The other 3 are
  interface-only.

Not included in Quillstone: view logging in the audit trail.

Now every cell can be checked, and every line could be quoted alone without misleading anyone.

Enlarge image

How do you keep a table true after it is published?

Assign every table an owner and a next review date, and tie that date to product changes, not to the calendar alone. A table verified in March is only as good as the last release that touched a listed capability.

Practical triggers for an extra review are a pricing or plan change, a release that adds or removes a capability, a change to a listed limit, and any time the same fact is edited on another page. The last one is the most common way tables drift: someone corrects the pricing page and nobody remembers the table.

Print the "as of" date next to the table. That date is a promise to the reader that you checked, so update it only when you actually recheck, never as a cosmetic refresh.

If your team finds the same capability described three ways across the pricing page, docs and table, treat that as a separate consistency problem. Our posts on checking that company information is consistent across your own pages and on auditing your pricing page for the questions AI buyers ask are the places to start; the pricing page is a sensible first comparison because it states plans and limits.

How can DiscoveredBy help you check the claims?

Once your table's facts are written as one-line statements, you can check whether AI engines repeat them correctly. DiscoveredBy's Fact check lets you keep a list of approved facts about your own brand, each in one of six categories: pricing, company, product, availability, policy or other. A fact is one line of plain text of 5 to 300 characters, which is the shape of the sentences your QA sheet produces. Split a long sentence into separate facts rather than cramming it into one line. Fact check is available depending on your plan; see plans and limits.

Enlarge image

A weekly study asks several AI engines (which ones depends on your plan) general questions about your brand, one per category such as pricing or product, and checks each answer against your active facts. It can also check answers to a small set of your tracked prompts. The questions use your brand name and domain, never the text of a fact, so a fact is scored only when an answer happens to address it; otherwise it reads "Not addressed yet". Fact check covers facts about your own brand, so it will not check a competitor column.

Where an answer contradicts a fact, the finding shows the quote, the engine and an AI-written explanation. The docs are explicit that the verdict is the model's judgement; the code guarantees only that the quote is in the answer and the fact is one of yours. Owners and editors can review a finding and mark it confirmed wrong, or mark that the answer agrees with the fact, or that the fact is out of date. There is also a Suggest from my site option that drafts candidate facts from your own pages. Each draft carries the sentence it came from, and the docs advise reading each statement against that sentence before you approve it.

On the writing side, the Articles workflow labels each claim in a draft it writes, for example as verified by source, unsupported or promotional, and any claim that is not verified by source counts against the draft's citation readiness score. That is a check on drafts DiscoveredBy writes for you, not on tables you publish yourself, so use the QA sheet above for those and treat the claim labels as a model for the discipline.

Common mistakes and what this cannot tell you

Treating ticks as facts. A tick is a summary. The sentence behind it is the fact. If nobody can write the sentence, the tick should go.

Refreshing the date without rechecking. A date that moves while the cells stay the same is a small deception. It is also the fastest way to lose the trust the table was meant to build.

Hiding exceptions in a footnote. A footnote that says "some limits apply" repairs nothing. Put the exception in the cell or in the plain-text equivalent, where a reader or summariser will find it.

Comparing against details you cannot verify. If a competitor cell relies on a rumour or an old call, remove it. Describing another company's product inaccurately is a risk you do not need.

Assuming a clean table wins citations. We have not shown that verifiable tables earn more AI citations, and this post does not claim it. Fact check flags answers that a model judges to contradict your facts; it does not prove why an engine phrased an answer the way it did. Treat a cleaner table as an accuracy improvement, and if you want to test any effect on visibility, do it as a before-and-after comparison on a fixed set of prompts, as in did your content update help? a practical before-and-after review.

Frequently asked questions

Should I use a table or a list for comparisons?

Use a table when readers genuinely compare the same attributes across several options, and a list when you are describing one option. Whichever you choose, the plain-text equivalent keeps the meaning available to readers and systems that cannot use a grid.

Do I need the plain-text equivalent if the table is a real HTML table?

It is still worth having. A real table helps assistive tools navigate, but it does not carry your scope, unit and exception in a sentence that can be quoted alone. The equivalent is where those qualifiers live.

How often should a comparison table be reviewed?

Review it on every change that touches a listed capability or price, and set a fixed date as a backstop. The right interval depends on how fast your product changes, so choose one your owner will really keep.

Can I include competitors in the table?

You can, but only with claims you can source from their public documentation, with the page and the date you read it recorded on the QA sheet. If you cannot source a cell, remove it rather than estimate.

Will fixing my tables make AI engines quote me?

Nothing here promises it. The dependable benefit is that the claims on your page are accurate and checkable. Whether engines quote you more often is something you can test but should not assume.

Next step

Take your most viewed comparison or capability table, run the QA sheet on it this week, and write the plain-text equivalent. Then add the corrected statements as approved facts in DiscoveredBy, so answers about your brand are checked against them. If the fix needs a new page rather than an edited table, see our post on turning an AI citation gap into a content brief.