Semantic HTML tags

Let's start with a bowl of div soup

If you've ever inherited someone else's markup, you've probably seen something like this:

<div class="header">
  <div class="nav">...</div>
</div>
<div class="main">
  <div class="article">...</div>
  <div class="sidebar">...</div>
</div>
<div class="footer">...</div>

Every block is a <div>, and the class names are doing all the work of telling a human "this is the nav" or "this is the article." Visually it renders just fine, because the browser only cares about the CSS, not what the tag is called. But here's the catch: the rendering engine understands styles, but that doesn't mean everything else reading this HTML understands the structure. Screen reader users, search engine crawlers, and even you six months from now, coming back to maintain this — they all have to guess when everything is a <div>. There's a name for this: div soup. Everything gets dumped into the same tag, and any sense of meaning gets diluted away.

That's exactly what semantic HTML is for: replacing meaningless <div>s with tags whose names actually say what they're for.

So what makes a tag "semantic"?

A tag is semantic when its name itself communicates the role of what's inside — not just its appearance as a container. <div> and <span> are pure layout containers; they carry no meaning on their own. <nav>, <article>, and <button> are different — you can tell just from the name that one holds navigation links, one holds a standalone piece of writing, and one is something you can click.

This matters because HTML isn't only written for the browser to paint pixels. Plenty of things read it without ever "looking" at it: screen readers build a page outline from your tags, letting a visually impaired user jump straight to <nav> or skip past <aside>; search engine crawlers lean on tags like <article> and <h1> to figure out what a page is actually about; and the browser's own accessibility tree is built from tag semantics too. Swap all of that out for <div>, and you erase all of that information — all that's left is "here's a blob of content."

Where's the line between <article> and <section>?

This is where most people get stuck, because the two often look identical on the page — the difference is entirely semantic. Take a guess: the comment section under a blog post — which one should that be?

The answer is <section>, and no, wrapping every comment in its own <article> isn't quite the full picture either. The usual pattern is to wrap the whole comment section in a <section>, then wrap each individual comment in its own <article> — because a single comment, pulled out of context, still stands on its own as a complete piece of content.

<article>
  <h1>How to Get Good at Semantic HTML</h1>
  <p>Body content...</p>
 
  <section>
    <h2>Comments</h2>
    <article>
      <p>Reader: this explains it so clearly!</p>
    </article>
    <article>
      <p>Another reader: finally get the difference between article and section.</p>
    </article>
  </section>
</article>

See the pattern? The test isn't "does this look like a block of content" — it's asking yourself, over and over: strip away the surrounding context, does this still hold up as a complete thing on its own? If yes, it's an <article>. If it's just one piece of a larger whole that stops making sense outside that context, it's a <section>.

Who actually benefits from semantic markup

Semantic tags don't make a page look any better — their value shows up entirely off-screen, for three groups of people in particular:

Screen reader users. Screen readers build a page outline from tags like <h1> through <h6>, <nav>, and <main>, letting someone navigate straight to "main content" or "navigation" with a keyboard shortcut instead of listening through the entire page top to bottom. If everything's a <div>, that outline is empty, and there's no shortcut — just the whole page, start to finish.

Search engine crawlers. When a crawler is figuring out what a page is really about and building a summary, semantic tags like <article> and <h1> are one of the signals it leans on. That's the real basis for the claim that semantic HTML "helps SEO." Worth being precise here, though: semantic tags don't directly bump your ranking. What they improve is whether your content gets understood correctly — that's a different thing from a ranking boost.

Whoever maintains this in six months — including you. This one's the easiest to overlook, and the most immediate in practice. Open up markup built with <header>, <nav>, <main>, and <article>, and you can guess most of the layout just from the tags. Open up a pile of <div class="wrapper"><div class="inner">, and you have to dig through the CSS before any of it makes sense. Semantic tags effectively write part of the documentation directly into the HTML.

A couple of traps to avoid

• Stuffing two <main> tags into one page. <main> is supposed to represent the one primary content area of the page. Have two, and a screen reader has no way to know which one you actually meant — the whole point of "the one" content area falls apart. If a page seems to have multiple "main" sections, chances are only one of them is truly the main content, and the rest should probably be a <section> or <article> instead.

• Treating <div> as a tag to avoid on principle. <div> isn't deprecated or something to phase out — it's exactly what a pure layout container is supposed to be. When a block has no semantic role of its own and exists purely to hold CSS or organize layout, <div> (or <span> for inline cases) is the right call, and forcing a semantic tag onto it is the actual misuse. Semantic tags are meant to rescue meaningful content that's buried inside a <div> — not to hunt <div> down and eliminate it.

Takeaway

The real value of semantic tags isn't a better-looking page — it's that the HTML itself can say "here's what this is" without anyone having to guess from a class name or the CSS. Next time you're about to reach for <div> out of habit, pause and ask: strip away the styling, and is this fundamentally navigation, the main content, a standalone piece of writing, or just a layout container? The answer usually points straight to the right tag — and that one habit makes your page friendlier not just to browsers, but to screen readers, search engines, and whoever's maintaining it six months from now, you included.