Semantic HTML in Divi 5: What Changed and How to Use It

If you've read anything about SEO in the last few years, you've been told to "use semantic HTML." Swap your <div> soup for <header>, <nav>, <main>, <article>, <section>, <footer>. It's good advice. It's also advice written for people who hand-code their markup — not for the millions of people building WordPress sites in a page builder.

If you build in Divi, here's the uncomfortable truth: until recently, most of your page's body content came out as div after div after div, no matter how semantically you tried to think about your layout. Divi 5 changes that — but only if you know the feature exists and use it deliberately. Here's what actually changed, and how to put it to work on a real page.

Semantic vs. Non-Semantic HTML, Quickly

Semantic HTML uses tags that describe what the content is, not just how it's boxed up. <nav> means "this is navigation." <header> means "this is introductory content for a page or section." <article> means "this is a self-contained piece of content." The tag itself carries meaning, independent of any styling.

Non-semantic HTML uses generic containers — <div> and <span> — that carry no meaning on their own. A <div> is just a box. It might visually look like a header, a nav menu, or a sidebar, but nothing in the tag itself says so. The only way to know what it's for is to read its class name or inspect its CSS, and machines parsing your page don't do that the way a human eye does.

Here's the same navigation menu written both ways:

Non-semantic:

<div class="menu">
  <div class="menu-item"><a href="/">Home</a></div>
  <div class="menu-item"><a href="/about">About</a></div>
</div>

Semantic:

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

Visually, these can render identically — same CSS, same look. The difference is entirely in what the markup communicates. A screen reader hitting the first version has to guess this is navigation, if it can tell at all. A screen reader hitting the second version can announce "navigation, two items" and let a user jump straight to it. A crawler hitting the second version knows with certainty which links on the page are structural navigation versus in-content links, which matters when it's deciding what to weight as your actual content.

Why Semantic HTML is Worth the Effort

• Accessibility. Screen readers rely on landmarks like <nav>, <main>, and <header> to build a navigable outline of the page. Without them, a user has to tab through everything in document order with no way to skip ahead.
• Clearer crawling and indexing. Tags like <article> and <main> help search engines separate your actual content from boilerplate — navigation, sidebars, footers — so they can weight the right part of the page.
• Better AI and LLM comprehension. Tools that summarize or extract content from a page lean on structure to figure out what the main content is, the same way a crawler does. Semantic tags make that extraction more reliable.
• Easier maintenance. <header>, <nav>, and <footer> are self-documenting. Six months from now, you or another developer can scan the markup and understand the page's structure without decoding class names.
• Some free functionality. Elements like <details>/<summary> come with built-in keyboard support and toggle behavior, no JavaScript required — one less thing that can break.

The catch: Divi's Visual Builder has historically defaulted to the non-semantic version of everything — which is the problem the next section covers.

The Semantic HTML Problem in Divi (Before Divi 5)

Divi's Visual Builder was never built around semantic output — it was built around visual flexibility. Every section, row, column, and module rendered as a <div> with a Divi-generated class like et_pb_section or et_pb_row. Some parts of a Divi site were already reasonably semantic: the Theme Builder's header and footer templates typically land inside sensible wrapper tags, and the Blog module wraps each post in something article-shaped. But the body of a page — the part you actually build in the Visual Builder — was almost entirely generic containers.

That's not just a semantic nitpick. It's the same category of issue behind the duplicate H1 problem I wrote about with Divi's heading structure — the builder gives you visual control without giving you a way to express document structure. You could make something look like a header, a nav menu, or a sidebar, without the markup ever saying so.

What Changed: Semantic Elements in Divi 5

Divi 5 introduced a feature called Semantic Elements, and it's more useful than the name suggests. Three pieces matter here.

1. Element Type dropdown

Every section, row, column, and module now has an HTML option group on its Advanced tab, with an Element Type dropdown. Instead of the default <div>, you can set the wrapper to header, nav, main, section, article, aside, footer, button, and a handful of other tags — directly in the Visual Builder, no Code module required.

So if you've built a custom mega-menu out of Divi modules instead of the native menu module, you can now select that container and change its Element Type to nav. A screen reader user suddenly has a real landmark to jump to. Before Divi 5, that container was permanently a <div> no matter how menu-like it looked.

2. HTML Before and HTML After

