Semantisches HTML für SEO

TL;DR — Semantisches HTML bedeutet, Tags zu verwenden, die beschreiben, was Inhalte sind — <article>, <nav>, <main>, <header> — statt alles in einfache <div>s zu packen. Es hilft Suchmaschinen und Screenreadern, Ihre Seite zu verstehen, ist aber kein Ranking-Faktor. Die Verwendung von <article> führt nicht zu höherem Ranking. Dieselbe Regel gilt auch über Landmarks hinaus: <a href> für Links, <button> für Aktionen, <table> für tabellarische Daten, echte Alt-Texte bei Bildern. Verwenden Sie das richtige Tag für den Zweck, und Sie sind schon fast am Ziel.

Was semantisches HTML ist

Jeder Teil einer Webseite besteht aus HTML-Elementen. Semantisches HTML bedeutet einfach, das Element auszuwählen, das zu dem passt, was der Inhalt tatsächlich ist, statt für alles einen generischen Wrapper zu verwenden.

Vergleichen Sie diese beiden Versionen derselben Seitenstruktur:

<!-- Non-semantic: "div soup" -->
<div class="top"> ... </div>
<div class="menu"> ... </div>
<div class="content"> ... </div>
<div class="sidebar"> ... </div>
<div class="bottom"> ... </div>

<!-- Semantic: the tags describe the roles -->
<header> ... </header>
<nav> ... </nav>
<main> ... </main>
<aside> ... </aside>
<footer> ... </footer>

Beide können auf dem Bildschirm identisch aussehen – CSS übernimmt das Styling. Der Unterschied besteht darin, dass die zweite Version einer Maschine (einer Suchmaschine, einem Screenreader, einem KI- Crawler) mitteilt, welcher Teil die Navigation ist, welcher der Hauptinhalt und welcher eine Sidebar. Die erste Version lässt alle raten.

Die Elemente, die Sie tatsächlich verwenden werden

• <header> – einleitender Inhalt oben auf der Seite (oder oben in einem Abschnitt).
• <nav> – ein Block mit Navigationslinks.
• <main> – der primäre, eindeutige Inhalt der Seite. Einer pro Seite.
• <article> – ein in sich geschlossenes Stück, das eigenständig bestehen kann (ein Blogbeitrag, eine Produktkarte, ein Kommentar).
• <section> – eine thematische Gruppierung von Inhalten mit eigener Überschrift.
• <aside> – Inhalt, der tangential zum Hauptinhalt ist (eine Sidebar, ein Hinweis).
• <footer> – abschließender Inhalt (Copyright, sekundäre Links).

Dieselbe Idee „das richtige Tag verwenden“ gilt auch unterhalb der Seitenlayout-Ebene: <a href> für Links, <button> für Aktionen auf der Seite, <table> für echte tabellarische Daten und zweckbasierte alt-Texte bei Bildern. Gefälschte Links aus gestylten <div>s sind der häufigste Barrierefreiheitsfehler – siehe die vollständige Liste im Tab „Erweitert“.

Das, was die meisten falsch verstehen

Das Verpacken Ihrer Inhalte in <article> verbessert nicht Ihr Ranking. Googles John Mueller hat gesagt, dass das <article>-Element „keine besondere Wirkung“ in der Google- Suche habe und dass semantisches HTML „kein magischer Multiplikator“ sei. Semantisches HTML hilft Suchmaschinen, Ihre Seite zu verstehen – es ist nur kein Hebel, den Sie ziehen, um höher zu ranken.

Der Wert ist real, nur eben keine „Ranking-Punkte“. Sauberes semantisches Markup erleichtert es Suchmaschinen, Ihren Hauptinhalt vom Beiwerk (Menüs, Fußzeilen, Anzeigen) zu unterscheiden, es sorgt dafür, dass Ihre Seite für Menschen mit Screenreadern ordnungsgemäß funktioniert, und es ist für KI-Tools leichter zu lesen. Das sind alles gute Gründe dafür – keiner davon ist „es ist ein Ranking-Faktor“.

Noch eine Falle: Semantisches HTML ist nicht dasselbe wie „Semantische SEO“. Semantisches HTML betrifft die Markup-Struktur. Semantische SEO betrifft Themen und Entitäten in Ihren Inhalten. Dasselbe Wort, völlig verschiedene Dinge.

Möchten Sie das vollständige Bild – was jedes Element signalisiert, was Google und Bing tatsächlich sagen, wie es in die Hauptinhalts-Extraktion passt, und eine Nachrüst-Checkliste? Wechseln Sie zum Tab Erweitert.

TL;DR — Semantisches HTML verwendet Elemente für ihre beabsichtigte strukturelle Bedeutung (<main>, <article>, <section>, <nav>, <header>, <aside>), sodass das Markup kommuniziert, was Inhalt ist, nicht wie er aussieht. Es ist kein Ranking-Faktor — Mueller: “kein magischer Multiplikator,” und <article> hat “keine besondere Wirkung.” Was es tut, ist Mehrdeutigkeit zu reduzieren: Googles Centerpiece-Annotation trennt Hauptinhalt von Boilerplate per NLP, unabhängig davon, ob Ihr Markup semantisch ist, aber saubere Semantik macht diese Aufgabe zuverlässiger. Bings Fabrice Canel formuliert es stärker (“ein Vorteil in der SEO”) — ich weise auf diese Diskrepanz ehrlich hin, statt sie wegzuharmonisieren. Googles eigener Starter Guide sagt, dass der größte Teil des Webs kein gültiges HTML ist, daher hängt es selten von Spezifikations-Semantik ab. Korrekte Verwendung schlägt Präsenz: ein <main>, <article> für eigenständigen Inhalt, <section> für eine thematische Gruppe mit Überschrift — kein <div>-Ersatz. Derselbe Test erstreckt sich auf <a href> vs. <button> (navigieren vs. handeln), echte <table>s für tabellarische Daten, zweckbasierte Bild-Alt-Texte und <details>/<summary> für Offenlegungs-Widgets — und verlassen Sie sich nicht darauf, dass <section> Verschachtelung eine Überschriftsebene impliziert; dieser “Document Outline Algorithm” wurde nie implementiert und die Spezifikation definiert Gliederungen nicht mehr so. Verwechseln Sie semantisches HTML nicht mit Semantic SEO.

Was semantisches HTML tatsächlich ist

Semantisches HTML ist die Praxis, HTML-Elemente für die strukturelle Bedeutung zu wählen, für die sie entwickelt wurden, statt für alles <div> und <span> zu verwenden. <article>, <section>, <nav>, <header>, <main>, <aside> und <footer> deklarieren jeweils eine Rolle. Das Markup beschreibt, was ein Teil der Seite ist; CSS entscheidet, wie es aussieht. Googles eigener Entwickler-Styleguide formuliert die Regel so einfach wie möglich: “Use HTML elements for the purposes that they were designed for.” (Übersetzung) Quelle „Verwenden Sie HTML-Elemente für die Zwecke, für die sie entwickelt wurden.“

