Sprachen

Das HTML-lang-Attribut

Was das HTML-lang-Attribut bewirkt, warum Google es für die Spracherkennung ignoriert, Bing es jedoch verwendet, wie es sich von hreflang unterscheidet und warum es für Barrierefreiheit und die automatische Übersetzungsaufforderung des Browsers weiterhin wichtig ist.

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 22. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Das HTML-lang-Attribut – gesetzt auf dem Wurzelelement als <html lang="en"> (oder einer Regionsvariante wie en-US) – deklariert die natürliche Sprache des Inhalts DIESES Dokuments mithilfe eines BCP-47-Tags. Es ist nicht dasselbe wie hreflang: lang beschreibt die Seite, auf der es sich befindet; hreflang deklariert URLs in alternativen Sprachen für andere Seiten. Google sagt deutlich, dass es lang für die Spracherkennung ignoriert („wir verwenden das überhaupt nicht … fast immer falsch“ – Mueller); es verwendet stattdessen Inhaltsalgorithmen. Bing ist das Gegenteil: Sein Webmaster-Blog von 2011 nennt <html lang> als Fallback-Signal für den Dokumentstandort, hinter dem Content-Language-Meta-Tag. Unabhängig vom Suchgewicht ist lang ein erforderliches Barrierefreiheitsattribut (WCAG 3.1.1) – es steuert die Aussprache des Screenreaders und die automatische Übersetzungsaufforderung des Browsers, und „fehlende Dokumentensprache“ ist immer noch einer der sechs häufigsten Fehler im WebAIM-Millionen-Report. Die eine Ausnahme von Google: maschinell übersetzte Blöcke mit lang="es-x-mtfrom-en" kennzeichnen. Setzen Sie einen gültigen Wert, halten Sie ihn konsistent mit hreflang, und hinterlassen Sie kein Standard-lang="en" auf nicht-englischen Inhalten.

TL;DR – lang deklariert die natürliche Sprache dieses Dokuments (<html lang="en"> oder eine Regionsvariante wie en-US) mithilfe eines BCP-47-Tags. Es ist ein anderer Mechanismus als hreflang, das alternative Sprach-URLs deklariert – Googles eigene Dokumentation fasst beide zusammen als Dinge, die es nicht zur Erkennung der Sprache einer Seite verwendet. Mueller: “we don’t use that at all… almost always wrong.” (Übersetzung) „Das nutzen wir überhaupt nicht … es ist fast immer falsch.“ Unabhängig vom Suchgewicht ist eine programmatisch bestimmbare Seitensprache eine WCAG-3.1.1-Level-A-Anforderung, und das HTML-lang-Attribut ist die Standardtechnik. Es unterstützt die Aussprache durch Screenreader und die automatische Übersetzungsaufforderung des Browsers, und „fehlende Dokumentsprache“ ist immer noch ein Top-Sechs-Fehler im WebAIM Million. Die eine Ausnahme bei Google: Kennzeichnung maschinell übersetzter Blöcke mit lang="es-x-mtfrom-en". Setzen Sie einen gültigen Wert, halten Sie ihn konsistent mit hreflang und entfernen Sie das Standard- lang="en" auf nicht-englischen Seiten.

Was das lang-Attribut tatsächlich deklariert

Das HTML-lang-Attribut ist ein globales Attribut – es kann technisch auf jedem Element stehen – aber das wichtigste sitzt auf dem Wurzelelement: <html lang="en">. Sein Wert ist ein BCP-47-Sprachcode, entweder ein Sprach-Subtag allein (en, es, de) oder ein Sprach-plus-Region-Paar (en-US, en-GB, pt-BR, zh-Hans).

Was es deklariert, ist eng und spezifisch: die natürliche Sprache des Textinhalts in dem Dokument, für das es gesetzt ist. Nicht die Sprache Ihrer alternativen Seiten, nicht das Land, das Sie anvisieren – nur „die Wörter auf dieser Seite sind in dieser Sprache.“

