Semantische HTML-Elemente — HTML schreiben, das wirklich Bedeutung hat

Wer für alles <div> schreibt — Seiten-Wrapper, Navigation, Artikel-Container, Sidebar — ist damit nicht allein. Das war jahrelang der Standardweg. Aber HTML hat seit HTML5 richtige semantische Elemente, und deren Verwendung macht den Code leichter lesbar, besser für SEO und wirklich zugänglicher. Schauen wir uns die Elemente an, die tatsächlich wichtig sind.

Das Wort "semantisch" bedeutet lediglich, dass das Element eine Bedeutung trägt, die über seine visuelle Darstellung hinausgeht. Ein <div> bedeutet nichts — es ist ein generischer Block. Ein <nav> teilt dem Browser, Suchmaschinen und assistiven Technologien mit: "Hier befinden sich Navigationslinks." Dieser Kontext kostet nichts beim Hinzufügen und zahlt sich auf mehrere Arten aus.

Warum Semantik wichtig ist

Drei echte Vorteile, keine theoretischen:

SEO. Suchmaschinen nutzen die Dokumentstruktur, um die Inhaltshierarchie zu verstehen. Ein <main>-Element signalisiert den Hauptinhalt. Ein <article> darin signalisiert ein eigenständiges Stück. Google verwendet diese Signale beim Ranking von Seiten.
Barrierefreiheit. Screen-Reader machen Landmark-Regionen für Benutzer zugänglich. Mit <nav>, <main> und <aside> an Ort und Stelle können Tastaturbenutzer direkt zum gewünschten Bereich springen — ohne durch jeden Link auf der Seite zu tabben.
Wartbarkeit. Ein neuer Entwickler, der die Vorlage liest, versteht die Seitenstruktur sofort. <header>/<main>/<footer> ist selbst-dokumentierend auf eine Weise, wie es <div class="top">/<div class="content">/<div class="bottom"> nicht ist.

Die zentralen Layout-Elemente

Diese fünf Elemente bilden das äußere Gerüst der meisten Seiten. Sie auf jeder Seite zu verwenden bedeutet, die Hälfte der semantischen Arbeit bereits erledigt zu haben:

html

<body>
  <header>
    <a href="/" class="logo">MyBlog</a>
    <nav>
      <ul>
        <li><a href="/articles">Articles</a></li>
        <li><a href="/about">About</a></li>
        <li><a href="/contact">Contact</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <!-- Primary page content goes here -->
  </main>

  <aside>
    <!-- Sidebar: related links, ads, author bio -->
  </aside>

  <footer>
    <p>&copy; 2026 MyBlog. All rights reserved.</p>
  </footer>
</body>

<header>. Einleitender Inhalt für die Seite oder einen Bereich. Enthält normalerweise Logo, Seitenname und Hauptnavigation. Kann auch innerhalb von <article> für den eigenen Überschriftenblock verwendet werden.
<nav>. Eine Gruppe von Navigationslinks. Nicht jede Linkgruppe braucht ein <nav> — für wichtige Navigationsblöcke wie Sitenavigation oder Paginierung verwenden.
<main>. Der Hauptinhalt der Seite. Es sollte nur ein <main> pro Seite geben, und es sollte nichts enthalten, was seitenübergreifend wiederholt wird (Header, Nav, Footer).
<aside>. Inhalt, der thematisch zum Hauptinhalt gehört. Sidebars, Zitate, verwandte Artikel. Screen-Reader stellen dies als ergänzendes Landmark bereit.
<footer>. Fußzeile für die Seite oder einen Bereich. Kann Copyright-Informationen, sekundäre Navigation, Kontaktlinks oder eine kurze Autorennotiz enthalten.

Häufiger Fehler: <header> und <footer> sind nicht auf die Seitenebene beschränkt. Jedes <article> oder <section> kann seinen eigenen <header> und <footer> haben. Das ist besonders nützlich für Blog-Post-Byelinen und artikelspezifische Metadaten.

article vs. section — Wann welches Element verwendet wird

Das ist der Punkt, der die meisten Menschen verwirrt. Die Faustregel, die wirklich funktioniert: Wenn der Inhalt Sinn ergeben würde, wenn er eigenständig verbreitet würde (z.B. als RSS-Eintrag veröffentlicht oder auf einer anderen Website geteilt), ist es ein <article>. Wenn es nur als Teil eines größeren Ganzen Sinn ergibt, ist es ein <section>.

html

<!-- article: self-contained, could stand alone -->
<article>
  <header>
    <h2>Understanding HTTP/2 Push</h2>
    <p>By Alice Chen — <time datetime="2026-03-15">March 15, 2026</time></p>
  </header>
  <p>HTTP/2 Server Push lets the server send resources...</p>
  <footer>
    <p>Tagged: <a href="/tags/http">HTTP</a>, <a href="/tags/performance">Performance</a></p>
  </footer>
