Semantisches HTML · Grundlagen & Struktur
Dokument-Metadaten: head, meta & link
Der <head> enthält die Angaben, die eine Seite über sich selbst macht: Zeichensatz, mobile Darstellung, Titel, Beschreibung und die Verweise auf Stylesheet, Canonical und Favicon. Im Seiteninhalt sieht man davon nichts – dafür überall dort, wo die Seite auftaucht: im Browser-Tab, im Suchergebnis und in der Vorschau eines geteilten Links.
Der <head> ist damit der Maschinenraum jeder Seite. Ein paar Zeilen entscheiden darüber, ob Umlaute funktionieren, ob die Seite auf dem Handy lesbar ist und wie sie in der Suche aussieht.
Diese Seite ist die technische Referenz: welche Angabe wohin gehört, in welcher Reihenfolge, mit welcher Syntax. Wie lang Title und Description sein dürfen und wie du sie für die Suche formulierst, steht im SEO-Leitfaden Title-Tag & Meta-Description.
Das Wichtigste in Kürze
- Zwei Zeilen sind Pflicht:
charsetundviewport– und beide gehören ganz nach oben. -
<title>und Meta-Description sind dein Auftritt in der Suche und pro Seite einzigartig. -
langsteht am<html>, nicht im<head>– gehört aber zum selben Setup. -
<link>regelt die Beziehungen: Stylesheet, Canonical, Icon, alternative Sprachfassungen, Vorladen. - Reihenfolge zählt:
charsetmuss in den ersten 1024 Byte stehen, sonst kann der Browser den Anfang der Seite neu parsen müssen. -
user-scalable=noist tabu – das sperrt das Pinch-Zoom aus und verstößt gegen 1.4.4 Textgröße ändern. - Fürs Favicon genügen vier Zeilen und vier Dateien:
favicon.ico(48 × 48),icon.svg,apple-touch-icon.png(180 × 180) und ein Web-App-Manifest. - Google verlangt fürs Favicon im Suchergebnis ein Quadrat mit einer Kantenlänge, die ein Vielfaches von 48 Pixeln ist – SVG ausgenommen.
Wo der <head> sichtbar wird
Das ist der Grund, warum sich die Sorgfalt hier lohnt: Der <head> ist der Teil der Seite, den am meisten Menschen sehen – nämlich auch alle, die nie klicken.
Das Pflichtprogramm
Zwei <meta>-Angaben gehören in jeden <head> – und ganz nach oben:
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Seitentitel | Marke</title>
<meta name="description" content="Kurze, einzigartige Beschreibung der Seite." />
</head>
charset="utf-8" stellt die korrekte Zeichenkodierung sicher – Umlaute, Anführungszeichen, Emojis. Sie muss innerhalb der ersten 1024 Byte des Dokuments stehen; findet der Browser sie später, hat er schon mit einer Vermutung angefangen zu parsen und muss unter Umständen von vorn beginnen. Deshalb ist sie die allererste Zeile im <head>. Wenn Umlaute trotz korrekter Angabe kaputt sind, liegt es fast immer daran, dass der Server einen anderen Zeichensatz im HTTP-Header meldet – der gewinnt gegen das Meta-Tag.
viewport sorgt für die richtige Skalierung auf Mobilgeräten. Ohne sie rendert der Browser die Seite in einer fiktiven Desktopbreite und schrumpft sie – die klassische „winzige Seite auf dem Handy“. Das content-Attribut sollte genau so lauten wie oben. Ergänzungen sind selten nötig; viewport-fit=cover braucht man, wenn Inhalte bis in die abgerundeten Ecken moderner Handys reichen sollen.
Was dort nicht hineingehört: user-scalable=no oder maximum-scale=1. Beides verhindert das Aufziehen mit zwei Fingern – für viele Menschen mit Sehbeeinträchtigung die wichtigste Bedienhilfe überhaupt.
Die empfohlene Reihenfolge
Ein <head>, der die übliche Reihenfolge einhält – von „muss zuerst gelesen werden“ bis „darf warten“:
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Dokument-Metadaten im head | html-einfach.de</title>
<meta name="description" content="charset, viewport, title, description …" />
<link rel="canonical" href="https://html-einfach.de/semantisches-html/dokument-metadaten.html" />
<link rel="preload" as="font" type="font/woff2" href="/fonts/sans.woff2" crossorigin />
<link rel="stylesheet" href="/styles.css" />
<link rel="icon" href="/favicon.ico" sizes="any" />
<link rel="icon" href="/icon.svg" type="image/svg+xml" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
<meta property="og:title" content="Dokument-Metadaten im head" />
<meta property="og:description" content="Der unsichtbare Teil jeder Seite." />
<meta property="og:image" content="https://html-einfach.de/og/dokument-metadaten.png" />
</head>Die Logik dahinter: Erst das, was das Parsen selbst betrifft (charset, viewport), dann das, was die Seite identifiziert (title, description, canonical), dann das, was das Rendern beschleunigt (Preloads, Stylesheet), zuletzt das, was erst später gebraucht wird (Icons, Social-Vorschau). Streng vorgeschrieben ist nur die Position von charset – der Rest ist Handwerk, das den LCP spürbar beeinflussen kann.
Title & Description: wohin sie gehören
Syntaktisch sind die beiden ungleiche Geschwister. Der Seitentitel ist ein eigenes Element, <title>, und kein <meta>-Tag – die Beschreibung dagegen schon:
<title>Seitentitel | Marke</title>
<meta name="description" content="Kurze, einzigartige Beschreibung der Seite." />Deshalb wertet Google ein <meta name="title"> auch nicht aus, so oft es in alten Vorlagen auch auftaucht. Beide gehören in den oberen Teil des <head>, direkt nach charset und viewport, und beide sind pro Seite einzigartig.
Damit endet der Teil, der zur <head>-Referenz gehört. Wie lang Title und Description sein dürfen, wie du sie formulierst und warum Google sie so oft umschreibt, steht vollständig unter Title-Tag & Meta-Description.
Die Sprache: lang am html-Element
Genau genommen kein <head>-Inhalt, aber Teil des Dokument-Setups: Das lang-Attribut am <html> sagt Browsern und Screenreadern, in welcher Sprache die Seite ist – damit die Aussprache stimmt. Ohne die Angabe liest ein Screenreader deutschen Text unter Umständen mit englischer Aussprache vor; verstehen kann das niemand.
<html lang="de">Es ist eine Zeile und zugleich ein WCAG-Kriterium der Stufe A. Einzelne anderssprachige Passagen im Text bekommen zusätzlich ihr eigenes lang am umschließenden Element.
Das link-Element
<link> verknüpft die Seite mit externen Ressourcen und Beziehungen:
<link rel="stylesheet" href="/styles.css" />
<link rel="canonical" href="https://example.de/seite.html" />
<link rel="icon" href="/favicon.ico" sizes="any" />
<link rel="alternate" hreflang="en" href="https://example.de/en/page.html" />
<link rel="preconnect" href="https://cdn.example.com" crossorigin />-
rel="stylesheet"bindet CSS ein. Es blockiert das Rendern – ein Grund, es schlank zu halten. -
rel="canonical"benennt die maßgebliche URL gegen Duplicate Content. Sie sollte absolut sein und auf sich selbst zeigen, wenn die Seite das Original ist. -
rel="icon"liefert das Favicon. Zwei Zeilen genügen heute: einefavicon.icofür ältere Browser und ein SVG für alles Moderne, dazu einapple-touch-iconfür den Homescreen – ausführlich unter Favicon einbinden: Formate, Größen und Beispiele. -
rel="alternate" hreflang="…"verweist auf Sprachfassungen. Wichtig dabei: Die Verweise müssen wechselseitig sein, sonst ignoriert Google sie. - Resource Hints steuern das Laden:
preload(jetzt gleich gebraucht, z. B. die Hauptschrift),preconnect(Verbindung zu einer fremden Domain vorbereiten),dns-prefetch(nur die Namensauflösung),prefetch(wahrscheinlich als Nächstes gebraucht). Sparsam einsetzen: Jeder Hint nimmt Bandbreite von etwas anderem weg.
Favicon einbinden: Formate, Größen und Beispiele
Kaum ein Thema hat so viele überholte Anleitungen im Umlauf wie das Favicon. Wer einem Generator vertraut, bekommt oft zwanzig <link>-Zeilen und einen Ordner voller PNGs in zwölf Größen. Das war um 2015 herum nötig. Stand August 2026 genügen vier Dateien und vier Zeilen – für alle Browser, iOS, Android und die Google-Suche.
Favicon-Beispiele: was bei 16 Pixeln noch trägt
Ein Favicon wird fast immer in der kleinsten aller Größen gesehen: 16 × 16 Pixel im Browser-Tab. Das ist ungefähr die Fläche eines Satzzeichens. Sechs Beispiele, jeweils groß und in der echten Tab-Größe daneben:
Daraus lässt sich eine Regel ableiten, die sich in jedem Projekt bewährt hat: ein Zeichen oder eine Form, ein kräftiger Farbkontrast, kein Text unter drei Buchstaben Größe. Wer die Wortmarke unbedingt unterbringen will, nimmt den Anfangsbuchstaben – Wiedererkennung entsteht bei dieser Kantenlänge über Farbe und Silhouette, nicht über Lesbarkeit.
Das vollständige Beispiel
<head>
<meta charset="utf-8" />
<!-- 1. Für ältere Browser und die Google-Suche -->
<link rel="icon" href="/favicon.ico" sizes="48x48" />
<!-- 2. Für alle modernen Browser: skaliert verlustfrei, kennt Dark Mode -->
<link rel="icon" href="/icon.svg" type="image/svg+xml" />
<!-- 3. Für „Zum Home-Bildschirm" unter iOS -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
<!-- 4. Für Android und installierbare Web-Apps -->
<link rel="manifest" href="/manifest.webmanifest" />
</head>Dazu die passende manifest.webmanifest im Wurzelverzeichnis:
{
"name": "html-einfach.de",
"icons": [
{ "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
{ "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" },
{ "src": "/icon-maskable.png", "type": "image/png", "sizes": "512x512",
"purpose": "maskable" }
]
}Das ist alles. Die favicon.ico gehört ins Wurzelverzeichnis, weil Browser sie auch ohne <link>-Zeile dort abrufen – eine Konvention aus den 1990ern, die bis heute trägt.
Welche Größe braucht welche Datei?
| Datei | Größe | Format | Wofür |
|---|---|---|---|
favicon.ico |
48 × 48 | ICO | Browser-Tab, Lesezeichen, Google-Suche |
icon.svg |
beliebig | SVG | moderne Browser, Dark Mode |
apple-touch-icon.png |
180 × 180 | PNG | iOS-Homescreen |
icon-192.png |
192 × 192 | PNG | Android-Homescreen |
icon-512.png |
512 × 512 | PNG | Splash Screen, App-Listen |
icon-maskable.png |
512 × 512 | PNG | Androids runde/eckige Zuschnitte |
Zwei Größenregeln lohnen sich zu merken, weil sie in fast jeder Anleitung fehlen:
Google verlangt ein Vielfaches von 48 Pixeln. Für das Favicon neben dem Suchergebnis auf dem Handy schreibt Google eine quadratische Datei vor, deren Kantenlänge ein Vielfaches von 48 px ist – also 48 × 48, 96 × 96, 144 × 144 und so weiter. SVG-Dateien sind von der Vorgabe ausgenommen. Ein klassisches 16 × 16-Icon erfüllt diese Bedingung nicht; deshalb steht in der .ico oben 48 × 48 und nicht die historischen 16 × 16.
Das Apple-Touch-Icon verträgt keine Transparenz. iOS legt hinter transparente Bereiche Schwarz. Wer ein freigestelltes Logo hinterlegt, bekommt auf dem Homescreen eine schwarze Kachel. Also: Hintergrundfarbe fest einbacken und auf 180 × 180 exportieren.
Maskable Icons brauchen eine Sicherheitszone. Android schneidet Icons je nach Hersteller rund, quadratisch oder als Squircle zu. Alles Wichtige gehört deshalb in den inneren Kreis mit 80 % Durchmesser – der Rand kann weggeschnitten werden.
Ein SVG-Favicon, das auf Dark Mode reagiert
Das ist der praktische Vorteil des SVG-Formats gegenüber der .ico: Ein Icon kann seine Farbe an das Farbschema des Systems anpassen, weil Browser die CSS im SVG auswerten.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
<style>
path { fill: #111827; }
@media (prefers-color-scheme: dark) {
path { fill: #f9fafb; }
}
</style>
<path d="M6 4h4v10h12V4h4v24h-4V18H10v10H6z" />
</svg>Ein dunkles Logo verschwindet sonst in der dunklen Browserleiste. Genau dieser Fall – ein Element, das nur in einem der beiden Modi erkennbar ist – begegnet einem auch beim Farbkontrast im Seiteninhalt wieder.
Häufige Fehler beim Favicon
- Nur 16 × 16 ausgeliefert. Sieht im Tab in Ordnung aus, erfüllt aber Googles 48-Pixel-Regel nicht und wird auf hochauflösenden Displays unscharf.
- Transparenz im Apple-Touch-Icon – ergibt eine schwarze Kachel auf dem iPhone.
-
Zwanzig
<link>-Zeilen aus einem Generator. Jede kostet eine Anfrage und Wartung; vier reichen. - Ein zu detailliertes Logo. Bei 16 Pixeln Kantenlänge bleibt von einem Schriftzug ein grauer Fleck. Ein Buchstabe oder eine einfache Form trägt weiter.
- Icon geändert, aber nichts passiert. Browser und Google cachen Favicons ausdauernd. Beim Wechsel hilft ein neuer Dateiname (
/icon-2026.svg) statt Warten. - Favicon nur im Unterverzeichnis. Ohne
/favicon.icoim Wurzelverzeichnis fragen manche Clients ins Leere und protokollieren einen 404 pro Aufruf.
Randnotiz – warum ein Favicon mehr ist als Kosmetik. Wer mit zwanzig offenen Tabs arbeitet, sieht vom Titel oft nur zwei Buchstaben; das Icon ist dann das einzige Unterscheidungsmerkmal. Für Menschen mit kognitiven Einschränkungen oder eingeschränktem Sehvermögen ist dieses Wiedererkennungszeichen ein echter Orientierungsgewinn – und es arbeitet mit dem Seitentitel zusammen, den WCAG 2.4.2 Seitentitel ohnehin verlangt. Ein Favicon, das sich von den Nachbarn unterscheidet und in hellem wie dunklem Modus erkennbar bleibt, ist deshalb kein Designdetail, sondern Bedienbarkeit.
Weitere <meta>-Angaben, die sich lohnen
| Angabe | Wofür | Pflicht? |
|---|---|---|
charset |
Zeichenkodierung | ja |
viewport |
mobile Darstellung | ja |
description |
Snippet in der Suche | praktisch immer |
robots |
Indexierung steuern (noindex …) |
nur bei Bedarf |
theme-color |
Farbe der Browserleiste (mobil) | optional |
color-scheme |
helle und dunkle Darstellung nativer Elemente | optional |
og:* / twitter:* |
Vorschau beim Teilen | empfohlen |
referrer |
wie viel Herkunft mitgesendet wird | selten |
Zwei praktische Anmerkungen dazu. theme-color lässt sich per media-Attribut für helle und dunkle Darstellung getrennt setzen. Und robots gehört zu den Angaben, mit denen man sich am schnellsten selbst aus dem Index schießt – ein versehentlich vom Testsystem übernommenes noindex ist ein Klassiker, den man erst Wochen später bemerkt.
Was man dagegen weglassen kann: keywords (von Google seit Langem ignoriert), revisit-after, generator und die meisten anderen Relikte aus alten CMS-Vorlagen. Sie kosten nichts außer Übersicht – aber die auch.
Randnotiz – eine Quelle für mehrere Ausgaben. Der
<head>ist auch die Heimat der Open-Graph-Tags und des JSON-LD. Wer diese Angaben aus einer zentralen Datenquelle erzeugt, hält Titel, Vorschaubild und strukturierte Daten automatisch konsistent – genau so macht es diese Website: Ein Titel im Seiten-Frontmatter erzeugt<title>,og:title, das Vorschaubild und den Eintrag im strukturierten Datensatz. Was zusammengehört, kann so nicht auseinanderlaufen.
Wie du den <head> prüfst
- Quelltext ansehen (Strg/⌘ + U): Steht
charsetwirklich oben? Ist der Titel der, den du erwartest? - Elemente-Bereich der DevTools: Zeigt den
<head>nach der Ausführung von Skripten – so findest du Tags, die erst nachträglich eingefügt oder überschrieben werden. - Netzwerk-Bereich: Prüft, ob der Server einen abweichenden
Content-Typemit fremdem Zeichensatz meldet. - HTML-Validator: findet doppelte Titel, falsch platzierte Elemente und ungültige Attribute.
- Vorschau testen: Teile den Link in einem Chat mit dir selbst – zeigt sich das erwartete Bild? Viele Netzwerke halten die Vorschau lange im Cache, deshalb besser vor dem Veröffentlichen prüfen als danach.
Häufige Fehler
-
viewportvergessen – die Seite ist auf dem Smartphone unbrauchbar. -
charsetfehlt oder steht zu spät – kaputte Umlaute. -
langnicht gesetzt – Screenreader sprechen die Seite falsch aus. -
Gleicher
<title>auf vielen Seiten – austauschbare Suchergebnisse. -
user-scalable=noim Viewport – ein Barriere-Verstoß. - Relativer oder falscher Canonical – im schlimmsten Fall zeigen alle Seiten auf die Startseite.
-
noindexaus der Testumgebung mitgenommen. -
og:imageals relative Adresse – Vorschaubilder brauchen absolute URLs.
Häufige Fragen
Wie binde ich ein Favicon in HTML ein?
Mit vier Zeilen im <head>: <link rel="icon" href="../favicon.ico" sizes="48x48"> für ältere Browser und die Google-Suche, <link rel="icon" href="../icon.svg" type="image/svg+xml"> für moderne Browser, <link rel="apple-touch-icon" href="../apple-touch-icon.png"> für iOS und <link rel="manifest" href="../manifest.webmanifest"> für Android. Die favicon.ico gehört zusätzlich ins Wurzelverzeichnis, weil Browser sie dort auch ohne <link>-Zeile abrufen.
Welche Favicon-Größe ist richtig?
Für die .ico 48 × 48 Pixel: Google verlangt für das Favicon im Suchergebnis ein Quadrat, dessen Kantenlänge ein Vielfaches von 48 px ist. Das Apple-Touch-Icon misst 180 × 180 und darf keine Transparenz enthalten, die Manifest-Icons 192 × 192 und 512 × 512. Ein SVG braucht keine Größenangabe, weil es verlustfrei skaliert – es ist von Googles Regel ausdrücklich ausgenommen.
Wie sieht ein gutes Favicon aus?
Es besteht aus einer einzigen Form: einem Buchstaben, einer geometrischen Marke oder einer kräftigen Silhouette, mit hohem Kontrast zum Hintergrund. Der Grund ist die Größe – im Browser-Tab bleiben 16 × 16 Pixel, und darin zerfällt jeder Schriftzug und jedes Bildmotiv zu einem grauen Fleck. Prüfen lässt sich das in fünf Sekunden: das Icon auf 16 Pixel verkleinern und aus normalem Sitzabstand ansehen.
Welche Meta-Tags brauche ich wirklich?
charset und viewport sind Pflicht, title und description praktisch immer, canonical sobald eine Seite unter mehreren Adressen erreichbar sein könnte. Vieles andere (das Keywords-Meta etwa) ist überflüssig.
Gehört das lang-Attribut nicht woanders hin?
Es steht am <html>-Element, nicht im <head>. Da es zum grundlegenden Dokument-Setup gehört, behandle ich es hier mit.
Wie viele link-Beziehungen sind sinnvoll?
So viele wie nötig: Stylesheet, Canonical, Icon, ggf. Preload und alternative Sprachen. Kein Ballast, aber das Wichtige vollständig. Bei Resource Hints gilt: lieber zwei gezielte als zehn auf Verdacht.
Muss der Titel die Marke enthalten?
Auf Inhaltsseiten hilft ein kurzer Markenzusatz hinten („Thema | Marke“), auf der Startseite gehört die Marke nach vorn. Wichtiger ist, dass der eigentliche Inhalt zuerst kommt – auf schmalen Bildschirmen sieht man vom Ende nichts mehr.
Beeinflusst der <head> die Ladezeit?
Ja, deutlich. Render-blockierendes CSS, Skripte ohne defer und fehlende Preloads für die Hauptschrift wirken sich direkt auf LCP und INP aus. Der <head> ist der Ort, an dem über die ersten Sekunden entschieden wird.
Was ist mit Skripten im <head>?
Nur mit defer (oder type="module"), sonst blockieren sie das Parsen des Dokuments. Alles, was nicht sofort gebraucht wird, gehört ans Ende oder gar nicht erst auf die Seite.
Fazit
Der <head> ist klein, aber folgenreich: charset und viewport als Pflicht und möglichst weit oben, Title und Description für die Suche, lang am <html> für die Aussprache und <link> für Stylesheet, Canonical, Icons und Vorladen. Unsichtbar auf der Seite – aber sichtbar überall dort, wo über den Klick entschieden wird.
Quellen
- HEAD – A simple guide to HTML head elements (kuratierte Referenz inklusive empfohlener Reihenfolge)
- Das head-Element (MDN – erlaubte Inhalte und Attribute)
- Favicon in Google-Suchergebnissen definieren (Google Search Central – Größenvorgabe „Vielfaches von 48 px“ und unterstützte Formate)
- rel="icon" (HTML-Standard, WHATWG – Verhalten und Attribute des Icon-Links)
- Web Application Manifest (W3C – Icon-Deklaration inklusive
purpose: maskable)