Semantic HTML
Last updated
Semantic HTML is the use of HTML elements that describe the meaning of content, not just how it should look. A <div> is a generic container with no inherent meaning. An <article> tells the browser and assistive technology that this region is a standalone piece of content. An <h2> declares the start of a new subtopic. The elements themselves carry meaning.
This is distinct from structured data and schema markup. Those add an explicit vocabulary layer on top of content. Semantic HTML works through the document structure itself.
How does semantic HTML differ from schema markup?
Both serve machine interpretation, but through different mechanisms.
Schema markup is a separate layer of explicit labelling: a JSON-LD block in a <script> tag that declares “this page is an Article, authored by this Person, published on this date.” It lives outside the visible content and is processed by systems that read it as structured metadata.
Semantic HTML is built into the document structure itself. There is no separate block to add. You choose <article> instead of <div>, <h2> instead of a styled paragraph, <nav> instead of an unsemantic container. The elements communicate what each part of the page is for, through the HTML that the content already lives in.
The practical difference: schema labels entities and their properties for search engines; semantic HTML defines the document boundaries and hierarchy that browsers and assistive technology read directly. Neither replaces the other.
Why does semantic HTML matter for traditional SEO?
Three reasons, none of them a direct ranking factor.
Crawlability. Semantic structure gives Googlebot explicit boundaries between navigation, primary content and supplementary content instead of leaving it to infer them. Google says it infers them well: its AI optimisation guide tells publishers that “it’s not required to have perfectly semantic HTML (the web in general is not valid HTML, and Google can understand it)”, while still calling it “generally a good idea” because it helps screen readers parse and navigate a page.1 Its SEO Starter Guide says the same of heading order: “fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order.”2
Accessibility. This is the benefit with evidence behind it. Screen readers rely on semantic elements to navigate: jumping between <h2> headings, skipping to <main>, identifying <nav>. In WebAIM’s 2024 survey of 1,539 screen reader users, 71.6% said navigating through headings is their first method for finding information on a long page, and a further 3.7% go by landmarks and regions.3 Remove the elements and that navigation stops working.
Rendering. Semantic elements carry browser defaults that keep content readable even when CSS fails to load. That is resilience, not a ranking signal.
Does semantic HTML matter for AI search?
Less than the advice around it suggests, and the only platform that has said anything says not to worry about it.
Google’s guide to its AI features gives the same instruction as its search guidance: “When it comes to semantic HTML, focus on human readability and don’t worry about perfect code.” It lists “chunking” among the things not to do: “there’s no requirement to break your content into tiny pieces for AI to better understand it”, because its systems “are able to understand the nuance of multiple topics on a page and show the relevant piece to users”.1
That is the only first-party statement on the subject. None of Google’s, Microsoft’s or OpenAI’s documentation says their AI systems read heading tags or landmark elements when retrieving a page for an answer, and no independent study has isolated the effect. The widely repeated claim that a heading boundary is a “retrieval boundary” has no platform documentation behind it. Write clear headings because readers and screen readers use them, and treat any AI benefit as unconfirmed.
What are the key semantic HTML elements?
| Element | What it communicates |
|---|---|
<h1> | The primary topic of the page. HTML permits more than one, and heading hierarchy covers why a single H1 is still the better convention. |
<h2> – <h6> | Subtopic hierarchy. H2 = major subtopic; H3 = section within an H2. Do not skip levels: screen readers navigate by the sequence. |
<article> | A standalone, self-contained piece of content: a blog post, a news item, a product description. |
<section> | A thematic grouping within a larger piece. Should have a heading. |
<main> | The primary content region of the page. One per page. Excludes navigation, header, footer. |
<nav> | Navigation: primary, secondary, breadcrumb. Helps systems identify what is not primary content. |
<aside> | Supplementary content tangentially related to the main content: sidebars, callouts, related links. |
<header> / <footer> | Page or section boundary markers. |
<figure> / <figcaption> | Self-contained media with a caption. Tells parsers that the image and its description belong together. |
Common mistakes
Skipping heading levels. Going from <h2> to <h4> breaks the sequence screen readers navigate by. Google says out-of-order headings do not matter to Search,2 so this is an accessibility defect rather than a ranking one.
<div> for everything. A page built entirely from <div> containers gives assistive technology nothing to navigate by and leaves Google to infer boundaries it could have been told. Google says it manages that inference;1 a screen reader cannot.
No landmark elements. Without <main> and <nav>, a screen reader user cannot jump straight to the content, and Google has to infer which region is the page’s substance. It usually can; the accessibility loss is the certain one.
<strong> for structure, not emphasis. <strong> marks important text within a flow, not headings or section titles. Using it in place of heading elements removes the hierarchical signal.
<table> for layout. Tabular elements imply data relationships between rows and columns. Used for visual layout, a screen reader announces them as data and reads the cells in an order that makes no sense for the design.
Frequently asked questions
Does semantic HTML improve rankings directly?
No. Google says it is not required and that its systems understand imperfect HTML.1 The benefits are accessibility, resilience when CSS fails, and markup that is easier to maintain. You will not see a rankings lift from adding <article> tags to a page that is otherwise unchanged.
Is semantic HTML the same as structured data?
No. Structured data is the concept of organising content for machine interpretation. Semantic HTML is one way to achieve that through native HTML elements. Schema markup (JSON-LD) is another way: it adds an explicit vocabulary layer. They are complementary, not the same thing.
Does it help with Google AI Overviews specifically?
Google says no special treatment is needed. Its AI optimisation guide tells publishers to “focus on human readability and don’t worry about perfect code”, and that there is no requirement to chunk content for AI.1 Nothing in its documentation says AI Overviews read heading tags or landmark elements.
How do I audit semantic HTML on my site?
Open any page and inspect the heading hierarchy: does it run H1 → H2 → H3 without skips? Check for <main>, <nav>, and <article> or <section> elements on content pages. Accessibility tools (Axe, Lighthouse’s accessibility audit) flag most semantic HTML violations alongside WCAG issues.