Evidence for this claim The HTML lang attribute specifies an element's language using a valid BCP 47 language tag; on the root html element it establishes the document's default language. Scope: WHATWG HTML language semantics and IETF BCP 47 tag syntax. Confidence: high · Verified: WHATWG: The lang attribute IETF RFC 5646 Evidence for this claim WCAG 2.2 success criterion 3.1.1 requires the default human language of a page to be programmatically determinable, and W3C lists lang on the html element as a sufficient HTML technique. Scope: WCAG 2.2 Level A language-of-page requirement for HTML documents. Confidence: high · Verified: W3C: Understanding Language of Page

Drei Präzisionspunkte, die es wert sind, verinnerlicht zu werden, entnommen aus der MDN-Referenz:

  • Nur gültige Werte. Ein BCP-47-Tag – kein erfundener Drei-Buchstaben-Code (eng), kein vollständiger Sprachname und kein en-UK (die Region-Unterkennung für das Vereinigte Königreich ist GB). Ungültige Werte werden wie kein Wert behandelt. Syntaktisch wohlgeformt ist auch nicht dasselbe wie korrekt: lang="en" ist ein vollkommen gültiges Tag, auf einer französischen Seite aber trotzdem falsch. Gültigkeit ist eine Untergrenze, keine Garantie, dass der Wert tatsächlich zum Inhalt passt (mehr dazu in der Standardwert-Falle unten).
  • Leer ist nicht dasselbe wie abwesend. Ein explizites lang="" bedeutet „unbekannte Sprache“ – ein bewusster Zustand. Ein wirklich fehlendes Attribut ist ein anderer Fehlermodus, und Barrierefreiheits-Tools kennzeichnen es als abwesend statt als explizit-unbekannt.
  • Der Wurzelwert ist ein Standard, keine Sperre. <html lang> legt fest, was jeder Nachkomme erbt, sofern es nicht überschrieben wird – setzen Sie lang lokal auf jedem Element zurück, das einen echten Sprachwechsel enthält (siehe „Setzen Sie es auch auf dem Element, das sich ändert“ unten). Verwechseln Sie diese In-Dokument-Deklaration nicht mit dem HTTP- Content-Language-Antwortheader: Dieser Header beschreibt Transport-Metadaten über die Antwort, nicht das geparste Dokument, und er ist kein Ersatz für lang, wenn es um Element-Ebene-Vererbung oder Barrierefreiheit geht.

lang vs. hreflang: die Verwirrung, aufgelöst

Wenn Sie von einer hreflang-Frage hierher gelangt sind, ist dies der Abschnitt, den Sie möchten. Diese beiden werden ständig verwechselt, weil sie beide sprachbezogen sind, beide am oder nahe dem Anfang des Dokuments stehen und beide ähnlich aussehende Codes verwenden. Aber sie erfüllen völlig unterschiedliche Aufgaben.

Die klarste Formulierung stammt direkt aus Googles eigener Dokumentation zu lokalisierten Versionen Ihrer Seiten, die beide genau deshalb zusammenfasst: Google verwendet keines von beiden zur Erkennung.

“Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” (Übersetzung) „Google verwendet weder hreflang noch das HTML-lang-Attribut, um die Sprache einer Seite zu erkennen; stattdessen verwenden wir Algorithmen, um die Sprache zu bestimmen.“

Lesen Sie das sorgfältig. Google nennt sowohl lang als auch hreflang in einem Atemzug – als zwei verschiedene Dinge, die es nicht verwendet, um herauszufinden, in welcher Sprache eine Seite ist. Es erkennt die Sprache stattdessen aus dem gerenderten, sichtbaren Inhalt.

Was ist also der tatsächliche Unterschied?

  • lang ist eine Selbstbeschreibung: ein Wert, auf <html> (oder jedem Element), der besagt: „Der Inhalt dieses Dokuments ist in dieser Sprache.“ Gelesen von Browsern, Screenreadern, Rechtschreibprüfungen; von Bing verwendet; von Google für die Erkennung ignoriert.
  • hreflang ist eine seitenübergreifende Karte: eine Reihe von <link rel="alternate">- Annotationen (oder das Sitemap-/Header-Äquivalent), welche die anderen URLs der alternativen Sprach-/Regionsversionen dieser Seite und deren jeweilige Sprache anvisiert. Es ist ein Routing-Signal, das Google tatsächlich verwendet – um die richtige URL- Variante in den Ergebnissen auszuliefern – kein Erkennungssignal.