</article>

<!-- section: thematic grouping within a page -->
<section>
  <h2>Related Articles</h2>
  <ul>
    <li><a href="/http3-quic">HTTP/3 and QUIC Explained</a></li>
    <li><a href="/cdn-strategy">CDN Strategy for Global Apps</a></li>
  </ul>
</section>

<section> sollte immer eine Überschrift haben (<h2> bis <h6>). Fehlt die Überschrift, ist das meist ein Zeichen, stattdessen ein <div> zu verwenden. Die WHATWG-Spezifikation ist eindeutig: <section> ist für thematische Gruppierungen, nicht für beliebige Layout-Aufteilungen.

figure, figcaption, time und address

Vier Elemente, die Entwickler häufig übersehen, aber regelmäßig brauchen:

html

<!-- figure + figcaption: images, code blocks, diagrams, charts -->
<figure>
  <img src="/images/latency-chart.png" alt="P99 latency over 24 hours showing a spike at 14:30">
  <figcaption>Figure 1: API latency during the Tuesday incident (UTC).</figcaption>
</figure>

<!-- A code block as a figure (totally valid) -->
<figure>
  <pre><code>const result = await db.query('SELECT * FROM users WHERE active = true');</code></pre>
  <figcaption>Listing 1: Basic active user query.</figcaption>
</figure>

<!-- time: machine-readable dates and times -->
<p>Published <time datetime="2026-04-16T09:00:00Z">April 16, 2026</time></p>
<p>Sale ends in <time datetime="PT2H30M">2 hours 30 minutes</time></p>

<!-- address: contact info for nearest article or body ancestor -->
<address>
  Written by <a href="mailto:[email protected]">Alice Chen</a>.<br>
  123 Dev Street, San Francisco, CA.
</address>

<figure>. Beliebiger eigenständiger Inhalt, der aus dem Hauptfluss referenziert wird — Bilder, Code-Listings, Diagramme, Videos. Das Kernmerkmal: er könnte in einen Anhang verschoben werden, ohne den Lesefluss zu unterbrechen.
<figcaption>. Die Bildunterschrift für ein <figure>. Muss das erste oder letzte Kind von <figure> sein. Stellt eine semantische Verbindung zwischen Beschriftung und Inhalt her, die ein <p> unter einem Bild nicht bietet.
<time>. Menschenlesbare Daten mit einem maschinenlesbaren datetime-Attribut. Der datetime-Wert verwendet das ISO 8601-Format. Suchmaschinen nutzen dies für Event-Markups und Aktualitätssignale.
<address>. Kontaktinformationen für den nächsten <article>-Vorfahren (oder den gesamten <body>). Kein allgemeines Adresselement — es ist speziell für Kontaktinformationen des Autors oder Site-Betreibers.

Das Divitis-Anti-Pattern

"Divitis" beschreibt den Zustand, wenn jedes Element im HTML ein <div> ist. Hier ist ein reales Vorher/Nachher, das das Problem zeigt:

html

<!-- Before: divitis -->
<div class="page">
  <div class="header">
    <div class="brand">TechBlog</div>
    <div class="nav">
      <div class="nav-item"><a href="/posts">Posts</a></div>
    </div>
  </div>
  <div class="post">
    <div class="post-title">Why TypeScript Is Worth It</div>
    <div class="post-meta">By Bob — Jan 2026</div>
    <div class="post-body">TypeScript adds static types to JavaScript...</div>
  </div>
</div>

<!-- After: semantic HTML -->
<body>
  <header>
    <span class="brand">TechBlog</span>
    <nav>
      <a href="/posts">Posts</a>
    </nav>
  </header>
  <main>
    <article>
      <header>
        <h1>Why TypeScript Is Worth It</h1>
        <p>By Bob — <time datetime="2026-01-10">January 10, 2026</time></p>
      </header>
      <p>TypeScript adds static types to JavaScript...</p>
    </article>
  </main>
</body>

Die semantische Version ist tatsächlich kürzer, benötigt weniger CSS-Klassennamen und gibt Browsern und assistiven Tools alles, was sie zur Strukturerkennung brauchen. Mit CSS lässt sich alles genauso stylen — semantische Elemente erzwingen keine visuellen Einschränkungen.

ARIA-Rollen — Letzter Ausweg, nicht erster Schritt

ARIA-Rollen ermöglichen es, Elementen semantische Bedeutung hinzuzufügen, die sie nativ nicht haben. Das Problem: Entwickler greifen oft auf ARIA zurück, wenn ein semantisches HTML-Element die Arbeit besser erledigen würde. Die erste Regel von ARIA: ARIA nicht verwenden, wenn natives HTML ausreicht.