Eine Sache, die Menschen verwirrt: Ein Klassenname erzeugt keine Semantik. Ein <div> mit class="article" oder class="main-nav" zu benennen, verleiht ihm nicht das Inhaltsmodell des <article>-Elements oder die implizite Navigationsrolle des <nav>-Elements — es bleibt für einen Browser, Screenreader oder Crawler ein generisches <div>. Semantik liegt in dem Element, das Sie wählen, nicht darin, wie Sie es stylen oder beschriften.

Dieser Artikel befasst sich speziell mit den semantischen Elementen. Das größere Bild “Wie Google Ihr HTML parst, Überschriftenhierarchie, Validität” gehört zum HTML-SEO-Hub, unter dem diese Seite liegt — ich werde darauf verweisen, statt es hier erneut zu behandeln.

Hilft semantisches HTML tatsächlich bei SEO?

Kurzantwort: Es hilft beim Verständnis, es ist kein Ranking-Faktor, und die beiden Suchmaschinen formulieren es etwas unterschiedlich. Hier ist die ehrliche Version.

Was Google sagt

Googles Linie, wiederholt von John Mueller, ist, dass semantisches HTML es wert ist, getan zu werden, aber kein Ranking-Hebel ist. Wie Search Engine Journal berichtete, sagte Mueller “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher,” (Übersetzung) Quelle „Semantisches HTML hilft beim Verständnis einer Seite. Es ist jedoch kein magischer Multiplikator, der eine Website höher ranken lässt.“ und separat: “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (Übersetzung) Quelle „Bitte verwenden Sie semantisches HTML. Es ist kein Ranking-Faktor, kann unseren Systemen aber helfen, Ihre Inhalte besser zu verstehen.“

Beim <article>-Element im Speziellen – dem, nach dem alle fragen – war Mueller in einer Office-Hours-Sitzung deutlich: Das <article>-Element “hat keinen besonderen Effekt in der Google-Suche,” und er fügte den Grund hinzu, es trotzdem zu verwenden: “Manchmal gibt es Barrierefreiheits- oder semantische Gründe, eine bestimmte Art von Markup zu verwenden, also konzentrieren Sie sich nicht nur auf SEO.”

Google sagt auch ausdrücklich, dass es nicht von perfekter Semantik abhängt. Der SEO-Leitfaden für Einsteiger stellt fest, dass “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (Übersetzung) Quelle „Eine semantische Überschriftenreihenfolge ist für Screenreader hervorragend. Aus Sicht der Google-Suche spielt die Reihenfolge jedoch keine Rolle. Das Web ist im Allgemeinen kein gültiges HTML, daher kann sich die Google-Suche nur selten auf in der HTML-Spezifikation verborgene semantische Bedeutungen verlassen.“ Das ist eine wichtige Nuance, kein Widerspruch: Semantisches HTML hilft an den Rändern, es erfordert keine Perfektion und es ist kein bewertetes Signal.

Wie es dazu passt, dass Google Ihre Hauptinhalte findet

Hier ist der Mechanismus, der semantisches HTML nützlich macht, obwohl es kein Ranking-Faktor ist. Google muss den Hauptinhalt einer Seite vom Boilerplate (Navigation, Kopfzeile, Fußzeile, Seitenleisten, Anzeigen) trennen, bevor es entscheiden kann, worum es auf einer Seite geht. Martin Splitt hat die Maschinerie beschrieben: “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (Übersetzung) Quelle „Wir haben beispielsweise eine sogenannte Centerpiece Annotation und einige weitere Annotationen, bei denen wir den semantischen Inhalt betrachten.“ (Übersetzung) „Wir haben zum Beispiel ein Ding namens Centerpiece Annotation, und es gibt ein paar andere Annotationen, bei denen wir uns den semantischen Inhalt ansehen.“ Die Art und Weise, wie Google das Thema ermittelt, ist die Verarbeitung natürlicher Sprache über den Inhalt, nicht die Tag-Namen: “This looks like from all the natural language processing that we did on this entire text content here that we got, it looks like this is primarily about topic A, dog food.” (Übersetzung) Quelle „Aus der Verarbeitung natürlicher Sprache für diesen gesamten Textinhalt ergibt sich, dass es hier hauptsächlich um Thema A, Hundefutter, geht.“ (Übersetzung) „Das sieht so aus, als ob es aufgrund der gesamten Verarbeitung natürlicher Sprache, die wir an diesem gesamten Textinhalt durchgeführt haben, den wir bekommen haben, so aussieht, als ginge es hier hauptsächlich um Thema A, Hundefutter.“ Und es gewichtet den Rest herunter: “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (Übersetzung) Quelle „Wir ermitteln, was wie Boilerplate aussieht, und gewichten es anschließend anders.“ (Übersetzung) „Wir finden heraus, was wie Boilerplate aussieht, und das wird dann auch anders gewichtet.“

Der entscheidende Punkt: Diese Extraktion funktioniert unabhängig davon, ob Ihr Markup semantisch ist oder nicht. Google kann eine Seite entwirren, die vollständig aus <div>s besteht. Aber direkt gefragt, ob semantisches HTML5 hilft, war Splitts Antwort “It does help us, but it’s not the only thing that we look for. Yes.” (Übersetzung) Quelle „Es hilft uns, aber es ist nicht das Einzige, wonach wir suchen. Ja.“ Semantisches HTML verschafft Ihnen also keine höhere Punktzahl – es reduziert die Ratespielerei in einem Schritt, den Google bereits durchführt, und genau deshalb ist es ein Vertrauens- und Effizienzsignal und kein Ranking-Signal. Um genau zu sagen, was es nicht tut: Korrektes semantisches Markup garantiert auch keine bestimmte Suchdarstellung – es ist eine separate Ebene von den Zulassungsregeln, die Rich Results regeln (mehr dazu weiter unten).

Was Bing sagt (und warum es sich unterscheidet)

Bing formuliert dies stärker als Google, und ich werde diesen Unterschied intakt lassen, anstatt ihn zu überdecken. Microsofts Fabrice Canel hat gesagt, dass Seiten mit korrekt implementiertem semantischem HTML5 “einen SEO-Vorteil” gegenüber solchen ohne haben. Das ist eine stärkere Aussage als Googles “hilft uns zu verstehen” – Bing verbindet semantisches HTML5 direkt mit einem SEO-Vorteil. Beide Suchmaschinen stimmen darin überein, dass es “mechanisch hilft”, aber sie verwenden nicht dieselben Worte, und Sie sollten das wissen, wenn Sie widersprüchliche Anleitungen lesen. Keiner von beiden beschreibt es, um es klar zu sagen, als einen bewerteten Ranking-Faktor so wie Links oder Relevanz.

Die zentralen semantischen Elemente und wie man sie korrekt verwendet

Präsenz ist nicht der Punkt – korrekte Verwendung ist es. Der häufigste Fehler ist, semantische Tags wie Dekoration zu verteilen oder <div> gegen <section> auszutauschen, ohne darüber nachzudenken, was jedes Element bedeutet.

<header> und <footer>

