When to Use Semantic HTML

The theory of semantic HTML is straightforward enough. Use elements for what they mean, not just for how they look. The practice is where it gets more interesting, because HTML gives you dozens of elements and not all of them have obvious use cases. When exactly should you reach for an article element rather than a section? When is a div actually the right choice? When does a button differ from an anchor link, and does it matter?

These decisions come up constantly in web development, and getting them consistently right is one of the things that separates a cleanly built site from one that looks identical in the browser but reads very differently to search engines, AI systems and screen readers. This article gives you a decision-based framework for the elements you will encounter most often.

The Decision You Are Always Making

Every time you add an element to an HTML document, you are making a claim about what that content is. Not how it looks. What it is. A heading element claims that this is a heading for the content that follows. A list element claims that this is a collection of related items. A nav element claims that this is navigation.

The question to ask before reaching for any element is: does this element accurately describe what this content is? If yes, use it. If not, either find an element that does, or use a generic div or span and style it yourself.

That is the whole framework. Everything below is an application of it.

Heading Elements: h1 Through h6

Use a heading element when the content is genuinely a heading, a title for the section or content that follows it. Not when you want text to be large. Not when you want text to be bold. When the content is a heading.

The h1

One per page. It describes what the page is primarily about. On a blog post, it is the post title. On a service page, it is the name of the service. On a homepage, it is the primary statement of what the business does. If you find yourself wanting more than one h1, the question to ask is whether you actually have two separate pages that have been combined into one.

h2 through h6

These create the document outline beneath the h1. Use h2 for major sections. Use h3 for subsections within those. Avoid skipping levels, so no jumping from h2 to h4. The heading hierarchy should reflect the actual structure of the content, not the visual size you want the text to be.

If you want smaller text that is styled like a heading but does not represent a structural section of the page, do not use a heading element. Style a paragraph or a span instead.

Paragraph Element: p

Use p for prose. Blocks of written content. Body text. Anything that constitutes a paragraph of writing.

Do not use p for one-word labels, captions, button text or standalone links. These are not paragraphs. A p element carries an implicit meaning that its content is a block of written text, and using it for interface labels or single words distorts that meaning.

List Elements: ul, ol and dl

Use ul for unordered collections where the order does not matter. Ingredients in a recipe. Features of a product—a set of related links. The choice between ul and ol is not about appearance; it is about whether sequence is meaningful.

Use ol when order genuinely matters. Numbered steps in a process. Ranking. Instructions where doing step three before step two would cause a problem.

Use dl for definition lists. A term paired with its definition. A glossary. A list of metadata where each item has a name and a value. This element is underused. When you have content that is structured as name-value pairs or term-description pairs, dl is almost always the right choice.

None of these should be used for visual indentation or visual bullet points that are not actually lists. If a series of lines of text is not genuinely a list of related items, do not mark it up as a list.

Anchor vs Button: The Most Commonly Confused Pair

This one matters more than most people realise, for accessibility, for keyboard navigation, and for how assistive technologies communicate the interface to users who cannot see it.

Use an anchor element (a) when

The action navigates somewhere. Clicking it takes you to a different page, a different URL, a different section of the same page via an anchor, or opens a file for download. The href attribute should always be present and should point to a real destination.

<a href=”/services/”>View our services</a>

<a href=”#contact”>Jump to contact form</a>

Use a button element when

The action does something without navigating, submitting a form, opening a modal, toggling a menu, or triggering a JavaScript interaction. If the click causes something to happen on the page rather than taking the user somewhere else, it is a button.

<button type=”submit”>Send message</button>

<button type=”button” aria-expanded=”false”>Open menu</button>

The common mistake is using a div or a span styled to look like a button, with a JavaScript click handler attached. Visually identical. Functionally broken for keyboard users, who expect to be able to activate a button with the Enter or Space key, and for screen reader users, who need to know whether a control is a link or a button to understand what activating it will do.

Semantic Layout Elements

header

The introductory content of a page or section. At the page level, this typically wraps the site logo, the main navigation, and any top-of-page content. You can also use header inside an article or section element to mark its own introductory content. Not every page needs a header element, but if you have introductory content at the top of a page or section, this is the right element for it.

nav

A block of navigation links. The main site navigation. A breadcrumb trail. A table of contents. Pagination. Not every group of links is a nav. A small collection of footer links may not warrant it. But any significant navigation structure that helps users find their way around should be marked with nav.

