Guide · Beginner
Headings, Lists and Tables: Structure LLMs Prefer
No AI engine publishes a preferred format, so structure content for readers: descriptive headings, lists for steps, tables for comparisons. Google says you don't need to write in a specific way for generative AI search, and that semantic HTML isn't required but is "generally a good idea" because it helps users such as screen-reader users navigate (Google). Good structure helps people first and does no harm to machines.
Facts are from Google Search Central and W3C, accessed 30 Oct 2026. Recommendations marked "our view" are interpretation.
On this page
- What does Google say about structure?
- How should you write headings?
- When should you use a list?
- When should you use a table?
- Do question headings help AI answers?
- Which structure pitfalls should you watch for?
- What's a worked example?
- How do you check structure?
- Does structured data replace visible structure?
- How much formatting is too much?
- Should every page look the same?
- Do AI engines read Markdown better than HTML?
- Checklist
- From MentionX data: which page types are cited
- Worked example: Ledgerline restructures its comparison of approval methods
- How should heading levels be used?
- How do you write a good list?
- How do you build a useful table?
- How does structure help mobile readers?
- How do you structure a page for different readers?
- How do you fix structure on old pages?
- How do you agree on structure as a team?
- How does structure relate to accessibility?
- What about FAQ sections?
- How do you structure step-by-step instructions?
- How do you structure definitions and glossaries?
- What should you avoid?
- How do you test structure quickly?
- Common questions
- Related
- Sources
Checked on 31 October 2026. "Our view" marks MentionX opinion. Ledgerline is a fictional company used for illustration.
What does Google say about structure?
| Google says (Google) | Meaning |
|---|---|
| You don't need to write in a specific way just for generative AI search | No AI-only format |
| Perfectly semantic HTML isn't required; Google can understand imperfect HTML | Don't panic about markup |
| Semantic HTML is generally a good idea | Use real headings, lists and tables |
| Make it easy to distinguish main content from other elements | Clean page layout |
| No special schema.org markup needed for AI search | Structured data optional for AI |
Google's helpful content guidance lists page titles and headings that summarise a page's topic as part of its main content (Google).
How should you write headings?
Our view:
- One H1 that states the page topic
- H2s for main questions or sections, H3s beneath them
- Specific wording ("How much does Plan X cost?" not "Pricing")
- Don't skip levels for visual size; style with CSS
The W3C's accessibility tutorials explain that headings communicate page organisation and help screen-reader users navigate (W3C).
When should you use a list?
| Use a list for | Example |
|---|---|
| Ordered steps | Setup instructions |
| Parallel items | Features, requirements |
| Checklists | Pre-launch checks |
Use ordered lists (<ol>) when order matters and unordered lists (<ul>) when it doesn't. Our view: if each item needs a paragraph of explanation, use sub-headings instead.
When should you use a table?
| Use a table for | Avoid tables for |
|---|---|
| Comparing options on the same attributes | Layout |
| Specs, prices, limits | Long prose |
| Mapping one thing to another | Single-column lists |
Use real HTML tables with header cells (<th>), not images of tables. W3C's tables tutorial explains that header cells let assistive technology associate data with headers (W3C). Our view: a table rendered as an image or built from styled divs is harder for any system to read.
Do question headings help AI answers?
Our view: question headings mirror how people prompt engines, and the answer directly below gives a clean passage. But it's a readability practice, not a published ranking factor. Google says its AI systems understand synonyms and meaning, so you don't need to capture every phrasing (Google).
Which structure pitfalls should you watch for?
- Text in images with no text equivalent
- Headings used for styling, not structure
- Key facts hidden in accordions that require script to load (Google can process JavaScript content that isn't blocked, but test it (Google))
- Giant tables with merged cells and no headers
- Dozens of tiny sections (see content chunking)
What's a worked example?
Fictional example: a "Plans" page rewrite.
| Before | After |
|---|---|
| Pricing shown as an image | HTML table with plan, price, limits, as-of date |
| "Learn more" headings | "What's included in Pro?" |
| Feature list in a paragraph | Bulleted list |
| FAQ hidden behind a script widget | Visible questions and answers |
How do you check structure?
- View the page with CSS disabled. Does it still make sense?
- Use a heading-outline tool or browser extension to check heading order.
- Run an accessibility checker.
- Use Search Console's URL Inspection to see rendered HTML (Google).
Does structured data replace visible structure?
No. Google says structured data isn't required for generative AI search, though it remains useful for rich-result eligibility (Google). Markup must match visible content.
How much formatting is too much?
Our view: if a page is mostly bullets with no explanation, readers lose the reasoning, and so does any system summarising it. Aim for a mix: prose for explanation, lists for steps, tables for comparisons. A useful test is whether a newcomer could understand why, not just what.
Should every page look the same?
Our view: consistent templates help readers and maintenance, but don't force a table onto a page that doesn't compare anything. Choose formats by content type.
| Page type | Typical structure |
|---|---|
| Guide | Answer, question H2s, tables, checklist |
| Tutorial | Prerequisites, numbered steps, troubleshooting |
| Comparison | Summary, table, verdict by use case |
| Glossary | Definition, example, related terms |
Do AI engines read Markdown better than HTML?
Google says you don't need Markdown versions of pages to appear in Google Search, including its AI features (Google). Our view: publish good HTML; other systems that want Markdown can convert it. Keeping one well-structured source also avoids two versions drifting apart.
Checklist
- One H1, logical H2/H3 order
- Specific heading wording
- Lists for steps, tables for comparisons
- HTML tables with header cells
- No key text only in images
- Accessibility check passed
From MentionX data: which page types are cited
Method. Read-only aggregate queries over MentionX scans from 22 August to 29 October 2026 (UTC): 2,217 engine runs (2,154 completed) across 18 anonymised projects and six engines.
In the MentionX sample, articles and homepages are the URL types cited most often:
| Cited URL type | Share of 9,750 citations |
|---|---|
| Blog or article | 19.6% |
| Homepage | 10.0% |
| Review page | 2.7% |
| Docs | 2.6% |
| Pricing | 1.9% |
| Wikipedia | 1.6% |
Engines differ in how often they cite anything at all:
| Engine | Brand mentioned | Answers with no citations |
|---|---|---|
| Gemini | 47.3% | 50.7% |
| OpenAI | 42.9% | 30.2% |
| Perplexity | 31.5% | 4.1% |
| AI Mode | 31.3% | 12.6% |
| Copilot | 26.0% | 47.0% |
| DeepSeek | 24.0% | 99.0% |
Our view: the data tables in this section are an example of the point. Comparisons in a table are easy for readers to scan and for engines to extract, which is why tables suit data and lists suit steps.
Limits. A convenience sample of mostly B2B software projects, run through engine APIs, which can behave differently from the consumer apps. Perplexity, Copilot and DeepSeek figures come from a single day (26 October 2026), so treat them as a snapshot, not a trend.
Worked example: Ledgerline restructures its comparison of approval methods
Ledgerline is a fictional accounts-payable tool. Figures are illustrative.
Ledgerline's page comparing email approvals, spreadsheet tracking and automated workflows is one long block of text. Headings such as "Thinking about it" and "Another way" say nothing about the content.
An editor rewrites the headings as questions, such as "How do email approvals work?" and "Which method suits a growing team?" She moves the comparison into a table with the same rows for each method: setup effort, audit trail, speed and cost. The setup steps for automated workflows become a numbered list. Everything else stays as prose, because it explains reasons rather than listing items.
How should heading levels be used?
Use one H1 for the page title. Use H2s for main sections and H3s for sub-sections inside them. Don't skip levels, such as jumping from H2 to H4, and don't use headings only to make text bigger. A logical hierarchy helps screen reader users, readers who skim and systems that read the page's outline.
How do you write a good list?
Introduce the list with a sentence. Keep items parallel in form, such as all starting with a verb. Use numbered lists when order matters, such as steps, and bullets when it doesn't. Keep items short; if an item needs several sentences, it may belong in a paragraph instead.
How do you build a useful table?
Give the table a clear purpose, stated in the sentence before it. Use a header row with descriptive column names. Keep each cell short and use the same units throughout. Avoid merged cells and nested tables, which are hard to read on mobile and for assistive technology. Make sure the table is real HTML, not an image.
How does structure help mobile readers?
Most readers skim on small screens. Clear headings let them find the right section quickly, and short paragraphs are easier to read. Wide tables can be hard to read on mobile, so keep columns few or make tables scroll horizontally.
How do you structure a page for different readers?
Start with a short answer for readers in a hurry. Follow with detail for those who want it. Put reference material, such as tables and specifications, where it's easy to find. A table of contents helps on long pages.
How do you fix structure on old pages?
Start with the most important pages. Rewrite vague headings, split long sections and turn comparisons into tables. Check that heading levels are logical. Don't change URLs or remove useful content while restructuring.
How do you agree on structure as a team?
Add structure rules to your style guide: heading levels, when to use lists and tables and how to write section openings. Include examples. Build templates in your CMS for common page types. Our view: consistent structure across a site helps readers learn where to look, and it makes reviews faster.
How does structure relate to accessibility?
Proper headings, lists and tables are part of accessible design. Screen readers let users jump between headings and announce lists and table headers. Using real HTML elements, rather than styled text, makes pages usable for more people and is often required by accessibility standards.
What about FAQ sections?
FAQ sections suit short questions with short answers. Use them for common follow-up questions at the end of a page, not as a substitute for proper sections. Keep answers to a few sentences and link to detail elsewhere.
How do you structure step-by-step instructions?
Give each step its own numbered item, starting with a verb. Put one action in each step. Add the expected result after steps where readers might be unsure whether it worked. Use screenshots for steps that involve finding something on screen, with alt text that names the screen and setting. If a step has options, use a short sub-list or a table rather than a long sentence.
How do you structure definitions and glossaries?
Start with a one-sentence definition that names the term and says what it is. Follow with an example and any important distinctions from related terms. On glossary pages, give each term its own heading or anchor so it can be linked directly.
What should you avoid?
Avoid headings that are clever but unclear, long walls of bullets, tables used for layout and bold text used instead of headings. Avoid repeating the same heading on one page, which confuses readers and makes anchors clash. Avoid hiding key content in accordions without checking that it's in the page's HTML.
How do you test structure quickly?
Turn off page styles in your browser or use a reader view. If the page still reads clearly, with headings, lists and tables in sensible order, the structure is sound.
Common questions
Should every heading be a question? Not always; question headings work well for informational pages, but labels can suit reference sections.
Do tables help AI engines? They make comparisons easy to read and extract; that helps readers and is likely to help engines.
How many headings should a page have? As many as it has distinct sections; avoid a heading every few lines.
Related
Sources
- Google, AI optimization guide; Creating helpful content; JavaScript SEO basics; Search Console
- W3C WAI, Headings tutorial; Tables tutorial
All accessed 30 Oct 2026.
Questions
Do LLMs prefer content with tables and lists?
No engine publishes a format preference. Google says there's no special format needed for AI search and its systems understand pages without perfect markup, but clear structure helps readers and screen readers.
Should I use semantic HTML?
Google says perfectly semantic HTML isn't required but it's generally a good idea, as it helps users such as screen-reader users navigate a page.
Are question headings better?
They match how people ask questions and make sections easy to scan. There's no published evidence they're required by any engine.