<header> enthält einleitende Inhalte und <footer> enthält abschließende Inhalte – und beide sind kontextbezogen. Auf Dokumentebene ist <header> Ihr Site-Banner und <footer> Ihr Site-Footer. Sie können aber auch innerhalb eines <article> oder <section> verschachtelt werden, um Intro und Outro dieses Blocks zu markieren (Titel/Byline eines Artikels in einem <header>, seine Tags in einem <footer>). Sie können viele davon haben; stellen Sie nur sicher, dass jeder Intro- oder Abschlussinhalte für seinen Kontext umschließt, nicht beliebige Boxen.

<nav>

<nav> ist für wesentliche Blöcke von Navigationslinks gedacht – Ihr Hauptmenü, Breadcrumb- Pfad oder ein In-Page-Inhaltsverzeichnis. Es ist nicht für jede Gruppe von Links auf der Seite gedacht (eine Liste verwandter Beiträge im Textkörper muss kein <nav> sein). Jede Linkgruppe in <nav> zu verpacken, verwässert das Signal; reservieren Sie es für echte Navigation.

<main>

<main> umschließt den primären, einzigartigen Inhalt der Seite – den Teil, der nicht über die Site wiederholt wird. Die Regel, die Menschen stolpern lässt: Es sollte genau ein <main> pro Seite geben, und es sollte nicht in <article>, <aside>, <header>, <footer> oder <nav> verschachtelt sein. Es ist das einzige klarste Signal, das Sie geben können, um zu sagen: “Dies ist der Inhalt, der hier zählt.”

<article> vs. <section> (das, das jeder falsch macht)

Dies ist die Unterscheidung, die Sie richtig machen sollten:

• <article> ist für in sich geschlossene, unabhängig verteilbare Inhalte gedacht – etwas, das auch dann noch Sinn ergäbe, wenn es aus der Seite herausgelöst und in einen Feed eingefügt würde. Ein Blog- Beitrag, eine Nachricht, eine Produktkarte, ein Forenbeitrag, ein einzelner Nutzerkommentar. Wenn es eigenständig syndiziert werden könnte, ist es ein <article>.
• <section> ist eine thematische Gruppierung von Inhalten, die eine eigene Überschrift haben sollte. Ein “Bewertungen”-Block, ein “Spezifikationen”-Block, ein Kapitel. Der Test: Wenn der Inhalt ohne Überschrift keinen Sinn ergibt, ist es wahrscheinlich kein <section> – und wenn Sie es nur verwenden, um CSS daran zu hängen, sollte es ein <div> sein.

<section> ist kein generischer Wrapper. Wenn Sie einen Styling-Haken ohne semantische Bedeutung benötigen, verwenden Sie <div> – genau dafür ist es da. Zu <section> zu greifen, weil es “moderner wirkt”, ist der häufigste Fehlgebrauch.

<aside>

<aside> markiert Inhalte, die nebensächlich zum umgebenden Inhalt sind – eine Seitenleiste, ein Pull-Quote, eine Box mit verwandten Links, eine Reihe von Anzeigen. Es signalisiert “Dies ist verwandt, aber nicht der Hauptstrang”, was genau die Unterscheidung zwischen Boilerplate und Hauptinhalt ist, die Google ohnehin zu ziehen versucht. Verwenden Sie es nicht nur, weil etwas visuell zur Seite steht; verwenden Sie es, wenn der Inhalt wirklich sekundär ist.

Die Landmark-Rollen richtig setzen (und der Outline-Mythos)

Jedes Landmark-Element wird auf eine spezifische implizite ARIA – Rolle abgebildet, die assistive Technologie direkt liest – dies ist dieselbe berechnete Struktur, nach der sich ein nicht-visueller Nutzer navigiert, und es lohnt sich, die tatsächliche Zuordnung zu kennen, anstatt anzunehmen:

Ein Stück Folklore, das man getrost verabschieden kann: Das Verschachteln einer <section> verleiht ihren Überschriften keine implizite niedrigere Rangstufe. Frühes HTML5 definierte einen Document Outline Algorithm, der die effektive Ebene einer Überschrift aus der Verschachtelungstiefe in Sectioning-Elementen berechnet hätte – so könnte ein verschachteltes <h1> theoretisch „wie ein“ <h2> wirken. Kein Browser und kein Screenreader hat diesen Algorithmus jemals implementiert, und die WHATWG-Spezifikation hat ihn inzwischen zugunsten einer viel einfacheren Definition verworfen: Die Gliederung ist einfach alle Überschriften im Dokument in Baumreihenfolge. Schreiben Sie Ihre <h1>–<h6>-Ebenen explizit und in der Reihenfolge, in der Sie diese tatsächlich gelesen haben möchten – die Verschachtelungstiefe übernimmt diese Arbeit nicht für Sie.

Links vs. Buttons – der Test für Aktion versus Navigation

Dieses Element ist keine Landmark, aber es ist der häufigste semantische Fehler im Web: ein gestyltes <div> oder <span> (oder ein <button>) zu verwenden, wo ein <a href> hingehört, oder umgekehrt. Die WHATWG-Spezifikation ist eindeutig – <a> mit einem href-Attribut ist der native Hyperlink-Mechanismus, und das <button>-Element ist ein beschriftetes interaktives Steuerelement zum Auslösen einer Aktion. Der Test ist einfach: Führt dieses Element den Benutzer zu etwas (einer neuen URL, einer neuen Seite, einem Fragment)? Verwenden Sie <a href>. Tut es etwas auf der aktuellen Seite (ein Formular absenden, ein Modal öffnen, eine Einstellung umschalten)? Verwenden Sie <button>. Ein Element so zu stylen, dass es wie das andere aussieht, ändert nicht, was es nativ ist – ein <div> mit einem Klick-Handler erhält weder die native Tastatur-Aktivierung noch die korrekte zugängliche Rolle, es sei denn, Sie bauen das alles selbst mit role, tabindex und Tasten-Handlern nach. Verwenden Sie einfach das richtige Element.

Tabellen sind für tabellarische Daten, nicht für Layout

Wenn Inhalte tatsächlich Zeilen und Spalten haben – eine Vergleichstabelle, ein Preistabelle, ein Datensatz – verwenden Sie eine echte <table>, nicht ein Raster aus gestylten <div>s. Die WHATWG-Tabellen-Spezifikation definiert ein echtes Datenmodell: <caption> benennt die Tabelle, und <th>-Kopfzellen (mit scope) stellen die Zeilen-/Spaltenbeziehungen her, die es assistiven Technologien ermöglichen, „Preis, 49 $“ anzusagen, statt nur eine Wand aus Zahlen. Ein visuell tabellenähnliches Raster aus <div>s trägt keine dieser Beziehungsdaten – es sieht richtig aus, liest sich aber nicht richtig. Verwenden Sie <table> auch nicht für das Seitenlayout; das ist der ältere Missbrauch, den diese Praxis ersetzt hat.

Alt-Text hängt davon ab, wofür das Bild gedacht ist

