How to Use Semantic HTML for AI Readability

Why it matters

HTML elements carry meaning, not just appearance. An <article>, an <h2>, a <ul>, a <table> each tell a parser what role that content plays — main content, a heading, a list, tabular data. A div-heavy page where headings are just styled <span>s and "tables" are stacks of <div>s looks identical to a human but is structurally invisible to a machine: the model has to infer structure from CSS classes it may not even receive.

Semantic HTML is the foundation the rest of Phase 2 rests on — your heading hierarchy (2.3) and your lists/tables/FAQ blocks (2.4) only count if they're expressed in the real elements. It also pairs with server-side rendering (Phase 1.2): the semantics have to be in the raw source, not assembled by JavaScript.

It matters more as AI assistants start acting on pages: browsing agents navigate through the accessibility tree, so real buttons, labelled form fields and landmarks are what let an agent find and use your content. Mark dates up with <time datetime="2026-10-13"> and images with <figure> / <figcaption> and descriptive alt text.

What good looks like

Every region of the page is wrapped in the element that describes its role:

• Main content sits in <article> / <section>, with <header>, <nav>, <main>, and <footer> landmarks around it.
• Headings are real <h1>–<h3>, lists are <ul>/<ol>, tabular data is a real <table>.
• Core content does not depend on class-based <div> styling to convey structure.
• The semantic structure is present in the raw HTML source (Phase 1.2), not injected later.
• The markup validates and elements are used for meaning, not for their default styling.

Step by step

1. Wrap the main content in article and section Put the page's primary content in an <article> (a self-contained unit) and divide it into <section>s. Use <header>, <nav>, <main>, and <footer> as page landmarks so the model can tell content from chrome.
2. Use real heading and list elements Headings are <h1>–<h3>, never bold <span>s or sized <div>s. Lists are <ul>/<ol> with <li> items. The visual result can be anything CSS makes it; the element is what carries meaning.
3. Use table elements for tabular data Real comparisons and data go in <table> with <thead>, <th>, and <tbody> — not CSS grid made of divs. This is what lets a model read rows and columns as relationships (and keeps the extraction benefits described in Phase 2.4).
4. Replace div-based structure with landmarks Audit core content for "div soup". Where a <div class="title"> is really a heading, or <div class="row"> is really a table row, swap in the semantic element. Keep <div>/<span> for pure styling hooks only.
5. Verify structure survives in the source View Source (or curl) the page and confirm the semantic tags are actually in the response — not generated by JavaScript at runtime (Phase 1.2). Run it through an HTML validator to catch nesting errors that break parsing.

Worked examples

<div class="post">
  <div class="title">What is GEO?</div>
  <div class="text">GEO is...</div>
  <div class="row">
    <div>Benefit</div><div>Outcome</div>
  </div>
</div>

<article>
  <h2>What is GEO?</h2>
  <p>GEO is...</p>
  <table>
    <thead><tr><th>Benefit</th>
      <th>Outcome</th></tr></thead>
  </table>
</article>

<body>
  <header>…brand, masthead…</header>
  <nav>…primary navigation…</nav>
  <main>
    <article>
      <h1>Generative Engine Optimisation</h1>
      <section><h2>What is GEO?</h2> …</section>
    </article>
  </main>
  <footer>…contact, legal…</footer>
</body>

Common mistakes