← Zurück zum Blog On-Page-SEO prüfen

Das HTML-lang-Attribut: wofür es da ist und was Google ignoriert

Das HTML-lang-Attribut: wofür es da ist und was Google ignoriert

Das HTML-lang-Attribut legt die Sprache einer Seite fest, etwa <html lang="de">. Screenreader, Browser und Übersetzungstools werten es aus. Google dagegen kaum: Die Suchmaschine erkennt die Sprache am sichtbaren Text und verknüpft Sprachversionen über hreflang. Ein falscher Wert kostet selten Rankings, ist aber trotzdem ein Fehler, und auf mehrsprachigen Websites steckt dahinter oft ein Template-Problem.

Wofür das Attribut da ist

Auf dem Wurzelelement gilt lang für das ganze Dokument. Jedes Element darin kann den Wert überschreiben, ein englisches Zitat in einem deutschen Artikel etwa mit <blockquote lang="en">.

Am wichtigsten ist es für assistive Technologien. Der Screenreader wählt anhand des Werts Stimme und Ausspracheregeln. Eine deutsche Seite, die als en ausgezeichnet ist, wird mit englischer Phonetik vorgelesen und ist kaum zu verstehen. Deshalb verlangt WCAG 2 das Attribut auf Stufe A (Erfolgskriterium 3.1.1, Sprache der Seite), 3.1.2 regelt Passagen in anderer Sprache auf Stufe AA. Lighthouse meldet im Barrierefreiheits-Audit sowohl ein fehlendes Attribut als auch einen ungültigen Wert.

Was Google damit macht

Wenig. Laut Googles Dokumentation zu mehrsprachigen Websites wird die Sprache einer Seite anhand des sichtbaren Inhalts bestimmt, nicht über Signale im Code wie das lang-Attribut. Sprach- und Länderversionen werden mit hreflang-Annotationen verbunden, im HTML, in HTTP-Headern oder in der Sitemap. Unser Leitfaden zum hreflang Checker zeigt, wie man sie prüft.

lang ist also ein Thema für Barrierefreiheit und Qualität, kein Ranking-Hebel. Als Konsistenzprüfung taugt es trotzdem: Wenn Inhalt, hreflang und lang nicht übereinstimmen, ist einer der drei falsch.

Gültige Werte: BCP 47 in der Praxis

Der Wert muss ein BCP-47-Sprach-Tag sein. Meist ist das ein Sprachcode nach ISO 639-1, bei Bedarf gefolgt von einem Ländercode nach ISO 3166-1. Ein paar korrekte Beispiele:

Groß- und Kleinschreibung spielt keine Rolle, Konvention ist aber Sprache klein, Land groß. Das Land ist optional: lang="de" ist völlig korrekt und oft die bessere Wahl, wenn sich der Inhalt nicht an ein einzelnes Land richtet.

Zwei ungültige Werte begegnen einem immer wieder. de_DE mit Unterstrich ist ein Locale-String aus serverseitigem Code, kein BCP-47-Tag. en-UK sieht richtig aus, ist es aber nicht: Der Code für das Vereinigte Königreich lautet GB, und uk ist der Sprachcode für Ukrainisch.

Typische Fehler auf Kundenwebsites

Am häufigsten: ein einziger Wert für alle Sprachen. Übersetzungs-Plugins und Headless-Frontends nutzen oft dasselbe Layout für jede Sprachversion, sodass /de/- und /fr/-Seiten mit lang="en" ausgeliefert werden. Inhalt und hreflang sagen Deutsch, das Wurzelelement sagt Englisch, und Screenreader-Nutzer hören die falsche Stimme.

Dann das fehlende Attribut. Handgeschriebene Templates, Landingpage-Baukästen und manche statischen Exporte lassen es einfach weg.

Den Rest erledigen Updates. In WordPress gibt language_attributes() im Theme-Header das Attribut aus und folgt dabei Einstellungen > Allgemein > Sprache der Website. Ein neues Theme mit fest eingetragenem <html lang="en-US"> hebelt das aus. Shopify-Themes geben normalerweise {{ request.locale.iso_code }} aus, ein individuelles Theme mit festem Wert macht alle übersetzten Märkte kaputt. Am häufigsten passiert das bei Relaunches und Plattformwechseln, deshalb gehört der Check in die SEO-Checkliste für Website-Migrationen.

So prüfen Sie es

Öffnen Sie den Quelltext und sehen Sie sich das öffnende <html>-Tag an, oder geben Sie document.documentElement.lang in der Browser-Konsole ein. Im Terminal:

curl -s https://example.com/de/ | grep -o '<html[^>]*>'

curl zeigt das HTML, das der Server ausliefert. Setzt ein JavaScript-Framework das Attribut erst im Browser, prüfen Sie zusätzlich die gerenderte Seite. Testen Sie eine URL pro Sprache und eine pro Template-Typ (Startseite, Kategorie, Artikel, Produkt), denn der Wert stammt oft aus unterschiedlichen Templates.

lang und hreflang mit Deltio im Blick

Der SEO-Scanner von Deltio liest das lang-Attribut auf jeder überwachten URL, zusammen mit Title, Meta Description, H1, Canonical und hreflang. Er meldet fehlende oder ungültige Werte und vergleicht jeden Scan mit dem vorherigen: Macht ein Deployment aus lang="de" plötzlich lang="en", bekommen Sie einen Alert per E-Mail oder Slack. Ob die angegebene Sprache zum Text der Seite passt, kann er nicht beurteilen, das bleibt Handarbeit.

Starter kostet £24 pro Monat, bei jährlicher Zahlung £20, und Sie können Deltio 14 Tage kostenlos testen.

Häufige Fragen

Beeinflusst das lang-Attribut das Google-Ranking?
Nicht direkt. Google erkennt die Sprache einer Seite am sichtbaren Inhalt und stützt sich nach eigener Aussage nicht auf das lang-Attribut. Wichtig bleibt es für Barrierefreiheit, das Verhalten des Browsers und andere Tools, die die Seite auslesen.
Muss der lang-Wert zum hreflang-Wert passen?
Beide sollten dieselbe Sprache angeben. Eine Seite mit hreflang="de" sollte lang="de" oder eine regionale Variante wie de-DE haben. Die Strings müssen nicht identisch sein, aber deutsches hreflang mit lang="en" deutet auf einen Template-Fehler hin.
Ist lang="en-UK" gültig?
Nein. BCP 47 verwendet Ländercodes nach ISO 3166-1, und der Code für das Vereinigte Königreich ist GB. Korrekt ist also en-GB. UK ist kein gültiger Regionscode, und kleingeschriebenes uk steht für Ukrainisch.
Braucht man noch das Meta-Tag content-language?
Die HTML-Spezifikation stuft das Pragma http-equiv content-language als nicht konform ein und empfiehlt stattdessen das lang-Attribut. Google ignoriert beides bei der Spracherkennung, auf neuen Seiten gibt es also keinen Grund dafür.
Meldet Deltio, wenn sich das lang-Attribut ändert?
Ja. Der SEO-Scanner von Deltio liest das lang-Attribut auf jeder überwachten URL, meldet fehlende oder ungültige Werte und vergleicht aufeinanderfolgende Scans. Jede Änderung kommt als Alert per E-Mail oder Slack.