<img> benötigt ein alt-Attribut, aber die Anforderungen der WHATWG-Spezifikation sind zweckabhängig, nicht Einheitsgröße: Ein Produktfoto benötigt eine Beschreibung dessen, was gezeigt wird; ein rein dekoratives Bild sollte alt="" erhalten (leer, nicht fehlend), damit assistive Technologien es überspringen, statt einen Dateinamen anzusagen; ein Bild, das auch ein Link ist, benötigt Alt-Text, der das Ziel oder die Aktion des Links beschreibt, nicht nur das Bild. Verwenden Sie nicht standardmäßig keyword-gefüllten Alt-Text auf jedem Bild „für SEO“ – das ist der falsche Test. Der richtige Test ist: Was muss ein Screenreader-Benutzer wissen, das er sonst verpassen würde?

Native Disclosure-Widgets: <details> und <summary>

Für Inhalte zum „Klicken zum Erweitern“ – FAQs, Spezifikationsblätter, Spoiler-Text – ist das <details>/<summary>-Paar ein natives Offenlegungs-Widget: <summary> ist das immer sichtbare Label, und der Inhalt innerhalb von <details> wird basierend auf dem open-Zustand des Elements ein- oder ausgeblendet, ohne JavaScript. Es bietet integrierte Tastaturunterstützung und die richtigen Barrierefreiheits-Semantiken kostenlos – ein benutzerdefiniertes <div>-plus-JavaScript-Akkordeon zu verwenden, bedeutet, Verhalten neu zu implementieren, das der Browser bereits bietet. Testen Sie es jedoch in Ihren tatsächlichen Zielbrowsern und Screenreadern, bevor Sie es ausliefern – die Darstellung und Offenlegung im Barrierefreiheitsbaum für <details>/<summary> hat historisch je nach Browser- und Assistenztechnologie-Kombination variiert, also gehen Sie nicht von Parität aus, die Sie nicht überprüft haben.

Häufige Mythen über semantisches HTML und SEO

1. „Das Einbetten von Inhalten in <article> verbessert Rankings.“ Nein – Mueller: das <article>-Element „hat keinen besonderen Effekt in der Google-Suche.“
2. „Semantisches HTML ist ein Ranking-Faktor.“ Nein – „kein magischer Multiplikator“ und „Es ist kein Ranking-Faktor, aber es kann unseren Systemen helfen, Ihre Inhalte besser zu verstehen.“
3. „Google erfordert gültiges/strenges semantisches HTML.“ Nein – laut dem Starter Guide, ist der größte Teil des Webs kein gültiges HTML und Google „kann sich selten auf semantische Bedeutungen verlassen, die in der HTML-Spezifikation versteckt sind.“
4. „Die Überschriftenreihenfolge muss für SEO perfekt sein.“ Screenreader kümmern sich darum; das Google-Ranking nicht (gleiche Zeile im Starter Guide). Die tiefere Behandlung der Überschriftenhierarchie gehört zum HTML-SEO-Hub – dies ist nur die Kurzversion.
5. „Semantisches HTML und semantische SEO sind dasselbe.“ Nein – das eine ist Markup-Struktur, das andere ist thematische/Entitäts-Inhaltsstrategie. Sie zu vermischen ist der Grund, warum so viele Suchergebnisse für „semantische“ Suchanfragen das falsche Thema betreffen.
6. „Strukturierte Daten machen semantisches HTML überflüssig.“ Nein – sie ergänzen sich. Semantisches HTML gibt Ihren strukturierten Daten eine vertrauenswürdigere Grundlage; es ersetzt sie nicht, und JSON-LD behebt keine Div-Suppe. Und keines von beiden garantiert ein Ergebnis: Googles eigene Einführung zu strukturierten Daten ist explizit, dass die Verwendung unterstützter Markups kein Rich Result garantiert – die Berechtigung für ein bestimmtes Suchfeature ist ein separates Regelwerk davon, ob Ihr Markup (semantisches HTML oder JSON-LD) technisch gültig ist.
7. „Das Verschachteln eines <section> gibt seinen Überschriften eine implizite niedrigere Ebene – Sie müssen nicht von <h1> auf <h2> innerhalb einer verschachtelten Sektion wechseln.“ Nein – dies ist ein Überbleibsel des alten Document Outline Algorithmus von HTML5, der eine implizite Überschriftenebene aus der Verschachtelung von Sektionselementen berechnet hätte. Kein Browser oder Screenreader hat es jemals implementiert, und die WHATWG-HTML-Spezifikation definiert die Outline-Berechnung nicht mehr auf diese Weise – die Outline heute ist einfach „alle Überschriften im Dokument, in Baumreihenfolge.“ Verwenden Sie explizite, korrekt geordnete <h1>–<h6> unabhängig davon, wie tief Ihre <section>/<article>-Verschachtelung geht; verlassen Sie sich nicht darauf, dass die Verschachtelung die Überschriftenebenen-Arbeit für Sie übernimmt.

Semantisches HTML vs. semantische SEO – verwechseln Sie diese nicht

Da sie sich ein Wort teilen, werden diese ständig verwechselt, und das verschmutzt die Suchergebnisse für beide:

• Semantisches HTML = das Markup – welche Elemente Sie zur Strukturierung einer Seite verwenden.
• Semantische SEO = eine Content-Strategie – den Aufbau von thematischer Autorität rund um Entitäten und verwandte Konzepte (die Art von Thema, das unter den Säulen KI-Suche und Content liegt, nicht hier).

Wenn Sie über eine „Semantic SEO“-Suchanfrage hierhergekommen sind und Themenmodellierung erwarten, ist das ein anderer Artikel. Dieser hier befasst sich ausschließlich mit den Elementen.

Semantisches HTML und KI-/LLM-Crawler

Hier wird semantisches HTML still und leise relevanter. Ich kennzeichne das als Branchenmeinung, nicht als Aussage einer Suchmaschine. Viele LLM-Crawler und KI-Antwortmaschinen rendern kein JavaScript — sie parsen das ausgelieferte HTML. Sauberes semantisches Markup lässt sich für sie erheblich leichter verarbeiten als tief verschachtelte <div>-Suppe. Barry Adams formuliert es so: “It’s much simpler for ChatGPT to parse a few dozen semantic HTML tags rather than several hundred (or even thousand) nested <div> tags,” (Übersetzung) „Für ChatGPT ist es viel einfacher, einige Dutzend semantische HTML-Tags zu parsen als mehrere Hundert oder sogar Tausend verschachtelte <div>-Tags.“ Quelle Allgemeiner schreibt er: “Semantic HTML markup on your webpages can help machine systems better understand your content and its value.” (Übersetzung) „Semantisches HTML-Markup auf Ihren Webseiten kann maschinellen Systemen helfen, Ihre Inhalte und deren Wert besser zu verstehen.“ Quelle Jono Alderson vertritt denselben zukunftsorientierten Standpunkt: Eine Website sei “an interface. An API. A dataset,” (Übersetzung) „eine Schnittstelle, eine API, ein Datensatz“, nicht nur ein visuelles Erlebnis. Quelle Sein Einzeiler fasst das Argument für korrekte Verwendung zusammen: “If everything is a <div> or a <span>, then nothing is meaningful.” (Übersetzung) „Wenn alles ein <div> oder ein <span> ist, hat nichts eine Bedeutung.“ Quelle Betrachten Sie all dies als guten richtungsweisenden Grund für sauberes Markup, nicht als Versprechen von Google oder Bing.

