When a language model reads your website, it does not see what your visitors see. There is no CSS, no layout, no color, no whiteboard of rendered pixels. What it sees is closer to what a screen reader sees: a tree of elements, each one declaring what it is and how it relates to everything around it. A heading says "I am a heading." A navigation landmark says "skip me if you want the content." An article element says "this is the thing you came here for."
When those declarations are missing, when every element is a <div> with a class name that means nothing outside your codebase, the model has to guess. It guesses based on position, on visual heuristics reconstructed from token patterns, on the hope that your markup follows conventions it has seen before. Sometimes it guesses right. Often enough, it does not.
That gap between guessing and knowing is the reason semantic HTML has become important again, not just for the accessibility audience that has argued for it for two decades, but for anyone who wants their content to be understood, retrieved, and cited by the machines that increasingly mediate how people find information.
The short version
Semantic HTML is the practice of using HTML elements for their meaning rather than their appearance: <nav> for navigation, <article> for self-contained content, <h2> for a second-level heading, <aside> for tangential information. The alternative, sometimes called "div soup," uses generic containers (<div>, <span>) styled with CSS classes to look correct visually while communicating nothing about structure to any system that reads the markup directly.
For most of the web's history, the practical audience for semantic HTML was small: screen reader users, search engine crawlers, and the developers who maintained the code. The arguments were real (accessibility, maintainability, SEO) but the consequences of ignoring them were diffuse. A site built entirely out of <div> elements could look identical to one built with semantic elements, rank similarly in search results, and function the same way for sighted mouse users.
That calculus has changed. A new class of HTML consumers has arrived: large language models, answer engines (ChatGPT search, Perplexity, Google AI Overviews), retrieval-augmented generation systems, and the growing ecosystem of tools that parse web content for AI applications. These systems read HTML in ways that make semantic structure load-bearing rather than optional. The structural cues that screen readers have relied on for years are now the same cues that determine whether an answer engine can extract, trust, and cite your content.
How browsers build the tree that machines read
To understand why semantic HTML matters to AI systems, you need to understand the accessibility tree: a parallel representation of the page that browsers build from the DOM (Document Object Model, the in-memory structure created when a browser parses HTML).
The DOM represents every element, attribute, and text node on the page. The accessibility tree is a simplified version that strips away visual presentation and exposes only semantic meaning. When you write <nav aria-label="Main navigation">, the accessibility tree creates a node that says: "this is a navigation landmark called Main navigation." When you write <div class="nav-wrapper">, the accessibility tree sees a generic container with no declared role, no label, no semantic meaning.
Screen readers like VoiceOver and NVDA consume the accessibility tree, not the rendered page. That is why a beautifully designed navigation bar built entirely from styled <div> elements can be invisible to a blind user: the accessibility tree has nothing meaningful to announce.
LLMs and answer engines face a structurally similar problem, though they solve it differently. They do not consume the accessibility tree directly (that structure exists only in the browser's rendering engine). Instead, they parse the raw HTML markup, and the semantic elements in that markup serve the same function: they declare what things are. A <h1> followed by <h2> elements creates a parseable outline. An <article> element identifies the primary content block. A <nav> element signals "this is navigation infrastructure, not the content the user is looking for."
When a retrieval system is deciding which chunk of a page to extract as an answer to a user's question, these structural declarations are not decorative. They are the difference between confident extraction and a best-guess heuristic that may pull a cookie banner, a sidebar promotion, or a navigation menu instead of the actual answer.
Three eras of HTML structure
The web has passed through three distinct structural periods, each defined by how HTML relates to meaning.
Figure 1. Three eras of HTML, each redefining the relationship between markup and meaning.
The presentational era (roughly 1995 to 2005) fused structure and appearance. Layouts were built with <table> elements. Text styling used <font> tags with explicit color and size attributes. Bold text was <b>, not <strong>, because the question was "how should this look?" rather than "what does this mean?" The markup described a visual layout; any meaning was incidental.
The semantic era (roughly 2005 to 2020) separated structure from presentation. CSS took over visual styling, and HTML was freed to describe meaning. New elements arrived with HTML5: <nav>, <main>, <article>, <aside>, <header>, <footer>, <section>, <figure>, <figcaption>, <time>, <mark>. WAI-ARIA (Web Accessibility Initiative, Accessible Rich Internet Applications) added roles, states, and properties for interactive widgets that native HTML could not express.
This era was driven largely by accessibility advocacy and web standards organizations. The argument was principled: the web should be usable by everyone, and structured markup is how you achieve that. The argument was also correct. Still, adoption was uneven. The semantic elements existed in the spec; whether developers used them depended on awareness, tooling, and incentive structures that often rewarded speed over structure.
The AI-readable era (now) has shifted the incentive structure. The same semantic cues that accessibility advocates fought for are now what answer engines, LLMs, and retrieval systems depend on to understand web content. A heading hierarchy is not just a screen reader convenience; it is the outline that a retrieval system uses to chunk and index your content. An <article> element is not just a code organization choice; it is the signal that tells an AI system where the substantive content begins and where the boilerplate ends.
The irony is sharp: the accessibility community spent two decades arguing that semantic HTML was important, with limited uptake. The arrival of AI-powered search and retrieval may accomplish what advocacy alone could not, simply by making the consequences of non-semantic markup commercially visible.
What machines actually see (and what they miss)
Consider two versions of the same content. The first uses semantic HTML:
<article>
<h1>Why PDFs Become Inaccessible</h1>
<p>The PDF format stores content as a stream of drawing instructions...</p>
<h2>How reading order diverges from visual order</h2>
<p>When a PDF is created, the order in which content is drawn...</p>
</article>The second uses div soup:
<div class="content-wrapper">
<div class="title-large">Why PDFs Become Inaccessible</div>
<div class="body-text">The PDF format stores content as a stream...</div>
<div class="subtitle">How reading order diverges from visual order</div>
<div class="body-text">When a PDF is created, the order in which...</div>
</div>To a sighted user, these can look identical. To a machine parsing the HTML:
Figure 2. How browsers and machines interpret the same page differently.
The semantic version declares a clear hierarchy. The <article> boundary identifies the content block. The <h1> and <h2> elements create a two-level outline. A retrieval system can confidently extract the content, understand its structure, and attribute the heading hierarchy.
The div-soup version offers only class names as clues. The class title-large probably means a heading, but "probably" requires inference. The class subtitle could be a subheading, a byline, a deck, or a caption. The class content-wrapper might contain the article, or it might contain the article plus a sidebar, a related-posts widget, and a newsletter signup form. The machine can guess, and modern models are good at guessing, but guessing introduces error at every ambiguous node, and those errors compound across a page with dozens of elements.
What semantic HTML does not solve
Semantic structure is necessary for machine readability. It is not sufficient.
Content quality operates on a separate axis entirely. A page with perfect semantic structure and nothing original to say will not be cited by answer engines, because there is nothing worth citing. The structural layer makes content parseable; the editorial layer makes it valuable. Confusing the two is a common mistake, especially among developers who treat semantic HTML as an optimization technique rather than a structural foundation.
Structured data (JSON-LD, microdata, RDFa) addresses yet another layer. Semantic HTML tells a machine what the structural elements of a page are. Structured data tells a machine what the entities are: this is an Article, by this Person, published by this Organization, on this date. The two systems are complementary, not interchangeable. A page can have excellent semantic HTML and no structured data, or extensive structured data embedded in non-semantic markup. The strongest pages have both.
ARIA (Accessible Rich Internet Applications) fills a different gap: it provides semantic information for interactive widgets and dynamic content that native HTML elements cannot express. A custom dropdown, a tab panel, a live-updating notification region: these need ARIA roles and states because no native HTML element captures their behavior. ARIA is not a replacement for semantic HTML; the first rule of ARIA, stated in the W3C specification itself, is "do not use ARIA if you can use a native HTML element."
What to actually do
The practical implications are not complicated, though they require discipline.
Use semantic elements for their meaning. <nav> for navigation blocks. <main> for the primary content area (one per page). <article> for self-contained content. <aside> for tangentially related content. <header> and <footer> for introductory and concluding content within their parent. <section> for thematic groupings that have a heading. If the element you need does not exist in HTML, use a <div> with an ARIA role; do not repurpose a semantic element for a meaning it does not carry.
Build a heading hierarchy that works as a table of contents. Start with one <h1> (the page title). Use <h2> for major sections, <h3> for subsections, and so on. Do not skip levels (going from <h2> to <h4> without an <h3>) unless you have a specific reason. The heading hierarchy is the single most important structural signal for both screen readers and content-extraction systems.
Use lists for things that are actually lists. Navigation items, feature sets, step-by-step instructions, comparison points: these should use <ul>, <ol>, or <dl> (description list). A list element tells a machine both the grouping relationship and the count. A series of <div> elements styled to look like a list communicates neither.
Do not use ARIA to compensate for non-semantic markup. Adding role="navigation" to a <div> works, technically, but it is strictly worse than using <nav>. The native element carries its semantics inherently; the ARIA role has to be maintained manually and can be removed, overridden, or applied incorrectly. Use ARIA for cases where no native element exists.
Test with the accessibility tree inspector. Every major browser's developer tools can show the accessibility tree. Chrome: DevTools, Elements, Accessibility pane. Firefox: DevTools, Accessibility tab. Safari: Web Inspector, Node, Accessibility. What you see in the accessibility tree is a reasonable approximation of what a machine reading your HTML will understand about your page's structure. If the tree is flat, generic, or confusing, your markup needs work. Browser extensions like Silktide's free toolbar can surface the same structural issues (missing landmarks, broken heading hierarchy, absent labels) without requiring you to interpret the raw tree, which makes them a useful complement for quick checks during development.
What we do not know yet
Several important questions remain open.
How heavily do different LLMs weight semantic structure versus raw text content? The answer almost certainly varies by model, by application (summarization versus retrieval versus generation), and by how the model was trained. There is no published benchmark that isolates the effect of semantic HTML on LLM content extraction accuracy. That experiment would be worth running.
Will AI systems eventually infer structure from visual rendering, making HTML semantics less important? Multimodal models can already "see" a page as an image and identify headings, navigation, and content areas from visual cues. If visual inference becomes reliable enough, semantic HTML might become less critical for AI applications (though it would remain essential for accessibility). The current trajectory suggests that text-based HTML parsing will remain the primary method for content extraction at scale, because it is cheaper, faster, and more reliable than rendering and visually parsing every page. That assumption is worth re-examining as multimodal models improve.
There is an uncomfortable question about AI-generated code: if an increasing share of websites are built by AI coding tools, and those tools produce less semantic markup than human developers (a pattern several early studies suggest, though the evidence is still sparse), the web could become simultaneously more dependent on semantic structure for AI retrieval and less likely to contain it. That tension deserves more attention than it currently receives.