main

The primary content of the page. Use it once per page, wrapping everything that is the actual reason someone is on that page. The header, footer, navigation and sidebars sit outside main. The article, the service information, the contact form, the product listing: that is main.

article

A self-contained piece of content that could stand on its own or be syndicated independently. A blog post. A news article. A product listing in a shop. A comment. The test is: could this content be lifted out of the page and republished somewhere else and still make sense? If yes, article is appropriate.

section

A thematic grouping of content within a page. Not a replacement for div. A section should have a heading that describes what it contains. If you cannot name the section with a heading, it is probably not a section in the semantic sense; it is just a visual grouping, and a div is fine for that.

aside

Content that is tangentially related to the main content but not central to it. A sidebar. A pull quote. A related articles block. An author biography. An aside is not simply content on the side of the page. It is content that supplements rather than constitutes the main content.

footer

The closing content of a page or section. Contact details, copyright information, secondary navigation, legal links. Like header, footer can be used within article or section elements as well as at the page level.

When div and span Are the Right Answer

Here is something the discussion of semantic HTML sometimes obscures: div and span are not wrong. They are the correct choice for any situation where no semantic element accurately describes the content.

You need a wrapper to apply CSS to a group of elements for layout purposes. No semantic element describes that purpose. Use a div.

You need to style a word within a paragraph. No semantic element applies. Use a span.

The mistake is not using div and span. The mistake is using them when a semantic element would be more accurate, or building entire layouts from nothing but divs when header, nav, main, article and footer exist precisely to give those structures meaning.

A Quick Decision Guide

• Is this content a heading for what follows? Use h1 to h6 at the appropriate level.
• Is this a block of prose? Use p.
• Is this a collection of related items where order does not matter? Use ul and li.
• Is this a collection where order matters? Use ol and li.
• Is this name-value or term-description content? Use dl, dt and dd.
• Does clicking this navigate somewhere? Use a with an href.
• Does clicking this trigger an action without navigating? Use button.
• Is this introductory content at the top of a page or section? Use header.
• Is this significant navigation? Use nav.
• Is this the primary content of the page? Use main.
• Is this a self-contained piece of content that could stand alone? Use article.
• Is this a themed group of content with a heading? Use section.
• Is this supplementary to the main content? Use aside.
• Is this closing content for a page or section? Use footer.
• Is this a layout wrapper with no semantic meaning? Use div.
• Is this an inline wrapper with no semantic meaning? Use span.

Frequently Asked Questions

Can I use multiple article elements on the same page?

Yes. A page listing blog posts might wrap each post summary in an article element. A comments section might wrap each comment in one. The key is that each instance of article should be genuinely self-contained content, not just a repeated visual component that happens to look similar.

What is the difference between section and div?

A section has semantic meaning. It represents a thematic grouping of content that would benefit from appearing in a document outline, typically because it has a heading. A div has no semantic meaning. It is a generic container used for styling and layout when no semantic element applies. If you are using a section element but do not have a heading for it, that is a signal you might want a div instead.

Does it matter if I use the wrong element visually?

Not visually. The wrong element looks identical to the right one in a browser. It matters to crawlers, which use element meaning to understand content structure. It matters to screen readers, which use element roles to communicate the interface to users who cannot see it. It matters to AI systems, which extract information more reliably from correctly structured documents. The visual result is the least useful measure of whether your HTML is correct.

Should I use semantic HTML in email templates as well as web pages?

Email HTML is a different environment with much weaker support for modern HTML and CSS. Many email clients strip semantic elements or ignore them entirely. The pragmatic answer for email is to follow email development conventions, which tend to be table-based for layout compatibility, rather than applying web HTML standards directly. The semantic HTML guidance in this article applies to web pages.

How do I know what element to use for something not on this list?

The HTML specification at html.spec.whatwg.org is the authoritative reference. MDN Web Docs at developer.mozilla.org is more accessible and equally reliable. For any element you are uncertain about, checking either of those for the definition and the intended use case will give you a clear answer. The definition always comes back to the same question: what does this content mean, not how should this content look.

Want Your Site’s HTML Reviewed?

A review of your HTML structure often turns up patterns that are invisible in the browser but affect how your site is read, indexed, and cited. Get in touch if you would like to know where your site stands.