Semantic HTML for Machines and People

Open the source of an average commercial webpage and you'll find it: div soup. Nested <div>s forty layers deep, class names like wrapper-inner-container-2, and somewhere in the middle, the actual content. The page renders fine. It might even look beautiful. But as a piece of communication with machines — browsers, search engines, screen readers, reader modes, and the growing crowd of AI crawlers deciding whether to cite you — it's a shrug. Everything is a box; nothing means anything.

Semantic HTML is the alternative: using elements that say what content is, not just how it should look. It costs almost nothing at writing time and pays out across search, accessibility, maintenance, and durability. Here's the case, and the practical vocabulary.

What "semantic" means, concretely

Compare two ways to mark up the same page region:

<div class="top"><div class="links">...</div></div>

versus

<header><nav aria-label="Main">...</nav></header>

Both can be styled identically. The difference is that the second version is legible to software that has never seen your CSS. A screen reader can announce "navigation" and offer to skip it. A search engine can discount boilerplate links from its analysis of your page's topic. A browser's reader mode can find the real content by elimination. Your successor — or you, in eighteen months — can read the markup like a table of contents. The class name top communicates only with your stylesheet; the element <header> communicates with everything.

The audience for your markup is bigger than you think

It's worth pausing on who, exactly, reads your HTML:

Search engine crawlers, which use structure to distinguish main content from navigation and footer boilerplate, and headings to understand topic hierarchy.
Assistive technology. Screen readers build a navigable map of your page from landmarks (header, nav, main, footer) and headings. On a semantic page, a blind user jumps straight to the content; on div soup, they wade through every link in your mega-menu, on every page, every visit.
Reader modes and read-later apps, which extract the <article> and discard the chrome. Sites that fail extraction get mangled or skipped.
AI crawlers and answer engines. As more discovery shifts to AI-generated answers, being cleanly parseable is becoming a distribution concern. Structured, semantic pages are simply easier to chunk, attribute, and quote correctly than anonymous box-piles.
Browsers themselves, which wire up keyboard behavior, form semantics, and default accessibility for native elements — behavior you must otherwise rebuild by hand, imperfectly.

The core vocabulary: page landmarks

A handful of elements describe the macro-structure of nearly any page:

Element	Use it for	Common mistake
`<header>`	Introductory content: logo, site title, main nav. Also valid inside an article for its title block.	Thinking there can be only one — an `<article>` may have its own.
`<nav>`	Major navigation blocks: main menu, breadcrumbs, pagination.	Wrapping every list of links. Reserve it for real navigation; label multiples with `aria-label`.
`<main>`	The unique content of this page. Exactly one per page.	Omitting it — it's the single most useful landmark for skip-to-content.
`<article>`	Self-contained content that would make sense syndicated alone: a post, a product card, a comment.	Using it as "fancy div" for any box.
`<section>`	A thematic grouping within content, almost always with its own heading.	Sections without headings — if you can't name it, it's probably just a div.
`<aside>`	Tangential content: sidebars, pull quotes, related links.	Putting essential content in it, where some tools deprioritize it.
`<footer>`	Closing matter: copyright, contact, secondary links.	None, really — this one's hard to misuse.

A useful test when choosing between <article>, <section>, and <div>: would this content stand alone in an RSS feed? Article. Is it a named chapter of the current page? Section. Is it purely a styling or layout hook? Div — and that's fine. Divs aren't evil; meaningless markup where meaning exists is. A page layout will always need some purely structural wrappers.

The inline vocabulary people forget

Beyond landmarks, the everyday elements carry surprising weight:

<strong> vs <b>, <em> vs <i>. <strong> means importance, <em> means stress emphasis; the single-letter versions are purely visual. In practice the distinction matters less than consistency — but if you mean "this is critical," say <strong>.
<time datetime="2026-07-06"> makes dates machine-readable — useful for search snippets and event parsing, and it costs one attribute.
<figure> + <figcaption> bind an image to its caption explicitly, instead of hoping proximity implies it.
<blockquote cite="..."> for quotations, <cite> for the work's title.
<table> for tabular data — with <th> headers and a <caption> — and never for layout; while lists (<ul>, <ol>, <dl>) belong wherever content is actually a list. Screen readers announce "list, five items" — orientation you get for free.
<button> and <a>, the load-bearing pair: buttons do things, links go places, and both come with keyboard handling, focus behavior, and assistive-tech announcements that a click-handling div lacks entirely.

Headings: the skeleton inside the skeleton

Landmarks give machines the map of your page; headings give them the outline of your content. The rules are short: one <h1> that names the page, <h2>s for major sections, deeper levels nested without skipping, and — critically — levels chosen by structure, never by font size. If your h3 looks too small, restyle h3 in CSS; don't promote content to h2 for cosmetic reasons. Screen reader users navigate by heading jumps more than any other method, and search engines read your heading outline as a statement of what the page is about. A page whose headings form a coherent outline when read alone is a page both audiences understand.

What semantic HTML does for SEO — honestly stated

Let's calibrate expectations. Swapping divs for sections will not rocket you up the rankings; search engines have spent two decades learning to parse messy HTML because they had no choice. The realistic benefits:

Cleaner content extraction. Clear main/article boundaries and heading outlines help crawlers identify your primary content and its topic structure — table stakes done well.
Richer features via structured data. Semantic HTML pairs naturally with schema.org markup (JSON-LD) for recipes, products, events, FAQs — which does visibly change how you appear in results.
Accessibility overlap. Many semantic practices (headings, link text, alt text) are direct or indirect ranking inputs because they're user-experience inputs.
The AI-answer angle. Emerging but real: systems that quote and cite the web reward pages whose structure makes attribution easy. Semantic markup is cheap insurance on that future.

Retrofitting an existing site without a rewrite

You don't need to rebuild anything. A pragmatic sequence:

Fix the landmarks in your theme templates once — header, nav, main, footer live in a handful of files, and fixing those fixes every page. Most modern WordPress themes already do this; verify with a landmarks browser extension or by checking the source.
Fix heading discipline in your content workflow. This is an editorial habit, not a code change: heading levels follow structure, one h1, no skipping.
Fix interactive elements as you touch them. Every clickable div you encounter during other work becomes a button. Every span-styled-as-link becomes a link.
Add the inline niceties opportunistically — time, figure, blockquote — in new content going forward. Don't audit ten years of archives; let the backlog age out.

The durability argument

Here's the quiet final benefit. CSS frameworks churn. JavaScript frameworks churn faster. Class-name conventions rise and fall like hemlines. But <article>, <nav>, and <h2> will mean the same thing in fifteen years that they mean today, to every browser and every parser, because the web platform does not break its contracts. Markup that encodes meaning in the elements themselves — rather than in a class dictionary that lives in your head or a designer's Figma file — is the part of your site that survives every redesign. Write for the machines and the people; the divs can carry the decoration.

Photo: Bibek ghosh on Pexels