Sie können und sollten oft koexistieren. Eine mexikanisch-spanische Seite trägt <html lang="es-MX">, das ihren eigenen Inhalt beschreibt, und eine Reihe von hreflang-Tags, die auf ihre en-US-, en-GB- und andere Geschwisterseiten verweisen. Die vollständige Implementierung von hreflang – die drei Methoden, die Regel der gegenseitigen Verlinkung, die selbstreferenzielle Regel und das Ausmaß, in dem sie häufig bricht – ist ein eigenes Thema; dieser Artikel leitet sie bewusst nicht erneut ab. Das Eine, das man mitnehmen sollte: lang ist die einfache Hälfte dieses Paares (ein Wert, ein Element, keine Gegenseitigkeit), gerade weil es nicht die komplexe Beziehung zwischen Seiten trägt, die hreflang hat – was John Mueller einmal als “one of the most complex aspects of SEO” (Übersetzung) „einen der komplexesten Aspekte der SEO“ bezeichnete. Leicht zu setzen ist jedoch nicht dasselbe wie häufig korrekt.

`lang` describes this document for browsers and assistive technology; hreflang maps alternate URLs for search-result routing. Quelle: Google Search Central

The root lang attribute gives one page a BCP 47 language self-description used by browsers and screen readers. Hreflang is a reciprocal cross-page map between alternate URLs, such as en-US and es-MX versions. Google detects a page's language from visible content rather than either annotation, but the lang value should remain accurate and consistent with the hreflang entry for the same URL.

© Patrick Stox LLC · CC BY 4.0 ·

Ist das lang-Attribut ein Google-Ranking-Faktor?

Kurze Antwort: nein, und Google war dabei ungewöhnlich deutlich. Die definitive Aussage stammt von John Mueller, berichtet von Barry Schwartz bei Search Engine Roundtable in Google: Wir ignorieren das HTML-lang-Attribut. Auf die Frage, wie wichtig es sei, die Sprache einer Seite im HTML zu deklarieren, sagte Mueller:

“We don’t use that at all. So we use the hreflang links if you have that if you have different language versions. But the language attribute within the HTML markup is something we don’t use at all. We’ve found that this language markup is something that is almost always wrong. So we tend to ignore that.” (Übersetzung) „Dieses Attribut nutzen wir überhaupt nicht. Falls verschiedene Sprachversionen existieren, verwenden wir die hreflang-Links. Das Sprachattribut im HTML-Markup berücksichtigen wir dagegen nicht. Unserer Erfahrung nach ist diese Sprachkennzeichnung fast immer falsch, weshalb wir sie üblicherweise ignorieren.“

Dieses “fast immer falsch” ist der Schlüsselbegriff. Googles Grund, lang zu ignorieren, ist nicht “es ist unwichtig” – es ist, dass das Signal im Web-Maßstab unzuverlässig ist. Leute lassen Standard-lang="en"-Boilerplate nach der Lokalisierung von Inhalten stehen; CMS- und Framework-Templates liefern einen Standard, der nie aktualisiert wird (das generierte Boilerplate von Vue CLI zum Beispiel kodiert lang="en" hart, unabhängig davon, was Sie damit bauen). Wenn ein Signal so oft falsch ist, ist die vernünftige technische Maßnahme, es nicht mehr zu vertrauen und die Sprache direkt aus dem Inhalt zu erkennen – was genau das ist, was Google laut eigener Aussage tut. Dieses Zitat von 2016 ist alt, aber das aktuelle (2026) Search-Central-Dokument, das oben zitiert wird, wiederholt dieselbe Richtlinie unabhängig, also behandeln Sie es als langjährige, nicht zurückgezogene Anleitung und nicht als veraltete Einzelaussage.

Die eine Ausnahme: maschinell übersetzter Inhalt

