How I Use the `<section>` Tag (and When Not To)

I once audited a site with over 400 <div> tags — and not a single <section>. Every block of content was just a box inside a box inside another box. It looked fine. But behind the curtain? A semantic mess.

That’s the danger of writing HTML that only *looks* right. When you ignore structure, you confuse screen readers, weaken SEO, and make life harder for future developers. So let’s talk about one of the most misunderstood HTML5 tags out there: <section>.

Here’s how I use it on real projects, how I explain it to clients and collaborators, and when I avoid it — on purpose.

What the `<section>` Tag Is Really For

Think of a web page like a nonfiction book. It has a title, an introduction, chapters, sidebars, references. The <section> tag? That’s your chapter. It marks a standalone chunk of related content with its own heading and purpose.

According to the spec, a section is a “thematic grouping of content.” Translation: if you can give the block a heading and explain it to someone (or a screen reader) as its own topic, it probably deserves a <section>.

Real-World Examples That Deserve a Section

A testimonials block labeled “What Clients Are Saying”
An FAQ group under “Common Questions”
A pricing chart introduced by “Plans & Pricing”
A block of case studies with their own heading

Here’s what that might look like:

<section>
  <h2>Plans & Pricing</h2>
  <ul>
    <li>Starter - $19/mo</li>
    <li>Pro - $49/mo</li>
    <li>Enterprise - Custom</li>
  </ul>
</section>

How It Helps

The beauty of <section> isn’t about visuals — it’s about meaning. And that has benefits for:

Screen reader users — they can jump between regions just like sighted users skim headings
SEO engines — Google understands content structure better when sections are clearly defined
Developers — semantic markup is easier to debug, refactor, and scale
Managers — it reduces the chances of front-end errors or inconsistent formatting down the line

It’s like giving your content a roadmap. Machines can follow it. Humans benefit from it.

When I Don’t Use It

Sometimes, you just need a container. You’re applying styles, setting layout rules, or wrapping components. That’s a job for <div>.

I avoid <section> in situations like:

Decorative wrappers (e.g., background images, layout helpers)
Nested grids or flex containers without standalone content
Modals or components without logical headings

In short: if the block doesn’t have its own topic or heading, don’t force it into a <section>. Semantics only help when they’re honest.

Common Objection: “Isn’t This Just Semantics?”

Yes — and that’s exactly why it matters.

Semantics are what separate a document from a layout. They allow assistive technology to parse meaning, not just pixels. They let your content survive design changes, platform shifts, or browser updates with clarity intact.

Think of semantic HTML like labeled storage bins. Anyone (or anything) opening the page should know exactly what each part is for. The alternative? A junk drawer of <div> soup.

Takeaways for Your Next Project

Can you name the block? Give it a heading. If it makes sense on its own, use <section>.
Just styling something? Use a <div>.
Want better accessibility? Think in chapters, not just containers.
Need stronger SEO? Semantics help search engines understand purpose.

Whether you're a developer working on a client build, a PM wrangling specs, or an SEO lead trying to improve crawlability — good structure makes everything easier.

Still unsure how to structure your next page? Or wondering if you’re using <section> the right way? Contact me here and let’s make sense of it together. I’ll walk you through it — no jargon, no judgment.

How I Use the <section> Tag (and When Not To)