So prüfen und modernisieren Sie bestehende Seiten

Die meisten echten Websites sind bereits Div-Suppe, und Sie bauen sie nicht über Nacht neu auf. Eine pragmatische Reihenfolge für die Nachrüstung:

• Zuerst die Landmarken festlegen. Stellen Sie sicher, dass es genau ein <main>, einen Dokument-<header>, <footer> und ein <nav> für das Hauptmenü gibt. Diese Landmark-Elemente leisten die meiste Arbeit sowohl für die Extraktion des Hauptinhalts als auch für die Barrierefreiheit.
• In sich geschlossene Blöcke in <article> umwandeln. Blogbeiträge, Produktkarten, Kommentare – alles, was in einem Feed eigenständig stehen könnte.
• Echte thematische Gruppen in <section> umwandeln – aber nur dort, wo es eine echte Überschrift gibt. Wenn es keine gibt, lassen Sie es ein <div>.
• Sidebars und verwandte Inhaltsboxen in <aside> verschieben.
• Fake-Links und Fake-Buttons beheben. Ein gestyltes <div> mit einem Klick-Handler sollte zu einem <a href> (wenn es navigiert) oder einem <button> (wenn es auf der Seite agiert) werden – das ist in der Regel die wertvollste einzelne Korrektur für Tastatur- und Screenreader-Nutzer.
• Tabellenartige Raster aus <div>s in echte <table>s umwandeln, wenn der Inhalt wirklich tabellarisch ist, mit <caption> und <th> für die Kopfzellen.
• Nicht überkonvertieren. Ein <div>, das rein als Styling-/Layout-Hook verwendet wird, ist korrekt. Nicht alles braucht ein semantisches Element; eines zu erzwingen ist selbst ein Fehler.
• Verifizieren, nicht annehmen. Überprüfen Sie den Accessibility-Baum in den DevTools Ihres Browsers – er zeigt die Landmark-Rollen, die Ihr Markup erzeugt, was dieselbe Struktur ist, welche die Maschinen lesen.

Wie dies in den HTML-SEO-Hub passt

Dieser Artikel ist ein Deep Dive unter dem übergeordneten HTML-SEO-Hub, der die breitere Frage behandelt, wie Suchmaschinen Ihr HTML parsen und verwenden – Überschriftenhierarchie, HTML-Gültigkeit und wie nachsichtige Parser mit unordentlichem Markup umgehen. Ich habe diese Seite bewusst auf die semantischen Elemente selbst beschränkt und diese Themen dem Hub und seinen Schwesterartikeln überlassen. Semantisches HTML passt auch direkt zu strukturierten Daten: Das Markup gibt Ihrem Schema eine vertrauenswürdige Grundlage, und beide erfüllen komplementäre Aufgaben.

Häufig gestellte Fragen

Hilft semantisches HTML bei SEO oder ist es nur für Barrierefreiheit? Beides – es hilft Suchmaschinen, Ihre Hauptinhalte zu identifizieren, und es ist für Barrierefreiheit unerlässlich. Es ist jedoch kein Ranking-Faktor.

Verbessert die Verwendung des <article>-Tags das Ranking? Nein. Mueller: Es “hat keinen besonderen Effekt in der Google-Suche.” (Übersetzung) „hat keinen besonderen Effekt in der Google-Suche.“

Was ist der Unterschied zwischen <article> und <section>? <article> ist eigenständiger Inhalt, der allein in einem Feed stehen könnte; <section> ist eine thematische Gruppierung mit eigener Überschrift. Keines ist ein Ersatz für <div>.

Kann ich mehr als ein <main>-Element auf einer Seite haben? Nein – ein <main> pro Seite.

Verlangt Google gültiges HTML, um eine Seite zu ranken? Nein – der größte Teil des Webs ist kein gültiges HTML, und Google “kann sich selten auf semantische Bedeutungen verlassen, die in der HTML-Spezifikation versteckt sind.” (Übersetzung) „kann sich selten auf semantische Bedeutungen verlassen, die in der HTML-Spezifikation versteckt sind.“

Ist semantisches HTML dasselbe wie semantische SEO? Nein – das eine ist Markup, das andere ist thematische/Entitäts-Inhaltsstrategie.

Sollte ich <a> oder <button> für ein klickbares Element verwenden? Hängt davon ab, was es tut. Wenn es zu einer URL oder einem Fragment navigiert, verwenden Sie <a href>. Wenn es eine Aktion auf der aktuellen Seite ausführt (Absenden, Umschalten, Öffnen eines Modals), verwenden Sie <button>. Fälschen Sie keines mit einem gestylten <div> und einem Klick-Handler.

Ändert die Verschachtelung von <section>, welche Überschriftenebene ich verwenden sollte? Nein. Der alte Dokumentgliederungsalgorithmus von HTML5 – der eine implizite Überschriftenrangfolge aus der Verschachtelung von Sektionen berechnet hätte – wurde von keinem Browser oder Screenreader implementiert, und die aktuelle Spezifikation definiert Gliederungen nicht auf diese Weise. Verwenden Sie explizite, korrekt geordnete <h1>–<h6> unabhängig von der Verschachtelungstiefe.