Es gibt eine einzige, enge Stelle, an der Googles Dokumentation doch einen lang-artigen Wert berücksichtigt. Wenn Sie maschinell übersetzten Inhalt veröffentlichen, bittet Googles Anleitung zu übersetzten Ergebnissen Sie, diese Blöcke mit einem speziellen Wertformat zu kennzeichnen – lang="<target>-x-mtfrom-<source>", z. B. lang="es-x-mtfrom-en" für Inhalte, die maschinell aus dem Englischen ins Spanische übersetzt wurden. Das ist die eng begrenzte Ausnahme von der Regel: Google ignoriert lang für die allgemeine Spracherkennung, aber diese spezielle Kennzeichnungskonvention ist eine, die es definiert und liest. (Der verwandte Hebel, wenn Sie sich vollständig von Übersetzungsfunktionen abmelden möchten, ist die notranslate-Regel – “To opt out of all translation features in Google Search, use the notranslate rule, which can be implemented as a meta tag or an HTTP header,” (Übersetzung) „Um alle Übersetzungsfunktionen in der Google-Suche zu deaktivieren, verwenden Sie die notranslate-Regel, die als Meta-Tag oder HTTP-Header implementiert werden kann.“ laut demselben Dokument.)

Nutzt Bing das lang-Attribut?

Ja – und hier wird lang tatsächlich folgenreicher, als die Geschichte “Google ignoriert es” vermuten lässt. Bings Haltung ist das Gegenteil von Googles, und sie wird fast überall unterbelichtet.

In seinem Webmaster-Blogbeitrag von 2011 So teilen Sie Bing Land und Sprache Ihrer Website mit legt Bing eine Prioritätsreihenfolge von “Dokumentstandort”-Signalen dar, die es für die Relevanz verwendet. Die Reihenfolge, von oben nach unten:

  1. Der content-language Meta-Tag im <head> (<meta http-equiv="content-language" content="en-us">).
  2. Das <html lang="en-us">-Attribut, dann das <title lang="en-us">-Attribut als Fallbacks – “the priority order for these tags is: <meta>, <html>, <title>.” (Übersetzung) „Die Prioritätsreihenfolge für diese Tags lautet: <meta>, <html>, <title>.“
  3. ccTLD.
  4. Reverse-IP-Lookup – wird nur verwendet, wenn die höheren Signale nicht eindeutig sind.

Bings Rat ist, eine Option zu wählen und konsistent zu bleiben: “It’s best that you use one option, instead of multiple options here.” (Übersetzung) „Verwenden Sie hier am besten eine einzige Option statt mehrerer.“ Anders als Google verwendet Bing also explizit <html lang> als echtes (wenn auch niedriger priorisiertes) Targeting-Signal. Für eine Website mit nennenswertem Bing-Traffic ändert das die empfohlene Maßnahme: Setzen Sie lang korrekt und erwägen Sie zusätzlich einen passenden content-language-Meta-Tag.

Hinweis: Dies ist ein Beitrag von 2011, der inzwischen aus dem aktuellen Blog-Archiv von Bing entfernt wurde. Ich zitiere ihn über die Wayback-Machine-Aufnahme; keine neuere Bing-Aussage ersetzt ihn, soweit ich finden konnte, daher behandle ich den Mechanismus als weiterhin aktuell – aber sein Alter sollte ehrlich erwähnt werden, statt ihn als frische Anleitung zu präsentieren.

Das schließt auch den Kreis zur hreflang-Seite: Bing nutzt hreflang kaum so wie Google – content-language plus lang ist Bings paralleler Mechanismus.

Warum das lang-Attribut trotzdem wichtig ist: Barrierefreiheit

Selbst wenn man die Suche völlig beiseitelässt, verdient lang seinen Platz. Es ist ein erforderliches Barrierefreiheitsattribut – WCAG-Erfolgskriterium 3.1.1 (Level A) verlangt, dass die Standardsprache jeder Seite programmatisch bestimmbar ist, was in der Praxis ein gültiges <html lang> bedeutet. Ein separates Kriterium, 3.1.2, behandelt die Kennzeichnung von Sprachwechseln innerhalb einer Seite.

Evidence for this claim WCAG 2.2 success criterion 3.1.1 requires the default human language of a page to be programmatically determinable, and W3C lists lang on the html element as a sufficient HTML technique. Scope: WCAG 2.2 Level A language-of-page requirement for HTML documents. Confidence: high · Verified: W3C: Understanding Language of Page

