Semantic HTML: why headings are not just big text
HTML tells search engines, screen readers and AI systems what each part of a page is. What semantic markup means and why page builders get it wrong.
The short answer
A web page is text and structure, dressed in styling. The structure lives in the HTML, and semantic HTML means using the element that says what each part is: a heading element for a heading, a list for a list, a button for a button, a link for a link, a navigation region for the menu, a main region for the content. People see the styling. Nearly everything else that reads your page reads the structure: search engines, AI systems, screen readers, reader modes, translation tools, browsers. A page built from styled boxes with no meaning looks right and reads as nothing, which is what most page builders and quick templates produce.
Who reads the structure
| Reader | What it uses | What it gets from a page of styled boxes |
|---|---|---|
| Screen reader users | Headings to navigate, landmarks to jump, lists to count, buttons to activate | A wall of undifferentiated text |
| Search engines | Heading outline, lists, tables, emphasis, links, to understand what the page is about | Weaker understanding, poorer snippets |
| AI systems answering questions | Structure to extract answers, headings to locate sections | Less citable content |
| Browsers | Free keyboard behaviour for buttons and links, form semantics, reader mode | Broken keyboard access, no reader mode |
| Your own future developers | Meaning they can build on | Guesswork |
What correct looks like
- One top-level heading per page that says what the page is, then a proper outline: sections as level two, subsections as level three, no skipped levels, levels chosen by position in the outline, never by size.
- Real lists for lists of things, real tables for tabular data with header cells, real quotes for quotations.
- Buttons for actions, links for navigation. A clickable box that is neither is invisible to keyboards and assistive technology.
- Landmark regions: header, navigation, main, footer, marked as such.
- Images with alternative text that says what they convey, or marked decorative when they convey nothing.
- Form fields with associated labels, and errors connected to their fields.
- Language declared, so screen readers and translation tools pronounce and process it correctly.
Why component-based builds get it right by default
In a component-based site, the heading component knows its level from where it sits, the button component renders a real button, the navigation component is a landmark, the card component puts its title in the outline. Authors write content; structure is produced by the components. It is the difference between asking every editor to remember the rules and building the rules in once.
What this means for you
Your page has more machine readers than human ones, and machines read structure. Insist on semantic HTML: one correct heading outline, real lists, buttons and links, landmarks, labelled fields, alternative text. On a component-based build this is the default and costs nothing; on a page-builder site it is a recurring fight. It is the quiet foundation under accessibility, search visibility and being cited by AI systems at the same time.
Frequently asked questions
The page looks fine. Why does the markup matter?
Because most readers of your page are not people looking at it. Search engines, AI systems answering questions, screen readers, reader modes, browser features and translation tools all read the HTML, and they understand a heading only if it is marked as one. A page of styled boxes is a picture to them.
How many top-level headings should a page have?
One, describing the page, with sections under it as second-level headings and subsections as third, without skipping levels. It is an outline, like a document's table of contents. Choosing heading levels for their size rather than their place in the outline is the most common structural mistake on the web.
Can we fix this on an existing page-builder site?
Partly, block by block, and it tends to regress as new pages are added by people picking whatever looks right. A component-based build enforces it: the heading component knows its level, the button component is a button, the navigation is a landmark. Structure becomes the default rather than a per-page effort.
Sources
- MDN: HTML, a good basis for accessibility (accessed 2026-09-11)