Because Divi modules are separate blocks, a single Code module has never been able to wrap several modules in one shared parent tag. The new HTML Before and HTML After fields solve that — you can inject opening and closing markup around an element, including custom wrappers a Code module physically couldn't reach. This is how you'd wrap, say, three separate modules that together form one logical <article>.

3. Toggle module → native <details>/<summary>

This one is worth calling out on its own. Divi's Toggle module — the one most people use for FAQ accordions — can now output the browser-native <details> and <summary> elements instead of a JavaScript-driven open/close widget. That gets you free keyboard accessibility, no JS dependency for the interaction, and markup that pairs cleanly with FAQ schema, which is exactly the kind of section most evergreen posts (including this one) rely on.

How to Add Semantic HTML Tags in Divi 5 (Step by Step)

Here's the workflow I'd run on an existing Divi page rather than a blank one — most of you aren't starting from scratch.

Step 1: Check what's already semantic

Right-click any element on your live page and choose Inspect. Look at your header and footer areas first — if you're using Theme Builder templates, these are often already close to correct. Your job is to find the gaps, not rebuild everything.

Step 2: Tag your main content area

Select the outermost section that holds your actual page content — not the header, not the footer — and set its Element Type to main. There should only be one main per page, so do this once, at the top-level wrapper for your body content.

Step 3: Tag logical content blocks as section or article

Inside that main area, individual sections with their own heading — a features block, a testimonials block, a pricing block — are good candidates for section. If a block is a genuinely standalone, reusable piece of content (a blog post inside a loop, a single testimonial card), article is the more accurate tag.

Step 4: Tag anything tangential as aside

Sidebars, related-posts widgets, and pull-quote-style callouts that support but aren't part of the main flow are what aside is for. If a reader could skip it without losing the thread of the page, it's probably an aside.

Step 5: Rebuild custom navigation and buttons properly

If you've built any navigation-like element out of Divi Text or Blurb modules rather than the native Menu module, switch its Element Type to nav. Same logic for anything acting as a button but built from a styled Text or Image module — Divi 5 lets you assign button as the Element Type so it behaves and announces itself correctly to assistive tech, not just visually.

Step 6: Convert your FAQ toggles

If your FAQ section uses the Toggle module, switch it to output <details>/<summary> where Divi 5 supports it. You keep your existing FAQ schema exactly as is — the schema markup lives separately in your page's <head> or as JSON-LD, so this is a pure markup upgrade with no knock-on changes to your structured data.

Set Semantic Tags by Default Using Divi 5 Presets

Doing this section by section on an existing page is a one-time cleanup. Going forward, you don't want to repeat that work on every new page. Divi 5's preset system lets you set an Element Type as part of a module or section's default preset, so anything you build afterward already carries the right tag — you're not fixing semantics after the fact, you're building semantically from the first click.

Does Semantic HTML Actually Affect Rankings?

Worth being honest here: semantic HTML is not a direct ranking factor, and nobody at Google has claimed otherwise. What it does do is remove ambiguity — for screen readers navigating your page, for crawlers trying to identify your main content versus boilerplate, and increasingly for AI systems parsing pages for summarization, which is the same territory I covered in my guide to Google's AI optimization recommendations. Cleaner structure doesn't guarantee a ranking boost, but it removes a class of interpretation problems that can quietly work against you — same principle as fixing a duplicate H1 or an unclear heading hierarchy.

FAQ: Semantic HTML in Divi 5

Do I need to redo every page on my site?

No. Prioritize your highest-traffic pages and anything with accessibility complaints or known structural issues first, then use presets so new pages come out correct by default.

Will changing Element Type break my page's styling?

Generally no — CSS applies based on class and structure, not tag name, so swapping a <div> for a <section> with the same classes shouldn't change how it looks. Always check on a staging site before applying broadly.

Do I need Divi 5 specifically, or does this work on Divi 4?

The Element Type dropdown and HTML Before/After fields are Divi 5 features. On Divi 4, you're limited to a Code module for custom wrappers, and you can't change a module's own wrapper tag.

Does this replace the need for a Code module?

Mostly for wrapper-tag changes, yes. You'll still reach for a Code module for anything beyond swapping an element's own tag or wrapping it with HTML Before/After — complex custom markup, third-party embeds, or scripts.

Can I use multiple <section> tags on a page?

Yes. A page can contain multiple <section> elements, but should generally have only one <main> element.