Semantisches HTML · Fehler vermeiden
HTML validieren & häufige Fehler
HTML validieren heißt, das Markup gegen die HTML-Spezifikation zu prüfen – nicht gegen die Frage, ob es im Browser gut aussieht. Der Browser repariert Fehler stillschweigend, der Validator macht sie sichtbar; das offizielle Werkzeug dafür ist der Nu Html Checker unter validator.w3.org/nu.
Browser sind nachsichtig, und genau das ist die Falle: Aus „sieht ok aus“ wird schnell „ist schon richtig“. Validierung stärkt das „R“ der vier Prinzipien – robust – und kostet in einem eingerichteten Projekt fast nichts.
Das Wichtigste in Kürze
- Der Browser zeigt dir den DOM, nicht deinen Quelltext. „Element untersuchen“ ist deshalb keine Validierung.
- Der häufigste Error im Web ist „Element X not allowed as child of element Y in this context“ – knapp die Hälfte aller Fehlermeldungen.
- Der häufigste Treffer überhaupt ist gar kein Fehler: der Schrägstrich an leeren Elementen (
<br/>) ist eine Warnung, kein Verstoß. - Zwei Werkzeuge, zwei Rollen:
html-validateprüft Templates und Fragmente während der Entwicklung,vnuprüft den fertigen Build-Output. - In CI gehört eine eigene Instanz – Massenanfragen an den öffentlichen Dienst laufen in „429 Too Many Requests“.
- Valide ≠ barrierefrei. Der Validator prüft Syntax, nicht Sinn.
Warum Browser Fehler verzeihen
Der HTML-Parser hat für fast jeden Fehler eine dokumentierte Reparaturregel. Er bricht nicht ab wie ein Compiler, sondern baut trotzdem einen Baum – nur eben nicht unbedingt den, den du gemeint hast.
<strong>fett <em>und kursiv?</strong> was ist das hier?</em>Was der Parser daraus macht, ist keine Meinungssache, sondern Spezifikation (der sogenannte Adoption Agency Algorithm):
<strong>fett <em>und kursiv?</em></strong><em> was ist das hier?</em>Das <em> wird geschlossen und danach neu geöffnet. Optisch fällt das nie auf – im DOM stehen jetzt aber zwei <em>-Elemente statt einem. Wer solche Strukturen per CSS oder JavaScript anspricht, sucht den Fehler später an der falschen Stelle.
Der DOM ist nicht dein Quelltext
Daraus folgt der wichtigste praktische Punkt dieser Seite: Die Entwicklerwerkzeuge zeigen den bereits reparierten DOM. Der Inspektor in Firefox und die Elements-Ansicht in Chrome zeigen den Baum nach dem Parsen – und nach allem, was JavaScript seither verändert hat. Kaputte Verschachtelung sieht dort sauber aus.
Für die Validierung brauchst du deshalb den ausgelieferten Quelltext („Seitenquelltext anzeigen“), nicht den Inspektor. Und bei Seiten, deren Inhalt erst im Browser entsteht, geht man den umgekehrten Weg:
copy(document.documentElement.outerHTML)Das kopiert den aktuellen DOM in die Zwischenablage – zum Prüfen per Direkteingabe. Ein Detail dabei: Der so kopierte Baum enthält keinen Doctype. Ohne ein vorangestelltes <!DOCTYPE html> meldet der Checker sonst „Start tag seen without seeing a doctype first“.
Der W3C-Prüfdienst
Zwei Adressen sind im Umlauf, und der Unterschied ist kleiner als oft behauptet: validator.w3.org ist die klassische Oberfläche des Markup Validation Service, validator.w3.org/nu der Nu Html Checker (v.Nu). Der Markup Validation Service bindet den Nu-Checker für HTML5-Dokumente ein – „der alte Dienst kann kein HTML5“ stimmt also nicht; unterschiedlich sind Oberfläche und die Unterstützung alter Doctypes. Für alles Moderne nimmt man direkt /nu.
Drei Eingabewege führen zum Ergebnis:
- Adresse prüfen – eine öffentlich erreichbare URL.
- Datei hochladen – eine lokale HTML-Datei.
- Direkteingabe – Markup direkt hineinkopieren.
Dazu kommen zwei Schalter, die man kennen sollte: „Show source“ zeigt den Quelltext mit markierten Fehlerstellen, „Message filtering“ blendet Meldungstypen aus und nennt die Gesamtzahlen.
Ein Beispiel: Diese Produktkarte sieht im Browser völlig normal aus.
<h1 id="titel">Unsere Produkte</h1>
<p>Ein Absatz, in dem ein Block steckt:
<div class="karte">
<img src="/img/stuhl.jpg">
<a href="/stuhl.html">Bürostuhl ansehen
<a href="/warenkorb.html">In den Warenkorb</a>
</a>
</div>
</p>
<h2 id="titel">Zubehör</h2>
<span>
<div>Ein Blockelement in einem Inline-Element.</div>
</span>
<button type="button" aria-labeledby="titel">Mehr laden</button>Der Nu Html Checker meldet dazu sieben Fehler und eine Warnung:
Beachtenswert ist die Reihenfolge: Fehler 2 und 3 sind derselbe Fehler. Das zweite <a> schließt das erste implizit, weshalb das folgende </a> „verirrt“ ist. Deshalb die wichtigste Arbeitsregel beim Validieren: von oben nach unten abarbeiten und zwischendurch neu prüfen – der erste Fehler erzeugt oft die halbe Liste darunter.
Die häufigsten Fehlermeldungen
Die folgenden Anteile stammen aus einer Auswertung von Rocket Validator (ein kommerzieller Crawler mit eigener Stichprobe, Stand 26. Juli 2026: rund 463 Millionen Meldungen auf 13 Millionen Seiten), gefiltert auf Fehler-Level. Die englischen Originalwortlaute stehen bewusst dabei – danach sucht man später.
| Meldung (Original) | Was gemeint ist | Anteil |
|---|---|---|
Element X not allowed as child of element Y in this context. |
Element an einer Stelle, an der es nicht erlaubt ist | 49,3 % |
Attribute X not allowed on element Y at this point. |
Attribut gibt es nicht oder nicht an diesem Element | 18,4 % |
Duplicate ID X. |
dieselbe id mehrfach im Dokument |
14,6 % |
An element with the attribute tabindex must not appear as a descendant of the a element. |
fokussierbares Element in einem Link verschachtelt | 4,8 % |
An img element must have an alt attribute… |
fehlender Alternativtext | 4,6 % |
Bad value for attribute target on element a: Browsing context name must be at least one character long. |
target="" – leerer Wert |
1,9 % |
No space between attributes. |
fehlendes Leerzeichen im Tag | 1,9 % |
Element img is missing required attribute src or srcset. |
Bild ohne Quelle | 1,8 % |
When the srcset attribute has any image candidate string with a width descriptor, the sizes attribute must also be specified. |
srcset mit w-Angaben ohne sizes |
1,5 % |
Duplicate attribute X. |
dasselbe Attribut zweimal am Element | 1,2 % |
Drei davon lohnen einen genaueren Blick, weil ihre naheliegende Korrektur falsch ist.
Doppelte id. Der reale Auslöser ist fast nie Schlamperei, sondern eine wiederverwendete Komponente mit hartcodierter id. Die Lösung ist deshalb nicht „die zweite umbenennen“, sondern die id aus einer eindeutigen Quelle zu erzeugen und alle Verweise daran zu koppeln:
---
const id = crypto.randomUUID();
---
<label for={`mail-${id}`}>E-Mail</label>
<input id={`mail-${id}`} type="email" aria-describedby={`hilfe-${id}`}>
<p id={`hilfe-${id}`}>Wir nutzen sie nur für die Antwort.</p>Doppelte IDs hebeln for, aria-describedby, aria-labelledby und jedes Sprungziel aus – das ist der Fehler mit den weitreichendsten Folgen.
tabindex im Link. Der Fix ist nicht, tabindex zu entfernen: Ein Bedienelement gehört gar nicht erst in einen Link.
<!-- Falsch: verschachtelte Bedienelemente -->
<a href="/produkt.html"><button type="button">Merken</button></a>
<!-- Richtig: nebeneinander -->
<a href="/produkt.html">Produkt ansehen</a>
<button type="button">Merken</button>
target="". Entweder das Attribut weglassen oder einen echten Wert setzen. Bei target="_blank" ist rel="noopener" heute nicht mehr zwingend – moderne Browser setzen es implizit –, schadet aber nicht. Wichtiger ist der Hinweis für Nutzende, dass sich ein neues Fenster öffnet.
Warnung, Info oder echter Fehler?
Der mit Abstand häufigste Treffer im ganzen Web ist kein Fehler: der Schrägstrich an leeren Elementen (<br/>, <img/>). Er ist in HTML wirkungslos, aber nicht ungültig; der Checker gibt dazu eine Warnung aus, weil die Schreibweise mit nicht-quotierten Attributwerten unschön interagiert. In JSX- und Vue-Templates ist sie sogar erforderlich. Wer diese Meldung durchs ganze Projekt jagt, verbrennt Zeit.
Weitere häufige Nicht-Fehler:
-
aria-hidden="true"nebenhidden– redundant, also eine Warnung. (Der harte Fehler dahinter findet der Validator übrigens nicht:aria-hiddendarf niemals auf einem Element liegen, das fokussierbaren Inhalt enthält.) -
type="text/javascript"an<script>– seit HTML5 überflüssig. - „Section lacks heading“ – eine Warnung, kein Verstoß.
-
Mehrere
<h1>sind valides HTML. Ob sie sinnvoll sind, ist eine Frage der Überschriften-Hierarchie, nicht der Validität.
Die Reihenfolge, die sich bewährt hat: erst alle Errors auf null, dann Warnungen bewerten, Infos zuletzt.
Den Checker lokal betreiben: vnu
Für alles jenseits einer Handvoll Seiten will man den Checker lokal. Er heißt vnu und läuft auf mehreren Wegen:
brew install vnu
npm install --save-dev vnu-jar
docker run -d -p 8888:8888 ghcr.io/validator/validator:latestDie vorkompilierten Binaries bringen Java eingebettet mit; vnu.jar und vnu.war setzen dagegen Java 17 oder neuer voraus.
Entscheidend für den Alltag ist, dass er nicht nur Dateien frisst:
vnu --errors-only dist/
java -jar vnu.jar --errors-only --format gnu dist/Die dokumentierte Aufrufform ist vnu [OPTIONS]... FILES|DIRECTORY|URL... – das DIRECTORY ist der springende Punkt: Eine statisch generierte Website prüft man am fertigen dist/-Ordner, nicht Datei für Datei.
Die Flags, die zählen
| Flag | Wirkung |
|---|---|
--errors-only |
nur Fehler, keine Warnungen und Infos |
--Werror |
Exit-Code ungleich 0 auch bei Warnungen |
--exit-zero-always |
bricht den Build nie ab (für Berichte) |
--format gnu|xml|json|text |
Ausgabeformat, Standard ist gnu |
--filterfile DATEI |
eine Regex je Zeile, um bekannte Meldungen zu unterdrücken |
--filterpattern MUSTER |
dasselbe als einzelner Ausdruck |
--skip-non-html |
Nicht-HTML-Dateien im Verzeichnis überspringen |
--also-check-css, --also-check-svg |
CSS und SVG mitprüfen |
--no-langdetect |
Spracherkennung abschalten |
Ein verbreiteter Irrtum: --skip-info-messages wird keine Warnungen los – die Man-Page ist eindeutig, es filtert nur Info-Meldungen. Für „nur Fehler“ ist --errors-only zuständig.
Die Grundlage jeder CI-Einbindung ist der Exit-Code 1 bei Fehlern.
Als Web-Service ansprechen
curl -H "Content-Type: text/html; charset=utf-8" \
--data-binary @index.html \
https://validator.w3.org/nu/?out=jsonDer Content-Type ist Pflicht, sonst antwortet der Dienst mit einem Fehler; bei mehreren Parametern ist ausschließlich & als Trenner erlaubt.
Nicht geeignet ist das für Massenvalidierung: Wer eine ganze Site in CI gegen validator.w3.org prüft, läuft in 429 Too Many Requests. Ein konkretes Limit dokumentiert das W3C nicht – die Lösung ist ohnehin dieselbe: eine eigene Instanz per Docker starten und dagegen prüfen.
html-validate: der Linter für Templates
vnu prüft fertige Dokumente. Für Komponenten, Partials und Templates – also für alles, was in einem Astro-, Vue- oder Angular-Projekt entsteht – ist ein Linter das passendere Werkzeug:
npm install --save-dev html-validate
npm exec html-validate "dist/**/*.html".htmlvalidate.json im Projektwurzelverzeichnis:
{
"extends": ["html-validate:recommended"],
"rules": {
"no-dup-id": "error",
"no-deprecated-attr": "error",
"input-missing-label": "error",
"heading-level": "warn"
}
}Ein paar Regelnamen, die den Nutzen zeigen: no-dup-id, no-missing-references, void-content, deprecated, no-deprecated-attr, no-dup-attr, no-unknown-attributes, valid-id, heading-level, empty-heading, input-missing-label – dazu ein eigener Satz WCAG-Regeln (wcag/h30, wcag/h32, wcag/h37, wcag/h63, wcag/h67, wcag/h71).
Seit Version 11 setzt das Werkzeug Node 22 oder neuer voraus.
vnu oder html-validate?
| Kriterium | vnu |
html-validate |
|---|---|---|
| Vollständige Spezifikationsprüfung | Referenzimplementierung | deckt nicht alles ab |
| Fragmente und Templates | nein | ja |
| Regeln einzeln konfigurierbar | nur per Filter-Regex | feingranular |
| CSS und SVG mitprüfen | ja | nein |
| Java nötig | ja (außer Binary) | nein |
| Offline | ja | ja |
Die Antwort lautet in der Praxis beides: html-validate während der Entwicklung auf den Templates, vnu im Build auf dem fertigen Output. Sie ersetzen einander nicht.
In CI automatisieren
name: HTML prüfen
on: [push, pull_request]
jobs:
validate:
runs-on: ubuntu-latest
services:
vnu:
image: ghcr.io/validator/validator:latest
ports: ['8888:8888']
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm run build
- run: npx html-validate "dist/**/*.html"
- run: npx vnu-jar --errors-only --format json dist/{
"scripts": {
"validate": "html-validate 'dist/**/*.html'"
}
}Der Punkt, an dem solche Pipelines meist scheitern: Jemand hängt || true an den Befehl, weil der Build sonst rot ist. Damit ist die Prüfung wirkungslos. Wenn ein Bestand zu groß ist, gehört stattdessen eine Baseline her.
Bestandsprojekte: Baseline statt Big Bang
Bei dreistelligen Fehlerzahlen bringt „alles auf null“ niemanden weiter. Was funktioniert:
- Aktuellen Stand einfrieren – bekannte Meldungen in eine
--filterfileschreiben, eine Regex je Zeile. - Die CI schlägt nur bei neuen Fehlern fehl. Alles, was dazukommt, wird sofort sichtbar.
- Fehlerbudget je Sprint abbauen und die Filterdatei entsprechend kürzen.
Wichtig ist die Buchführung: Jede Filterzeile bekommt einen Kommentar mit Grund und Datum. Sonst wird aus der Übergangslösung ein Dauerzustand, den Jahre später niemand mehr zu löschen wagt.
Sonderfälle, an denen Validierung scheitert
- Framework-Attribute wie
x-data,v-if,hx-getoderng-*meldet der Checker als unbekannt. Statt sie stumpf zu filtern, kann man sie inhtml-validateals eigene Element- und Attribut-Metadaten hinterlegen – dann bleiben echte Tippfehler sichtbar. - Clientseitig gerendertes Markup prüft man über den DOM-Dump (siehe oben).
- Seiten hinter Login entweder als lokale Datei speichern oder mit
--additional-request-headerprüfen. - Custom Elements meldet
vnumit unbekannten Attributen. Sie sind laut Web Almanac 2024 auf 7,9 % der Seiten im Einsatz – eine Filterregel dafür ist legitim.
Was der Validator nicht prüft
Er prüft die Syntax, nicht den Sinn. Alle folgenden Beispiele validieren fehlerfrei und verstoßen trotzdem gegen WCAG:
<!-- Valide. Und trotzdem 1.1.1 verletzt: „Bild" beschreibt nichts. -->
<img src="umsatz-2026.png" alt="Bild">
<!-- Valide. Und trotzdem 2.1.1 verletzt: reagiert nicht auf Enter/Leertaste. -->
<div role="button" tabindex="0" onclick="senden()">Absenden</div>
<!-- Valide. Und trotzdem 1.3.1 fragwürdig: von h1 direkt auf h4. -->
<h1>Titel</h1>
<h4>Erster Abschnitt</h4>Dazu kommen Kontraste, Fokusreihenfolge, ARIA-Semantik und Sprachwechsel im Text – nichts davon sieht ein Markup-Checker. Der Nu Html Checker sagt das über sich selbst sehr deutlich: Er sei „intended solely as a checker, not as a pass/fail certification mechanism“. Und weil laufend neue Prüfungen dazukommen, ist null Fehler heute keine Garantie für morgen – in CI kann ein Checker-Update einen grünen Build rot färben.
Die Kür bleibt also echtes Testen mit Tastatur, Screenreader und Werkzeugen wie axe.
WCAG 4.1.1 Parsing: erledigt, auch rückwirkend
Bis WCAG 2.1 gab es ein eigenes Erfolgskriterium für sauberes Markup: 4.1.1 Parsing verlangte vollständige Start- und End-Tags, korrekte Verschachtelung, keine doppelten Attribute und eindeutige IDs. In WCAG 2.2 ist es entfernt – und das W3C hat es 2023 auch in den älteren Fassungen als überholt gekennzeichnet, wo es seither als immer erfüllt gilt. Validierung ist damit kein Konformitätskriterium mehr, auch nicht bei einer Prüfung gegen WCAG 2.1.
Warum das so entschieden wurde, was mit doppelten IDs heute passiert und wie du alte Prüfberichte einordnest, steht unter Warum WCAG 4.1.1 Parsing gestrichen wurde.
Die praktischen Vorteile sauberen Markups bleiben davon vollkommen unberührt. Doppelte IDs hebeln weiterhin aria-describedby aus, falsche Verschachtelung verwirrt weiterhin Hilfsmittel – und der Validator ist nach wie vor der billigste Aufräumschritt vor jedem manuellen Test.
Validierung und SEO: der <head> ist der Ernstfall
„Valides HTML rankt besser“ ist Geraune. Es gibt aber einen dokumentierten Mechanismus mit sehr konkreten Folgen, und der sitzt im <head>.
Google erlaubt dort genau acht Elemente: title, meta, link, script, style, base, noscript und template. Trifft der Parser auf etwas anderes – Google nennt ausdrücklich <img> und <iframe> –, nimmt er an, der <head> sei zu Ende, und liest nicht weiter.
<!-- Falsch: alles ab dem Tracking-Pixel wird ignoriert -->
<head>
<title>Bürostühle</title>
<img src="https://tracker.example/pixel.gif" alt="">
<link rel="canonical" href="https://beispiel.de/stuehle.html">
<meta name="robots" content="max-image-preview:large">
</head>
<!-- Richtig: der head enthält nur, was hineingehört -->
<head>
<title>Bürostühle</title>
<link rel="canonical" href="https://beispiel.de/stuehle.html">
<meta name="robots" content="max-image-preview:large">
</head>
<body>
<img src="https://tracker.example/pixel.gif" alt="" width="1" height="1">Im ersten Beispiel fallen Canonical und Robots-Angabe still aus – mit allen Folgen für Canonical & Duplicate Content. Ein <div>-Wrapper um Skripte im <head>, wie ihn manche Tag-Manager produzieren, hat exakt denselben Effekt.
Wie valide ist das Web wirklich?
Ernüchternd. Eine jährliche Auswertung von Jens Oliver Meiert prüft die ersten 200 Websites aus den Ahrefs-Top-1.000 (nur Startseiten, statisches HTML):
| Jahr | Ø Fehler je Startseite | valide Seiten |
|---|---|---|
| 2021 | 125,2 | 2 % |
| 2022 | 125,6 | 0 % |
| 2023 | 132,1 | 0 % |
| 2024 | 99,3 | 0,5 % |
| 2025 | 110,5 | 0 % |
2025 war keine einzige der 200 Seiten valide. Der Median lag bei 55,5 Fehlern, 63 Seiten hatten über 100. Die einzige valide Seite aus 2024 war ein Jahr später wieder fehlerhaft.
Meiert selbst warnt vor Scheinpräzision – die Stichprobe ist klein und auf Startseiten begrenzt. Die Botschaft bleibt trotzdem: Validität ist selten. Und genau deshalb ist sie ein billiger Qualitätsvorsprung.
Häufige Fehler
- Nie validieren und sich auf die Browseransicht verlassen.
- Den Inspektor für den Quelltext halten – er zeigt den reparierten DOM.
- Infos und Warnungen für Fehler halten und
<br/>durchs Projekt jagen. - Nur die Startseite prüfen statt des ganzen
dist/-Ordners. - Templates statt Build-Output validieren – der Fehler entsteht oft erst beim Zusammensetzen.
- Meldungen pauschal wegfiltern, statt sie zu verstehen.
-
|| truein der CI-Zeile, damit der Build grün bleibt. -
CI gegen
validator.w3.orgfahren und in 429 laufen. - Valide mit barrierefrei verwechseln – zwei verschiedene Prüfungen.
Häufige Fragen
Muss meine Seite zu 100 % fehlerfrei validieren?
Errors: ja, das ist ein realistisches Ziel. Warnungen bewertet man einzeln, Infos meist gar nicht. Wichtig sind die Fehler mit Folgen – doppelte IDs, kaputte Verschachtelung, fehlende Pflichtattribute.
Wo ist der Unterschied zwischen validator.w3.org und /nu?
/nu ist der HTML5-Checker; der klassische Dienst bindet ihn für moderne Dokumente ein und bietet zusätzlich alte Doctypes an. Für neue Projekte nimmt man /nu.
Brauche ich Java?
Für vnu.jar ja (Version 17 oder neuer). Die vorkompilierten Binaries und das Docker-Image bringen alles mit, html-validate läuft ganz ohne Java.
Wie validiere ich Seiten hinter einem Login?
Entweder die fertige Seite lokal speichern und die Datei prüfen – oder vnu mit --additional-request-header die nötigen Header mitgeben.
Wie prüfe ich JavaScript-generiertes HTML?
Über den DOM-Dump: copy(document.documentElement.outerHTML) in der Konsole, dann per Direkteingabe prüfen – mit vorangestelltem <!DOCTYPE html>.
Zählt Validität für die BFSG-Prüfung?
Nicht als eigener Prüfpunkt: 4.1.1 Parsing ist entfernt und gilt auch rückwirkend als erfüllt. Praktisch bleibt sie trotzdem relevant, weil doppelte IDs und kaputte Verschachtelung andere Kriterien reißen.
Ist valides HTML ein Google-Ranking-Faktor?
Nein. Dokumentiert ist nur der <head>-Mechanismus oben – und der ist konkret genug, um ihn ernst zu nehmen.
Wie validiere ich eine ganze Astro-Website?
npm run build, dann vnu --errors-only dist/. Das Verzeichnis-Argument nimmt den kompletten Output auf einmal.
Fazit
Der W3C-Prüfdienst macht sichtbar, was Browser verschlucken: nicht geschlossene Tags, doppelte IDs, kaputte Verschachtelung, vertippte ARIA-Attribute. Der wichtigste gedankliche Schritt dabei ist, den Inspektor nicht mit dem Quelltext zu verwechseln – er zeigt dir das Ergebnis der Reparatur, nicht den Fehler. Im Alltag lohnt beides: html-validate auf den Templates während der Entwicklung, vnu auf dem fertigen dist/-Ordner im Build, mit Baseline statt Big Bang für Bestandsprojekte. Und die Einordnung zum Schluss: WCAG 4.1.1 Parsing ist erledigt, Validität also kein Prüfpunkt mehr – aber weiterhin die Grundlage, auf der div-Suppe vermeiden und echtes Testen überhaupt Sinn ergeben.
Quellen
- Nu Html Checker (W3C – Prüfdienst, CLI-Optionen, Web-Service-API und Selbstverständnis)
- Valid page metadata for Google Search (Google Search Central – die acht im
<head>erlaubten Elemente und die Folgen eines ungültigen)