Garantiert korrektes semantisches HTML oder strukturierte Daten ein Rich Result? Nein. Googles eigene Dokumentation zu strukturierten Daten besagt, dass unterstütztes Markup keine bestimmte Suchdarstellung garantiert – die Berechtigung für eine Funktion ist getrennt davon, ob Ihr Markup technisch gültig ist.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Semantisches HTML = Elemente für ihre beabsichtigte Bedeutung verwenden (<main>, <article>, <section>, <nav>, <header>, <aside>, <footer>), sodass das Markup sagt, was der Inhalt ist. CSS übernimmt das Aussehen.
• Kein Ranking-Faktor. Mueller: “not a magical multiplier” (Übersetzung) „kein magischer Multiplikator“; das <article>-Element hat “no particular effect” (Übersetzung) „keine besondere Auswirkung“ in der Google-Suche. Verwenden Sie es für Barrierefreiheit/Klarheit, nicht für Ranking-Punkte.
• Es hilft bei der Extraktion des Hauptinhalts. Googles Centerpiece-Annotation trennt den Hauptinhalt von Boilerplate per NLP unabhängig vom Markup (Splitt), funktioniert also auch bei Div- Suppe – aber semantisches Markup reduziert die Rätselrate. Splitt: “It does help us, but it’s not the only thing that we look for.” (Übersetzung) „Es hilft uns, ist aber nicht das einzige Kriterium.“
• Google verlangt kein valides HTML. Starter Guide: Der Großteil des Webs ist nicht valide, daher kann Google “can rarely depend on semantic meanings hidden in the HTML specification.” (Übersetzung) „kann sich selten auf semantische Bedeutungen in der HTML-Spezifikation verlassen.“
• Bing formuliert es stärker. Fabrice Canel: Semantisches HTML5 bringt “an advantage in SEO.” (Übersetzung) „einen SEO-Vorteil“ Beachten Sie die Lücke ehrlich – Bings Formulierung ist stärker als die von Google; keiner nennt es einen bewerteten Ranking-Faktor.
• Korrekte Verwendung schlägt Präsenz: ein <main>; <article> = in sich geschlossen; <section> = thematische Gruppe mit einer Überschrift, kein <div>-Ersatz; <nav> = nur Hauptnavigation; <aside> = ergänzender Inhalt.
• Landmark-Elemente bilden spezifische implizite ARIA-Rollen ab (<header>→banner, <nav>→navigation, <main>→main, <aside>→complementary, <footer>→contentinfo – nur auf Dokumentebene; verschachtelt in einem Abschnitt sind sie keine Landmarks). <section> ist nur ein Landmark (region), wenn es einen zugänglichen Namen hat; <article> ist überhaupt kein Landmark.
• Der Mythos des Dokumentgliederungsalgorithmus: Das Verschachteln eines <section> verleiht seinen Überschriften keine implizite niedrigere Rangstufe. Dieser Algorithmus wurde nie von einem Browser oder Screenreader implementiert, und die WHATWG-Spezifikation definiert Gliederungen nicht mehr auf diese Weise – schreiben Sie explizite <h1>–<h6>-Ebenen.
• Über Landmarks hinaus: Verwenden Sie <a href> für Navigation vs. <button> für Aktionen auf der Seite; echte <table>s (mit <caption>/<th>) für tabellarische Daten, nicht <div>-Raster; zweckbasierter alt-Text auf Bildern (alt="" für dekorative); <details>/<summary> für native Offenlegungs-Widgets – testen Sie die Browser/AT-Darstellung vor der Veröffentlichung.
• KI/LLM-Winkel (Branchenmeinung): LLM-Crawler rendern oft kein JS, daher ist sauberes semantisches HTML einfacher zu parsen als verschachtelte <div>s (Adams, Alderson).
• Nicht mit Semantic SEO verwechseln (Entitäts-/Themenstrategie) – gleiches Wort, andere Sache. Strukturierte Daten ergänzen semantisches HTML, ersetzen es aber nicht, und keines garantiert ein Rich Result oder einen Ranking-Gewinn.

Offizielle Dokumentation

Primärquellen-Dokumentation und Stilrichtlinien von Suchmaschinen und Standardisierungsgremien.

Google

• SEO-Leitfaden für Einsteiger – der Abschnitt “things you shouldn’t focus on”, einschließlich des Hinweises zu Überschriftenreihenfolge / semantischen Bedeutungen.
• Google-Styleguide für HTML und semantische Auszeichnung – “Use HTML elements for the purposes that they were designed for.” (Übersetzung) „Verwenden Sie HTML-Elemente für die Zwecke, für die sie entwickelt wurden.“
• web.dev – Learn HTML: Semantic HTML – Googles eigenes Lernmodul zu Landmark-Elementen und ihren Barrierefreiheitsrollen.

Standards / Referenz

• MDN — Semantics (Glossar) — die kanonische Definition von semantischen Elementen im Vergleich zu nicht-semantischen Wrappern.
• WHATWG HTML Living Standard — Sections — Definitionen von <article>, <section>, <nav>, <aside>, <header>, <footer>, Inhaltsmodelle und die aktuelle (nicht-algorithmische) Definition der Dokumentgliederung.
• WHATWG HTML Living Standard — Links — das <a>-Element und Hyperlink-Semantik.
• WHATWG HTML Living Standard — Das button-Element — native Semantik interaktiver Steuerelemente.
• WHATWG HTML Living Standard — Tabellendaten — Semantik von <table>, <caption>, Kopfzellen und Datenbeziehungen.
• WHATWG HTML Living Standard — Bilder — Anforderungen an Alternativtext für <img> nach Zweck/Kontext.
• WHATWG HTML Living Standard — Die details- und summary-Elemente — das native Offenlegungs-Widget.
• MDN — ARIA-Rollenreferenz — implizite Landmark-Rollen-Zuordnungen für die Abschnittselemente.
• W3C WAI — Tutorial zur Seitenstruktur — wie native Regionen und Überschriften die Navigation mit assistiven Technologien unterstützen.

Bing / Microsoft

• Kalicube — HTML5-Semantik-Tags (Fabrice Canel) — die Quelle für Canels Position zum „Vorteil in SEO“ bei semantischem HTML5.

Zitate aus der Quelle

Öffentliche Aussagen von Google und Bing. Wo die Quellseite es unterstützt, ist jeder Link ein Deep Link, der direkt zur zitierten Passage springt.

Google — kein Ranking-Faktor (John Mueller)

• “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher.” (Übersetzung) „Semantisches HTML hilft tatsächlich, eine Seite zu verstehen. Es ist jedoch kein magischer Multiplikator, um eine Website höher ranken zu lassen.“ — John Mueller, Google, über Search Engine Journal. Berichterstattung lesen
• “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (Übersetzung) „Bitte verwenden Sie semantisches HTML. Es ist kein Ranking-Faktor, aber es kann unseren Systemen helfen, Ihre Inhalte besser zu verstehen.“ — John Mueller, Google, gleiche Quelle. Berichterstattung lesen

Google — das <article>-Element speziell (John Mueller)

• “The <article> HTML element does not have any particular effect in Google Search.” (Übersetzung) „Das <article>-HTML-Element hat keine besondere Wirkung in der Google-Suche.“ — John Mueller, Google SEO Office Hours, über Search Engine Journal. Berichterstattung lesen
• “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (Übersetzung) „Manchmal gibt es Zugänglichkeits- oder semantische Gründe, eine bestimmte Art von Markup zu verwenden, also konzentrieren Sie sich nicht nur auf SEO.“ — John Mueller, Google SEO Office Hours, gleiche Quelle. Berichterstattung lesen

Google — Extraktion des Hauptinhalts (Martin Splitt)

• “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (Übersetzung) „Wir haben beispielsweise eine sogenannte Centerpiece Annotation und einige weitere Annotationen, bei denen wir den semantischen Inhalt betrachten.“ — Martin Splitt, Google, via Search Engine Journal. Berichterstattung lesen
• “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (Übersetzung) „Wir ermitteln, was wie Boilerplate aussieht, und gewichten es anschließend anders.“ — Martin Splitt, dieselbe Quelle. Berichterstattung lesen
• “It does help us, but it’s not the only thing that we look for. Yes.” (Übersetzung) „Es hilft uns, aber es ist nicht das Einzige, wonach wir suchen. Ja.“ — Martin Splitt, answering directly whether semantic HTML5 helps Google. Jump to quote

Google — hängt nicht von gültiger/Spezifikations-Semantik ab (SEO-Starteranleitung)

