Semantic HTML is the practice of building web pages with HTML elements that describe what each part of the content is, such as a heading, a list, a navigation menu, the main article or a button, rather than wrapping everything in generic boxes styled to look right. It gives browsers, assistive technology and search engines a reliable map of the page.
How semantic HTML works
HTML has two kinds of element. Generic ones, <div> and <span>, carry no meaning; they are containers. Semantic ones say what their content is. <header>, <nav>, <main>, <article>, <section>, <aside> and <footer> describe regions of a page. <h1> to <h6> mark a hierarchy of headings. <ul>, <ol> and <table> mark lists and tabular data. <button> and <a> mark actions and links, <figure> ties an image to its caption, and <time> marks a date.
Two pages can look identical in a browser while being built very differently. One uses a real <h2> for each section heading; the other uses a <div> with large bold text. A sighted visitor notices nothing, but a screen reader user moving through the page by headings finds none on the second version, and a search engine has to guess the structure from the styling.
Semantic HTML is not the same as structured data. Schema markup adds explicit labels in a separate block of code, while semantic HTML is the structure of the visible content itself. The two work well together.
Why it matters
Accessibility is the clearest reason. Screen readers, voice control and keyboard navigation rely on semantic elements to announce headings, jump between regions and recognise buttons. Meeting WCAG starts here, and in the UK it is more than good practice: the Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and public sector bodies have specific website accessibility regulations to meet.
For search, Google has said it gives no ranking boost simply for using particular HTML5 elements, and it copes with untidy code. Clear structure still helps it tell main content from navigation and boilerplate, see how sections relate, and lift passages for featured snippets and AI answers. Links built as real <a href> elements are crawlable; links built as click handlers on a <div> may never be found.
Common mistakes
- Choosing heading levels for their size rather than their place in the outline, or skipping levels.
- Several <h1> elements added by the theme, for the logo, the page title and a banner.
- Buttons and links made from <div> or <span> elements with click scripts, which keyboards and crawlers cannot use.
- Tables used for page layout, or real data shown as a grid of boxes with no table markup.
- Page builders that wrap every element in layers of anonymous containers, burying the main content.
- No <main> element, so assistive technology cannot skip straight past the menu.
How to act on it
Start with templates rather than individual pages, because fixing a template fixes every page that uses it. Use your browser’s developer tools or a heading outline extension to check that each page has one H1 and a logical run of H2s and H3s. Tab through a page using only the keyboard: every link and button should be reachable and clearly highlighted when focused. Then run the accessibility audit in Lighthouse to catch missing labels and landmarks.
When you commission a new site or theme, ask for semantic markup in the brief and test it before launch rather than after. Reviewing templates for crawlable links, heading structure and clean markup is part of my technical SEO service.