Die nachgelagerten Effekte sind konkret und gut dokumentiert (Adrian Rosellis On Use of Lang Attribute dokumentiert viele): Screenreader verwenden lang, um die richtige Aussprache-Engine und Stimme auszuwählen (JAWS’ phonetische Engine, VoiceOvers automatische Stimmschaltung), CSS hyphens: auto hängt davon ab, das spellcheck-Verhalten richtet sich danach, die Darstellung von Anführungszeichen und die Standardauswahl von CJK-Schriftarten folgen ihm, und Braille-Displays verhalten sich damit unterschiedlich. Wie genau sich das jeweils auswirkt, variiert je nach Screenreader, Browser und installierter Stimme – Rosellis eigene Tests zeigen, dass JAWS und VoiceOver sich nicht identisch verhalten – behandeln Sie einen korrekten lang-Wert also als Ermöglichung des richtigen Verhaltens, nicht als Garantie für eine identische Erfahrung über jeden Assistenztechnologie-Stack hinweg.

Und es ist kein gelöstes Problem. Laut dem aktuellen Bericht WebAIM Million liegt „missing document language“ bei 13,5 % der Startseiten – der sechsthäufigste automatisierte Barrierefreiheitsfehler im Web. Die Rate verbessert sich (gesunken von 15,8 % im Vorjahr und 17,1 % bzw. 18,6 % davor), aber „ein großes, schrumpfendes Problem“ ist immer noch ein Problem. Googles eigene Tools spiegeln diese Einordnung wider: Die html-has-lang- und html-lang-valid-Prüfungen von Lighthouse liegen unter der Kategorie Accessibility, nicht unter SEO – ein deutliches Zeichen, dass selbst Googles Entwicklertools lang als A11y-Thema einordnen, nicht als Ranking-Faktor. Diese Prüfungen basieren auf Deques axe-core-Regel gleichen Namens, die ein fehlendes lang als WCAG-2,0/2.1-Level-A-„Serious“-Problem einstuft.

Browserverhalten: die Auto-Übersetzen-Aufforderung

Es gibt noch ein sichtbares Verhalten, das lang steuert: die Aufforderung des Browsers „Diese Seite übersetzen?“. Chrome (und andere) gewichten lang neben der Analyse des tatsächlich sichtbaren Textes, wenn sie entscheiden, ob eine Übersetzung angeboten wird. Ein falscher oder fehlender Wert kann in beide Richtungen fehlschlagen – fälschlich anbieten, eine Seite zu übersetzen, die bereits in der Sprache des Lesers vorliegt, oder es bei einer wirklich fremden Seite nicht anbieten.

Das anschauliche Praxisbeispiel ist Manuel Matuzovics Das lang-Attribut: Browser, die süße kleine Lügen erzählen: der österreichische Sender ORF.at lieferte deutsche Inhalte mit lang="en" aus, woraufhin die automatische Übersetzung von Chrome den deutschen Text als Englisch behandelte und „übersetzte“, wobei der Wiener Bezirksname „Liesing“ in das englische Wort „lies“ verwandelt wurde. Das ist die Falle des Standard-Boilerplates, die einen sichtbaren Fehler erzeugt – genau die Klasse von Problemen, die Mueller mit „almost always wrong“ beschrieb.

