AI assistants are surprisingly good at reading prose, and surprisingly bad at reading a spec sheet built from nested <div> tags, an image of a pricing grid, or a "table" that is really three columns of floating text. When the structure is unclear, models mix up which number belongs to which product, quote the wrong plan's limits, or skip the facts entirely.
Clean, semantic HTML removes that ambiguity. A real <table> with header cells, a definition list of attributes, or a numbered list of steps tells any parser, whether a screen reader, a search engine or an AI crawler, exactly how each piece of information relates to the others.
This guide shows which HTML formats make facts easy to extract, with before-and-after examples you can copy, a checklist for spec pages and comparison tables, and the mistakes that most often cause AI tools to misquote your data.
Key Takeaways
- Use real HTML elements for structured facts:
<table>with<th>for comparisons,<dl>for name–value specs,<ol>for sequences and<ul>for sets. - Every value should sit next to an explicit label and unit; "12" means nothing, "Battery life: 12 hours" is extractable.
- Do not put key facts only in images, tabs that load by JavaScript, or CSS-positioned layouts.
- Structured data should repeat what is visible on the page, never contradict it.
- Accessible markup and AI-friendly markup are largely the same thing, so you improve both at once.
Why structure affects AI extraction
When an AI search system retrieves your page, it typically works with the text and HTML it fetched, broken into passages. Relationships that are obvious visually (this number is in the "Pro" column) may be lost if the markup does not encode them. Semantic elements keep those relationships in the text itself.
There is supporting evidence that structure correlates with citations, though not proof of cause. In a Semrush study published in January 2026, comparing over 300,000 URLs cited by ChatGPT Search, Google AI Mode and Perplexity with URLs ranking in Google's top 20, "section structure" scored 22.91% higher among cited pages. The authors recommend headings, lists and tables to help LLMs segment content. Note that the study scored visible text only, not HTML or schema.
The accessibility community has long explained why header markup matters. MDN puts it this way:
“The scope attribute can be added to the <th> element to tell screen readers exactly what cells the header is a header for”
— MDN Web Docs, MDN: HTML table accessibility
The same programmatic association that helps a screen reader helps any machine reader connect a value to its row and column.
Which format for which kind of fact
| Information type | Best HTML | Example | Avoid |
|---|---|---|---|
| Comparing several items on the same attributes | <table> with <thead>, <th scope>, <caption> | Plan comparison, product comparison | Div grids, images of tables |
| Attributes of a single item | <dl> with <dt>/<dd>, or a two-column table | Product spec sheet, service details | Runs of bold text and line breaks |
| Ordered process | <ol> | Installation steps, onboarding | Paragraphs starting "First", "Then" |
| Unordered set of features or options | <ul> | Features, ingredients, requirements | Comma-separated sentences of 15 items |
| Single key fact | One clear sentence under a descriptive heading | "The warranty lasts 3 years." | Facts buried in a marketing paragraph |
| Code, commands or exact values | <pre><code>, <code> | API endpoints, config lines | Screenshots of code |
Before and after: a spec sheet
Before
<div class="specs">
<div class="col"><b>Weight</b><br><b>Battery</b><br><b>Warranty</b></div>
<div class="col">1.2<br>12<br>3</div>
</div>Labels and values live in separate containers, units are missing, and the only link between "Battery" and "12" is visual alignment.
After
<h2>Model X200 specifications</h2>
<dl>
<div><dt>Weight</dt><dd>1.2 kg</dd></div>
<div><dt>Battery life</dt><dd>Up to 12 hours (video playback)</dd></div>
<div><dt>Warranty</dt><dd>3 years, parts and labour</dd></div>
</dl>Each label sits beside its value with a unit and context. MDN notes that "Description lists are useful for displaying metadata as a list of key-value pairs", and HTML allows wrapping each pair in a <div> for styling.
Before and after: a comparison table
Before
A pricing grid exported as a PNG, with a tick icon in each cell and a footnote "*annual billing only" in small grey text below the image.
After
<table>
<caption>Plan comparison (prices per month, billed annually)</caption>
<thead><tr><th scope="col">Feature</th><th scope="col">Starter</th><th scope="col">Pro</th></tr></thead>
<tbody>
<tr><th scope="row">Users included</th><td>3</td><td>10</td></tr>
<tr><th scope="row">API access</th><td>No</td><td>Yes</td></tr>
</tbody>
</table>The caption carries the billing condition, text replaces tick icons ("Yes"/"No" is unambiguous), and row and column headers make every cell self-describing. For whole pages built around this pattern, see our guide to comparison pages.
Step-by-step: make a fact-heavy page extractable
- Inventory the facts. List every number, limit, price, dimension and condition on the page.
- Choose the right element for each group using the table above.
- Add labels and units to every value and spell out conditions ("billed annually", "excluding VAT").
- Use text instead of icons for yes/no and status cells; if you keep icons, add visible or accessible text.
- Keep tables simple. One header row, one header column, no merged cells unless essential. Split very large tables by topic.
- Put the table near its explanation. A one-sentence summary above the table (the answer-first pattern) gives AI tools a quotable line plus the detail.
- Render it in the HTML. Check the page source, not just the browser view. Content injected late by JavaScript may be missed by some AI crawlers (see JavaScript and AI crawlers).
- Mirror key facts in structured data where a schema type exists (Product, Offer, Event), keeping values identical to the visible text.
Structured data vs visible structure
Schema markup and HTML structure do different jobs. Structured data gives search engines explicit, typed values; HTML structure makes the visible content itself unambiguous. Google's AI features documentation lists "Making sure your structured data matches the visible text on the page" among its best practices, so treat the visible table as the source of truth and the markup as a mirror. Our guides to structured data for AI search and product and merchant listing schema cover the markup side.
Quick audit checklist for fact-heavy pages
| Check | Pass looks like | Common fail |
|---|---|---|
| Facts in HTML text | Visible in page source without clicking | Specs inside images, PDFs or lazy-loaded tabs |
| Labels and units | "Height: 180 cm" | "180" in an unlabelled cell |
| Table headers | <th> with scope, plus a <caption> | First row styled bold but marked up as <td> |
| Conditions stated | Billing period, tax, region next to the price | Conditions only in a footnote or tooltip |
| One source of truth | Same numbers on product page, help docs and blog | Old figures left on older pages |
| Schema consistency | Markup values equal the visible values | Schema price differs from the page price |
Run the same checklist on support content too: knowledge-base articles are often what AI assistants quote for limits and settings, as we cover in help centre docs for AI. Semrush's 2026 guide to optimising for AI search engines likewise recommends semantic HTML for headings and lists.
Common mistakes
- Tables as images or PDFs only. Provide an HTML version of every important table.
- Tabs and accordions that load content on click. If the text is not in the initial HTML, some crawlers never see it.
- Using tables for layout. It confuses the relationship between cells and real data.
- Ticks, crosses and colours with no text. Machines read "Yes", not a green circle.
- Missing units and conditions. "From 49" with the currency and billing period in a footnote invites misquotes.
- Conflicting numbers across pages. If the spec page and a blog post disagree, an AI tool may quote either. Keep one source of truth.
Tables and lists work best alongside self-contained passages; our guide to content chunking explains how to write sections that stand on their own, and content readability covers the prose around them.
Related Guides
- Answer-First Writing: Structuring Pages for AI Answers
- Query Fan-Out: Covering the Sub-Questions AI Mode Searches For
- Writing for Long, Conversational Prompts
Frequently Asked Questions
Do AI tools read HTML tables correctly?
Generally they handle simple, well-labelled tables well. Problems usually come from tables built with divs, images of tables, merged cells or values without labels and units.
Should I use a table or a definition list for product specs?
Both work. A description list (dl) suits name–value pairs for a single item; a table is better when comparing several items on the same attributes.
Do lists help pages get cited in AI answers?
There is correlational evidence. A January 2026 Semrush study found cited pages scored higher on section structure. Lists help because each item is a clear, self-contained statement, but they are not a guarantee of citation.
Is schema markup enough without visible tables?
No. Google advises that structured data match the visible text. Visible, well-structured HTML should carry the facts; schema mirrors them.
How big should a comparison table be?
Keep it focused. Several small tables on specific topics are easier for readers and machines than one huge grid with merged cells.
Make your facts impossible to misread
AI tools cannot cite what they cannot parse. Convert image tables to HTML, give every value a label and unit, and keep structured data in sync with the page. If you would like a page-by-page review of your product, pricing or spec pages, our on-page optimisation service can help. Request a quote to get started.