• “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (Übersetzung) „Semantisch geordnete Überschriften sind für Screenreader ausgezeichnet; der Google-Suche ist eine abweichende Reihenfolge jedoch gleichgültig. Da das Web insgesamt kein valides HTML ist, kann Google nur selten auf semantische Bedeutungen vertrauen, die in der HTML-Spezifikation verborgen sind.“ — Google SEO Starter Guide. Jump to quote

Google — Elemente für ihren Zweck verwenden (Style Guide)

• “Use HTML elements for the purposes that they were designed for.” (Übersetzung) „Verwenden Sie HTML-Elemente für die Zwecke, für die sie entwickelt wurden.“ — Google Developer Documentation Style Guide. Quelle lesen

Bing / Microsoft (Fabrice Canel)

• Fabrice Canel von Microsoft Bing hat gesagt, dass Seiten mit korrekt implementiertem semantischem HTML5 einen SEO-Vorteil gegenüber solchen ohne haben – Bings Formulierung ist stärker als Googles „hilft beim Verständnis“, wird aber dennoch nicht als bewerteter Ranking-Faktor beschrieben. Paraphrasiert, nicht wörtlich zitiert: Dies erfolgt über eine Sekundärquelle (Kalicube), nicht über eine abgerufene Bing-Primärquelle – bestätigen Sie die genaue Formulierung anhand des Originals, bevor Sie es als direktes Zitat behandeln. Quelle lesen

Welches Element braucht dieser Block?

Die Frage Artikel-vs-Abschnitt-vs-Div (und die übrigen Landmark-Entscheidungen) ist eine echte Verzweigung, keine Stilpräferenz. Beantworten Sie jeden Schritt ehrlich – der Test ist immer „was tut dieser Inhalt tatsächlich“, nicht „was sieht moderner aus“.

Was Sie nicht tun sollten

Dies sind die tatsächlichen Fehler, auf welche die obigen Mythen hinweisen – jeweils mit dem Grund, warum sie falsch sind, und was Sie stattdessen tun sollten.

• Inhalt in <article> einwickeln, in der Erwartung eines Ranking-Boosts. Warum es falsch ist: Mueller hat gesagt, das Element „hat keinen besonderen Effekt in der Google-Suche.“ Was Sie stattdessen tun sollten: Verwenden Sie <article>, wenn der Inhalt wirklich in sich geschlossen ist (in einem Feed allein stehen könnte), für Barrierefreiheit und Klarheit – nicht als SEO-Hebel.

• Semantisches HTML generell als bewerteten Ranking-Faktor zu behandeln. Warum das falsch ist: Es ist “kein magischer Multiplikator” und es gibt kein bewertetes Signal, dem man hinterherjagen könnte. Was stattdessen zu tun ist: Planen Sie die Arbeit als Investition in Verständlichkeit/Barrierefreiheit mit einem realen (wenn auch nicht als Ranking messbaren) Nutzen, nicht als Ranking-Projekt mit erwartetem Anstieg.

• Auf perfekte Überschriftenreihenfolge oder strikte Validität allein für Google zu bestehen. Warum das falsch ist: Googles eigener Starter Guide sagt “the web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (Übersetzung) „Das Web im Allgemeinen ist kein gültiges HTML, daher kann sich die Google-Suche selten auf semantische Bedeutungen verlassen, die in der HTML-Spezifikation verborgen sind.“ Quelle Was stattdessen zu tun ist: Korrigieren Sie Überschriftenreihenfolge und Validität für Screenreader und Nutzer — dort kommt es tatsächlich darauf an —, nicht weil Google sie bewertet.

• <section> als Ersatz für <div> zu verwenden, weil es “moderner wirkt”. Warum das falsch ist: <section> ohne Überschrift ist keine thematische Gruppierung, sondern Dekoration – das ist der häufigste Missbrauch des Elements. Was stattdessen zu tun ist: Wenn der Block ohne eigene Überschrift keinen Sinn ergibt, verwenden Sie <div>.

• Semantisches HTML mit semantischer SEO zu verwechseln. Warum das falsch ist: Das eine ist Markup-Struktur, das andere ist thematische/Entitäts-Inhaltsstrategie – sie zu vermischen bedeutet, das Falsche für das Ziel zu optimieren, das Sie tatsächlich haben. Was stattdessen zu tun ist: Halten Sie die beiden getrennt; dieser Artikel behandelt nur die Elemente.

• Semantisches HTML zu überspringen, weil strukturierte Daten bereits existieren. Warum das falsch ist: JSON-LD behebt keine Div-Suppe, und strukturierte Daten sind kein Ersatz für Markup-Struktur. Was stattdessen zu tun ist: Verwenden Sie beides – strukturierte Daten sitzen auf einem semantischen Fundament, sie ersetzen es nicht. Keines von beiden garantiert auch ein Rich Result – das ist eine separate Eignungsfrage von der Markup-Validität.

• <section>-Elemente zu verschachteln, um Überschriften “wie” eine niedrigere Ebene wirken zu lassen. Warum das falsch ist: Dies stützt sich auf den alten Dokumentgliederungsalgorithmus von HTML5, den kein Browser oder Screenreader je implementiert hat und den die aktuelle WHATWG-Spezifikation nicht mehr so definiert. Was stattdessen zu tun ist: Schreiben Sie explizite, korrekt geordnete <h1>–<h6>-Ebenen – lassen Sie nicht die Verschachtelungstiefe für die Überschriftenebene einstehen, die Sie tatsächlich meinen.

• Ein <div> mit einem Klick-Handler anstelle von <a href> oder <button> zu verwenden. Warum das falsch ist: Sie verlieren die native Tastatur-Aktivierung und die korrekte zugängliche Rolle, es sei denn, Sie bauen beides manuell mit role, tabindex und Tasten-Handlern wieder auf. Was stattdessen zu tun ist: Verwenden Sie <a href>, wenn die Aktion irgendwohin navigiert, <button>, wenn sie etwas auf der aktuellen Seite tut – und erhalten Sie das native Verhalten kostenlos.

Landmark-Elemente auf einen Blick

Die sieben Elemente, welche dieser Artikel behandelt, wofür jedes tatsächlich gedacht ist und das Missbrauchsmuster, das es zu vermeiden gilt.

Faustregel: Wenn ein Block eigenständig syndiziert werden könnte, ist es <article>; wenn er eine Überschrift braucht, um Sinn zu ergeben, ist es <section>; wenn beides nicht zutrifft, ist es ein <div>.

Über Landmarks hinaus: interaktive und Datenelemente

Prompts für die Nachrüstung von HTML

Kopierfertige Prompts für die spezifische Aufgabe, welche dieser Artikel behandelt: Div-Suppe finden und in korrektes semantisches Markup umwandeln. Fügen Sie den HTML-Code Ihrer Seite (View-Source, nicht das gerenderte DOM) mit einem dieser Prompts in einen KI-Assistenten ein.

Div-Suppe markieren und Ersatz vorschlagen