So setzen Sie es richtig

  • Verwenden Sie ein gültiges BCP-47-Tag. Nur das Sprach-Subtag (en, es, fr), wenn Sie keine regionale Unterscheidung benötigen; Sprache-Region (en-US, en-GB, pt-BR), wenn doch. Entnehmen Sie die Codes aus dem IANA-Register der Sprach-Subtags; erfinden Sie keine, und denken Sie an GB, nicht UK.
  • Setzen Sie es auch auf dem Element, das sich ändert. Für einen eingebetteten fremdsprachigen Ausdruck auf einer ansonsten einsprachigen Seite setzen Sie lang lokal zurück: <span lang="fr">c'est la vie</span>. Nicht überschriebene Nachkommen erben das lang des nächsten Vorfahren, sodass der Wurzelwert alles abdeckt, was Sie nicht überschreiben.
  • Entfernen Sie den Boilerplate-Standard. Das lang="en", das Ihre Vorlage oder Ihr CMS mitgeliefert hat, ist nur korrekt, wenn Ihr Inhalt tatsächlich auf Englisch ist. Das ist der Fehler, den Mueller ansprach, und der ORF.at-Bug im Miniaturformat – prüfen Sie darauf.
  • Halten Sie lang und hreflang konsistent. Wenn das lang einer Seite es-MX angibt, aber die hreflang-Annotation für dieselbe URL en sagt, ist das ein Widerspruch. Es ist genau das Problem „Abweichung zwischen hreflang und HTML-lang“, das ich in Ahrefs-Hreflang-Leitfaden dokumentiert habe – wo ich es klar formuliert habe: “Google doesn’t use the HTML language attribute, but other search engines and browsers do. It’s important to keep these two attributes consistent with one another.” (Übersetzung) „Google verwendet das HTML-Sprachattribut nicht, aber andere Suchmaschinen und Browser schon. Es ist wichtig, diese beiden Attribute konsistent zu halten.“ Google ignoriert die lang-Hälfte dieses Vergleichs, aber ein Widerspruch signalisiert dennoch, dass etwas falsch konfiguriert ist – weshalb Site-Audit-Tools es markieren.

Häufige Mythen

  • „Korrektes lang verbessert meine Google-Rankings.“ Nein. Google gibt an, dass es lang für die Spracherkennung überhaupt nicht verwendet. Es kann für Bing relevant sein und indirekt über Barrierefreiheit und Übersetzungsverhalten helfen, aber ein direkter Google-Ranking-Vorteil ist nicht belegt.
  • „lang und hreflang sind im Grunde dasselbe.“ Nein – lang beschreibt die Seite, auf der es steht; hreflang verweist auf andere URLs. Eine Seite kann ein korrektes lang und kein hreflang haben, oder korrektes hreflang und ein falsches lang.
  • „Keine Suchmaschine kümmert sich um lang.“ Bing tut es ausdrücklich (als Fallback hinter content-language). Für jede Website mit echtem Bing-Traffic ist das keine „interessiert niemanden“-Situation.
  • „Das Standard-lang="en" zu belassen ist harmlos, wenn mein Inhalt nicht Englisch ist.“ Das ist nahezu wortwörtlich der Fehler, den Mueller als „almost always wrong“ bezeichnete, und es ist das, was falsche Übersetzungsaufforderungen und falsche Screenreader-Aussprache auslöst.
  • „Korrektes lang bringt eine 22 % höhere Klickrate“ / „KI-Crawler verarbeiten lang-getaggte Seiten 40 % schneller.“ Diese konkreten Zahlen kursieren auf einigen SEO-Marketing-Blogs ohne nachvollziehbare Studie, Methodik oder Primärquelle. Ich konnte keine davon mit einer offiziellen Aussage oder Erstanbieterdaten untermauern – betrachten Sie solche Zahlen als selbstbewusst klingende, unbegründete Folklore, die sich um wenig geprüfte technische Themen ansammelt.
  • „Ein leeres lang="" ist dasselbe wie keines zu haben.“ Nein – ein expliziter leerer Wert bedeutet „unbekannte Sprache“, ein eigener Zustand gegenüber einem wirklich fehlenden Attribut.

Wo dies einzuordnen ist

Dies ist der Deep Dive auf Attribut-Ebene des HTML-SEO-Teilclusters – das Gegenstück zur Behandlung auf Element-Ebene von <article>, <nav> und <main> im semantischen HTML-Artikel sowie zum breiteren HTML-SEO-Hub darüber. Für die vollständige Geschichte des seitenübergreifenden Targetings – die drei Implementierungsmethoden, die Regeln für gegenseitige Verweise und wie oft Cluster in großem Maßstab brechen – ist der hreflang-Deep-Dive der richtige Ort; die Aufgabe dieses Artikels ist es nur, die beiden Konzepte im Kopf auseinanderzuhalten.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.