html

<!-- Wrong: using ARIA where native HTML works -->
<div role="navigation">
  <a href="/home">Home</a>
</div>

<!-- Right: just use the semantic element -->
<nav>
  <a href="/home">Home</a>
</nav>

<!-- ARIA is appropriate here: custom widget with no HTML equivalent -->
<div
  role="tablist"
  aria-label="Code examples"
>
  <button role="tab" aria-selected="true" aria-controls="panel-js">JavaScript</button>
  <button role="tab" aria-selected="false" aria-controls="panel-py">Python</button>
</div>

ARIA für interaktive Widgets verwenden, die natives HTML nicht abdeckt — Tab-Panels, Comboboxen, Baumansichten, Datumsauswähler. Für strukturelle Landmarks wie Navigation, Header und Hauptinhalt immer auf native Elemente setzen.

Eine vollständige Blog-Post-Seitenstruktur

So sieht eine vollständig semantische Blog-Post-Seite aus. Das ist das Muster, das auf Seiten verwendet wird, die bei Barrierefreiheits-Audits ohne Zusatzaufwand gut abschneiden:

html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Why TypeScript Is Worth It — TechBlog</title>
</head>
<body>
  <header>
    <a href="/" class="logo">TechBlog</a>
    <nav aria-label="Site navigation">
      <ul>
        <li><a href="/posts">Posts</a></li>
        <li><a href="/topics">Topics</a></li>
        <li><a href="/about">About</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <article>
      <header>
        <h1>Why TypeScript Is Worth It</h1>
        <address>
          By <a rel="author" href="/authors/bob">Bob Martinez</a>
        </address>
        <p>Published <time datetime="2026-01-10">January 10, 2026</time></p>
      </header>

      <section>
        <h2>The Setup Cost Is Real but Front-Loaded</h2>
        <p>TypeScript adds a compilation step and requires type annotations...</p>

        <figure>
          <pre><code>interface User {
  id: number;
  name: string;
  email: string;
}</code></pre>
          <figcaption>Listing 1: A typed User interface catches shape errors at compile time.</figcaption>
        </figure>
      </section>

      <section>
        <h2>Where TypeScript Pays Off</h2>
        <p>The ROI kicks in as team size and codebase complexity grows...</p>
      </section>

      <footer>
        <p>
          Tagged: <a href="/tags/typescript">TypeScript</a>,
          <a href="/tags/javascript">JavaScript</a>
        </p>
      </footer>
    </article>

    <aside aria-label="Related articles">
      <h2>You Might Also Like</h2>
      <ul>
        <li><a href="/ts-vs-js">TypeScript vs JavaScript — A Practical Comparison</a></li>
        <li><a href="/ts-generics">TypeScript Generics Explained</a></li>
      </ul>
    </aside>
  </main>

  <footer>
    <nav aria-label="Footer navigation">
      <a href="/privacy">Privacy</a>
      <a href="/terms">Terms</a>
    </nav>
    <p><small>&copy; 2026 TechBlog</small></p>
  </footer>
</body>
</html>

Beachtenswert ist die doppelte Verwendung von <header> und <footer> — einmal auf Seitenebene, einmal innerhalb von <article>. Das ist beabsichtigt und korrekt. Auch zwei <nav>-Elemente mit unterschiedlichen aria-label-Werten fallen auf — das verhindert, dass Screen-Reader zwei identische "Navigations"-Regionen aufführen.

Schnellreferenz: Hilfreiche Tools

Wer mit HTML arbeitet und den Code bereinigen oder validieren möchte: Der HTML-Formatierer formatiert und ordnet den Code, und der HTML-Validator erkennt strukturelle Fehler wie nicht geschlossene Tags und fehlende Pflichtattribute. Für ein gründlicheres Barrierefreiheits-Audit bietet web.dev/accessibility exzellente Diagnosen und Erläuterungen.

Fazit

Semantisches HTML ist nicht das Befolgen von Regeln um ihrer selbst willen — es geht darum, Code zu schreiben, der Browsern, Suchmaschinen, assistiven Tools und dem nächsten Entwickler, der die Vorlage liest, klar kommuniziert. Die Kernelemente sind unkompliziert: <header>, <nav>, <main>, <article>, <section>, <aside> und <footer> decken den Großteil realer Seitenstrukturen ab. <figure>, <time> und <address> dort hinzufügen, wo sie passen, ARIA nur dann einsetzen, wenn natives HTML nicht ausreicht — und man hat einen Markup, mit dem es echte Freude macht zu arbeiten.

← All HTML articles Browse all categories →