Here is the HTML for one of my pages. Identify every <div> or <span> that is standing
in for a semantic landmark, and suggest the correct replacement element from this list:
header, nav, main, article, section, aside, footer. For each suggestion, explain which
test it passes (e.g. "this could stand alone in a feed, so it's an <article>" or "this
has its own heading and one theme, so it's a <section>"). Flag any block that should
stay a <div> because it's purely a styling/layout hook.

[paste HTML here]

Auf strukturelle Fehler bei Landmarks prüfen

Review this page's HTML for these specific structural mistakes: more than one <main>
element, a <main> nested inside <article>/<aside>/<header>/<footer>/<nav>, a <nav>
wrapping something that isn't major navigation, or a <section> with no heading. List
each problem found with the line/snippet and the fix.

[paste HTML here]

Eine Reihenfolge für die Nachrüstung priorisieren

Given this page's HTML, tell me which landmark to fix first for the biggest
accessibility and main-content-extraction benefit: establishing <main>/<header>/
<footer>/<nav>, converting self-contained blocks to <article>, converting themed
groups to <section>, or moving sidebars to <aside>. Order the fixes and say what
"done" looks like for each.

[paste HTML here]

Landmarks entsprechen Ihrer beabsichtigten Struktur

Durchzuführender Test: Öffnen Sie den Accessibility-Baum der DevTools Ihres Browsers (Chrome/Edge: DevTools → Elements → Accessibility-Bereich) auf der nachgerüsteten Seite. Erwartetes Ergebnis: Die aufgeführten Landmark-Rollen (banner, navigation, main, complementary, contentinfo) entsprechen den semantischen Elementen, die Sie tatsächlich geschrieben haben – eine main/„main“-Rolle, ein banner usw. Fehlerinterpretation: Eine fehlende oder doppelte Landmark-Rolle bedeutet, dass das Markup nicht die Struktur erzeugt hat, die Sie beabsichtigt haben (z. B. ein zweites <main> oder ein <div>, das hätte umgewandelt werden sollen). Überwachungszeitraum: Sofort – direkt nach dem Bereitstellen der Nachrüstung prüfen. Rollback-Auslöser: Mehr als eine main/„main“-Landmark oder eine Landmark, die verschachtelt ist, wo sie nicht sein sollte (z. B. main in article), bedeutet Rückgängigmachen und erneutes Prüfen des Markups.

Genau ein <main> pro Seite

Durchzuführender Test: grep -o "<main" page.html | wc -l gegen das gerenderte HTML (oder View-Source) ausführen oder in DevTools’ Elements-Bereich nach <main suchen. Erwartetes Ergebnis: Genau eine Übereinstimmung. Fehlerinterpretation: Null Übereinstimmungen bedeutet, dass keine Landmark für den primären Inhalt gesetzt wurde; mehr als eine bedeutet, dass das „einzige klarste Signal“ für den Hauptinhalt jetzt mehrdeutig ist. Überwachungszeitraum: Sofort, zum Zeitpunkt der Bereitstellung. Rollback-Auslöser: Jede Anzahl außer genau einer.

Nicht rendernde Crawler sehen die Struktur trotzdem

Durchzuführender Test: Rufen Sie die Seite mit einem einfachen HTTP-Client ab (curl oder „Seitenquelltext anzeigen“, nicht das gerenderte DOM) und bestätigen Sie, dass die semantischen Elemente in der Rohantwort vorhanden sind und nicht erst später durch clientseitiges JavaScript eingefügt werden. Erwartetes Ergebnis: <header>, <nav>, <main>, <article>/<section>, <aside> und <footer> erscheinen alle in der ursprünglichen HTML-Auslieferung. Fehlerinterpretation: Wenn die semantischen Tags erst nach der JS-Ausführung erscheinen, sehen Crawler, die kein JavaScript rendern (gemäß dem obigen Punkt zu AI/LLM-Crawlern), die Struktur überhaupt nie. Überwachungszeitraum: Sofort – erneut prüfen, sobald Templating oder ein JS-Framework die Darstellung der Seite ändert. Rollback-Auslöser: Semantische Landmarken sind im gerenderten DOM vorhanden, fehlen jedoch in der rohen HTML-Antwort.

Überschriftenebenen sind explizit, nicht von der Verschachtelung geerbt

Durchzuführender Test: Listen Sie im Accessibility-Baum der DevTools Ihres Browsers (oder mit einer Erweiterung zur Gliederungsprüfung) die Überschriftenebenen in Dokumentreihenfolge auf und vergleichen Sie diese mit den tatsächlichen <h1>–<h6>-Tags im Quelltext, unabhängig davon, wie tief jede Überschrift in verschachtelten <section>/<article>-Elementen sitzt. Erwartetes Ergebnis: Die gemeldete Überschriftenebene für jede Überschrift stimmt mit ihrem wörtlichen Tag überein (ein <h2> wird als Ebene 2 gemeldet, egal in wie vielen Abschnitten es verschachtelt ist) – es gibt keine implizite Herabstufung durch Verschachtelung. Fehlerinterpretation: Wenn Ihre Vorlage oder eine Komponentenbibliothek sich darauf verlässt, dass <section>-Verschachtelung die Rangstufe einer Überschrift „automatisch“ senkt, trifft diese Annahme nicht zu – der alte Dokumentgliederungsalgorithmus wurde nie implementiert und die aktuelle Spezifikation berechnet Gliederungen nicht auf diese Weise. Korrigieren Sie die tatsächlichen Überschriften-Tags. Überwachungszeitraum: Sofort und immer dann, wenn ein neues Vorlagen- oder Komponentenmuster verschachtelte Abschnitte einführt. Rollback-Auslöser: Die gerenderte/gemeldete Ebene einer Überschrift stimmt nicht mit ihrem wörtlichen <h1>–<h6>-Tag überein.

Fake-Links und Fake-Schaltflächen sind per Tastatur zugänglich

Durchzuführender Test: Navigieren Sie mit der Tabulatortaste nur über die Tastatur durch die Seite und versuchen Sie, jedes klickbare Element mit Eingabetaste/Leertaste zu aktivieren; prüfen Sie separat im Accessibility-Baum, welche Rolle jedes klickbare Element meldet. Erwartetes Ergebnis: Elemente, die navigieren, melden link (natives <a href>); Elemente, die auf der Seite agieren, melden button (natives <button>), und beide sind per Tastatur ohne zusätzlichen role/tabindex/Key-Handler-Code erreichbar und aktivierbar. Fehlerinterpretation: Ein <div> oder <span> mit einem Klick-Handler, der nicht per Tastatur erreichbar ist oder eine generische Rolle statt link/button meldet, bedeutet, dass es in das native Element umgewandelt werden muss, anstatt mit ARIA gepatcht zu werden. Überwachungszeitraum: Sofort – nach jeder Änderung an interaktiven Elementen durch Komponentenbibliothek oder Designsystem erneut prüfen. Rollback-Auslöser: Jedes klickbare Steuerelement, das nicht allein über die Tastatur erreicht oder aktiviert werden kann.

Testen Sie sich selbst: Semantisches HTML

Fünf kurze Fragen zu semantischem HTML und was es für SEO tut (und nicht tut). Wählen Sie eine Antwort für jede Frage und prüfen Sie dann.

Änderungsprotokoll