Open any codebase from 2012 and you'll find a graveyard of <div> tags. div.header, div.nav, div.main-content, div.sidebar, div.footer — divs all the way down. We had no other choice back then. But HTML5 shipped semantic elements over a decade ago, and I still see developers writing div soup in 2025.
Here's the uncomfortable truth: if your HTML looks the same without your CSS, if a screen reader can't figure out what's a navigation bar and what's an article, you've got a problem. And it's not just an accessibility problem — it's an SEO problem and a maintainability problem too.
Let me walk you through the semantic elements that actually matter, and more importantly, how to use them correctly.
The Core Semantic Elements
HTML5 introduced a handful of structural elements that replace the most common <div> patterns. Here's the full picture of a well-structured page:
<body>
<header>
<nav>
<a href="/">Logo</a>
<ul>
<li><a href="/about">About</a></li>
<li><a href="/blog">Blog</a></li>
<li><a href="/contact">Contact</a></li>
</ul>
</nav>
</header>
<main>
<article>
<h1>Article Title</h1>
<p>Article content...</p>
<section>
<h2>First Section</h2>
<p>Section content...</p>
</section>
</article>
<aside>
<h2>Related Posts</h2>
<ul>...</ul>
</aside>
</main>
<footer>
<p>© 2025 My Site</p>
</footer>
</body>
Compare that to the div-soup equivalent. The semantic version is self-documenting. Any developer reading this HTML knows what each section does without checking class names.
<header> — Not Just for the Top of the Page
Here's a common misconception: <header> is only for the site's top navigation. Wrong. You can use <header> inside any sectioning element — articles, sections, even asides.
<article>
<header>
<h2>Understanding Flexbox</h2>
<time datetime="2025-08-01">August 1, 2025</time>
<span>By Sachin</span>
</header>
<p>Article body goes here...</p>
</article>
The <header> groups introductory content for its parent element. The page can have multiple headers — one for the site, one for each article. Both are valid.
<main> — There Can Be Only One
The <main> element wraps the primary content of your page — the content unique to this specific page. Navigation, sidebars shared across pages, and footers go outside <main>.
Critical rule: you can only have one <main> element per page (unless others are hidden with the hidden attribute). Screen readers use it to jump directly to the good stuff, skipping navigation entirely.
Quick accessibility win: Adding a "skip to content" link that targets <main> lets keyboard users bypass lengthy navigation menus. It's one of the easiest WCAG improvements you can make: <a href="#main" class="skip-link">Skip to content</a>
<article> — Standalone Content
Use <article> for content that makes sense on its own — blog posts, news articles, product cards, forum posts, comments. The litmus test: could this content be syndicated (like in an RSS feed) and still make sense out of context?
One thing that often gets overlooked: articles can be nested. A blog post is an <article>, and each comment on that post can also be an <article>. Both are semantically correct.
<section> vs. <div> — The Eternal Confusion
This is where most developers go wrong. <section> is NOT a replacement for <div>. A section represents a thematic grouping of content, and it should always have a heading.
<!-- Correct: section with a heading --> <section> <h2>Pricing Plans</h2> <div class="plan-grid">...</div> </section> <!-- Wrong: using section as a styling wrapper --> <section class="py-8 bg-gray-100"> <div class="container">...</div> </section>
If you're just grouping content for styling purposes and there's no logical heading for it, use a <div>. Divs are not evil. They're the right tool when you need a non-semantic container.
<aside> — Related but Not Essential
The <aside> element is for content tangentially related to the surrounding content. Think sidebars, pull quotes, related article lists, or advertising blocks.
<main>
<article>
<h1>How to Deploy to AWS</h1>
<p>Here's the deployment process...</p>
<aside>
<h3>What is AWS?</h3>
<p>Amazon Web Services is a cloud platform...</p>
</aside>
<p>Continuing with the deployment steps...</p>
</article>
</main>
Notice how the <aside> can go inside an article (for content related to that article) or at the page level alongside <article> (for a traditional sidebar). Both are valid and convey different relationships.
<nav> — Major Navigation Only
You don't need to wrap every group of links in <nav>. It's meant for major navigation blocks — the primary site nav, breadcrumbs, table of contents, pagination. A list of links in your footer? That's probably fine as a plain <ul>.
<nav aria-label="Main navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/products">Products</a></li>
<li><a href="/about">About</a></li>
</ul>
</nav>
If you have multiple <nav> elements on a page (which is totally fine), give each one an aria-label so screen readers can differentiate them: "Main navigation," "Breadcrumb," "Footer navigation."
Why This Matters for Accessibility
Screen readers use semantic elements to build a navigable outline of your page. A user with VoiceOver or NVDA can jump between landmarks: skip to the main content, jump to the navigation, find the footer.
With div soup, they get nothing. The screen reader sees a flat wall of generic containers and has to read everything linearly. For a page with a big navigation menu, that means listening to 20 links before reaching the actual content.
Each semantic element maps to an ARIA landmark role automatically:
<header>→banner(when it's a direct child of<body>)<nav>→navigation<main>→main<aside>→complementary<footer>→contentinfo(when it's a direct child of<body>)
You get ARIA roles for free just by using the right HTML. That's the beauty of it — no extra attributes needed.
The SEO Impact
Google's crawler is smart enough to figure out most page structures from context. But semantic HTML makes its job easier. When you wrap your blog post in <article> and your sidebar in <aside>, you're explicitly telling Google "this is the main content, and this is supplementary."
This matters for featured snippets and passage indexing. Google can more confidently extract relevant passages from your content when it knows which parts are the primary article and which are navigation or advertising.
SEO tip: Use <article> with proper heading hierarchy (h1 → h2 → h3) for your main content. Google's documentation explicitly mentions that proper heading structure and semantic markup help them understand page content hierarchy.
Common Mistakes I Keep Seeing
Mistake 1: Using <section> Instead of <div> Everywhere
I've reviewed codebases where every single <div> was replaced with <section>. That's worse than using all divs, because you're now lying to screen readers about your content structure. If it doesn't have a heading and doesn't represent a thematic grouping, use a <div>.
Mistake 2: Multiple <main> Elements
Exactly one visible <main> per page. I've seen sites with <main> elements nested inside other <main> elements. Screen readers have no idea what to do with that.
Mistake 3: Putting Site Nav Inside <main>
The <main> element is for content unique to this page. Your site-wide navigation is the same on every page — it belongs outside <main>, typically inside a <header>.
Mistake 4: Heading Level Chaos
Semantic HTML isn't just about the structural elements. Heading hierarchy matters too. Don't jump from <h1> to <h4> because you like the default font size. One <h1> per page, then <h2> for major sections, <h3> for subsections.
<!-- Don't do this --> <h1>My Blog</h1> <h4>Recent Posts</h4> <!-- Skipped h2 and h3! --> <!-- Do this --> <h1>My Blog</h1> <h2>Recent Posts</h2>
A Complete, Properly Structured Blog Page
Let me give you a real-world template that puts everything together. This is roughly the structure I use for every blog post on this site:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Post Title — My Blog</title>
</head>
<body>
<a href="#main-content" class="skip-link">
Skip to content
</a>
<header>
<nav aria-label="Main navigation">
<a href="/">My Blog</a>
<ul>
<li><a href="/blog">Blog</a></li>
<li><a href="/about">About</a></li>
</ul>
</nav>
</header>
<main id="main-content">
<article>
<header>
<h1>Post Title</h1>
<time datetime="2025-08-20">Aug 20, 2025</time>
</header>
<section>
<h2>Introduction</h2>
<p>Content here...</p>
</section>
<section>
<h2>Main Point</h2>
<p>More content...</p>
</section>
</article>
<aside aria-label="Related articles">
<h2>Related Posts</h2>
<ul>
<li><a href="/post-2">Related Post</a></li>
</ul>
</aside>
</main>
<footer>
<p>© 2025 My Blog. All rights reserved.</p>
</footer>
</body>
</html>
Every element has a purpose. Screen readers can navigate by landmarks. Google understands the content hierarchy. And any developer can read the HTML and immediately know what's what.
Convert Your Semantic HTML to Images
Built a beautifully structured page? Export it as a crisp PNG or WebP image for documentation and sharing.
Try HTML to PNG Free →Quick Reference Cheat Sheet
- <header> — Introductory content for its parent (page or section)
- <nav> — Major navigation blocks only
- <main> — One per page. The unique content area.
- <article> — Self-contained, syndicatable content
- <section> — Thematic grouping with a heading
- <aside> — Tangentially related content
- <footer> — Footer for its parent (page or section)
- <div> — No semantic meaning. Use for styling wrappers.
The Bottom Line
Semantic HTML isn't a trend. It's how the web was always supposed to be built. It costs nothing extra — you're writing HTML either way. You just need to pick the right element instead of defaulting to <div>.
Your future self, your colleagues, screen reader users, and search engines will all thank you. It's one of those rare things in web development where doing the right thing is also the easy thing.
Start with your next project. Replace those divs where appropriate. It takes five minutes of thought and pays off for the entire lifetime of the codebase.
