Stop Building With Divs
View source on most business websites and you'll find a sea of <div> elements. Div for the header. Div for the navigation. Div for the main content. Div for each section. Div for the footer. Sprinkle in some <span> elements and you've got a website that a browser can render but neither a search engine nor a screen reader can properly understand. Semantic HTML is the practice of using HTML elements that describe their content and purpose, not just their visual appearance. It's also the easiest win in web development — free performance improvements, free SEO benefits, free accessibility gains. No build tools. No libraries. No configuration. Just better markup. What semantic HTML actually means HTML5 introduced elements that carry meaning: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <figure>, <figcaption>, <time>, <address>, and more. Each one tells browsers, search engines, and assistive technologies something specific about the content it contains. A <nav> element tells a screen reader "this is a navigation region — the user can jump here directly." A <main> element says "this is the primary content of the page." An <article> element says "this is a self-contained piece of content that could stand alone." A <div> says nothing. It's a generic container with zero semantic meaning. The SEO advantage is real Google's crawler parses your HTML to understand your content hierarchy. When you use <main>, Google knows where your primary content lives. When you use <article>, it can identify distinct content blocks. When you use proper heading hierarchy — a single <h1> followed by <h2>, <h3>, and so on — it understands the structure and relative importance of your content sections. This isn't theoretical. Google's own documentation explicitly recommends semantic HTML for better content understanding. Pages with proper heading structure consistently outperform pages with flat or broken heading hierarchies for relevant search queries. Rich snippets, FAQ schema, and featured snippets all depend on Google being able to parse your content structure correctly — and semantic HTML is the foundation of that parsing. The accessibility win is massive Screen readers use semantic elements as navigation landmarks. A VoiceOver user can press a key to jump directly to the <nav>, the <main>, or any <h2> on the page. On a div-based site, they have to Tab through every single element sequentially — imagine trying to find the contact section on a 3,000-word page by pressing Tab 200 times. Proper heading hierarchy is the foundation of screen reader navigation. Headings must follow a logical order — <h1> then <h2> then <h3>. Skipping levels (jumping from <h1> to <h4>) confuses assistive technology. Using headings for visual styling (making something an <h3> because you want smaller bold text) instead of hierarchy breaks the navigation model entirely. Use CSS for visual styling. Use headings for document structure. The performance angle Semantic HTML is inherently lighter than the alternatives. A <button> element is focusable, keyboard-activatable, and correctly announced by screen readers with zero JavaScript. Recreating that behaviour with a <div> requires tabindex, a click handler, a keydown handler for Enter and Space, an ARIA role, and focus management code. That's 20+ lines of JavaScript to replicate what the browser gives you for free with the correct element. Multiply this across an entire site — custom divs for buttons, spans for links, divs for form controls — and you accumulate significant unnecessary JavaScript. We've seen sites drop 10-15KB of JS simply by replacing custom div-based components with native HTML elements. The elements most sites get wrong <button> vs <a>: If it navigates to a URL, it's an <a> element. If it triggers an action (open a modal, submit a form, toggle a menu), it's a <button>. Divs and spans with click handlers are neither. <section> vs <div>: A <section> represents a thematic grouping of content with a heading. If the content doesn't have a heading or isn't a distinct thematic section, use a <div>. Don't replace every <div> with <section> — that's just as unsemantic. <figure> and <figcaption>: For images with captions, diagrams, code snippets, and quotes that are referenced from the main content. Most sites put images in plain <div> wrappers when <figure> with <figcaption> would give search engines and screen readers the relationship between the image and its description. <time>: For dates and times. Adding a datetime attribute with a machine-readable format helps search engines understand when content was published, when events occur, and when business hours apply. A practical audit Right-click your homepage and hit "View Source." Search for <main>. If it doesn't exist, your page has no declared primary content region. Count your heading elements — is there exactly one <h1>? Do the <h2> and <h3> elements follow a logical hierarchy? Search for div onclick — every instance is a semantic and accessibility failure. Check your navigation — is it inside a <nav> element? Does your site footer use <footer>? If the answers are discouraging, the good news is that fixing semantic HTML is one of the fastest, cheapest improvements you can make. No redesign required. No framework migration. Just replacing generic elements with meaningful ones. It takes a few hours and the benefits are permanent.