Zwei Punkte im Check sehen unscheinbar aus: „Mobile-Viewport, bestanden" und „HTML-Sprache, bestanden, de". Beide bestehen oft, ohne dass jemand je darüber nachgedacht hat, weil ein gutes Theme sie automatisch setzt. Genau deshalb lohnt der Blick darauf, denn wenn sie fehlen oder falsch stehen, merkt man es lange nicht, und der Schaden ist trotzdem real. Das Viewport-Tag entscheidet, ob deine Seite auf dem Smartphone benutzbar ist. Das lang-Attribut entscheidet, ob Google, Screenreader und Browser-Übersetzer die Sprache deiner Seite kennen. Zwei einzelne Code-Zeilen, beide mit Wirkung weit über ihre Größe hinaus.
Das Viewport-Meta-Tag, eine Zeile mit großer Wirkung
Das Viewport-Tag ist eine einzelne Zeile im <head> der Seite. Sie sieht so aus:
<meta name="viewport" content="width=device-width, initial-scale=1" />
Was sie tut, versteht man am besten über das Problem, das sie löst. Ohne dieses Tag geht ein Smartphone-Browser davon aus, er müsse eine breite Desktop-Seite anzeigen, und quetscht das gesamte Layout auf die kleine Bildschirmbreite zusammen. Das Ergebnis: Die Seite erscheint winzig, der Text ist unlesbar klein, und der Nutzer muss mit zwei Fingern hineinzoomen und seitlich scrollen, um überhaupt etwas zu erkennen.
Das Tag sagt dem Browser: „Nimm als Breite die tatsächliche Gerätebreite und stelle den Zoom auf normal." Erst damit kann ein responsives Design seine Wirkung entfalten und sich sauber an das jeweilige Display anpassen. Die Seite zeigt dann auf dem Handy eine handytaugliche Ansicht, auf dem Tablet eine breitere, auf dem Desktop die volle. Das Tag selbst macht die Seite nicht responsiv, das ist Aufgabe des CSS, aber ohne das Tag bleibt selbst das beste responsive Design auf dem Handy wirkungslos.
Warum Mobile heute zuerst zählt
Die Bedeutung des Viewport-Tags lässt sich nur verstehen, wenn man weiß, wie Google heute arbeitet. Google indexiert Webseiten seit Jahren nach dem Prinzip Mobile First. Das heißt: Nicht die Desktop-Version deiner Seite ist die Grundlage für die Bewertung, sondern die mobile. Was auf dem Handy schlecht funktioniert, schadet dem Ranking auch dann, wenn die Desktop-Version perfekt ist. Google beschreibt dieses Vorgehen in der eigenen Dokumentation zur Mobile-First-Indexierung ausführlich.
Dahinter steht eine simple Realität: Bei den meisten Webseiten kommt heute über die Hälfte des Traffics vom Smartphone, in vielen Branchen deutlich mehr. Eine Seite, die auf dem Handy unbenutzbar ist, verliert also nicht eine Randgruppe, sondern die Mehrheit ihrer Besucher. Wer das Viewport-Tag vergisst, baut praktisch eine Seite, die für die wichtigste Geräteklasse kaputt ist.
Der Effekt verbindet sich direkt mit der Ladezeit. Eine mobil schlecht aufgesetzte Seite ist meist auch eine langsame Seite, weil sie überdimensionierte Desktop-Ressourcen aufs Handy lädt. Wie stark Geschwindigkeit das Ranking beeinflusst, vertieft der Beitrag zu Ladezeit und Core Web Vitals. Mobile-Tauglichkeit und Tempo gehören zusammen, und beide entscheiden sich oft an genau diesem einen Tag.
Ein Beispiel aus der Praxis zeigt, wie folgenschwer das fehlende Tag sein kann. Ein Handwerksbetrieb hatte eine Webseite aus dem Jahr 2013, die nie überarbeitet wurde. Am Desktop sah sie ordentlich aus, doch auf dem Smartphone erschien die ganze Seite als winziges, unlesbares Miniaturbild, weil das Viewport-Tag fehlte. Die Inhaber wunderten sich, warum kaum Anfragen über die Seite kamen, obwohl sie für ihre Dienstleistung durchaus rankte. Der Grund: Drei Viertel der Besucher kamen vom Handy, sahen die unbenutzbare Miniatur und sprangen sofort ab. Das Nachrüsten des Viewport-Tags und ein schlankes responsives Layout verdoppelten die Verweildauer und die Anfragen innerhalb weniger Wochen. Eine einzige fehlende Zeile hatte die Mehrheit der Besucher abgewiesen.
Was mobiltauglich noch ausmacht
Das Viewport-Tag ist die Eintrittskarte, aber allein macht es eine Seite noch nicht angenehm bedienbar. Drei weitere Dinge entscheiden, ob die mobile Ansicht wirklich funktioniert.
Tippziele groß genug. Auf dem Handy bedient man mit dem Finger, nicht mit einem präzisen Mauszeiger. Buttons und Links, die zu klein oder zu eng beieinander liegen, führen zu Fehlklicks und Frust. Eine Mindestgröße von etwa 48 Pixeln und genug Abstand zwischen den Elementen macht den Unterschied zwischen flüssiger Bedienung und Genervtsein.
Lesbare Schriftgröße. Was am Desktop noch geht, ist auf dem kleinen Bildschirm oft zu klein. Eine Grundschriftgröße, bei der man ohne Zoomen lesen kann, ist Pflicht. Wer den Nutzer zum Vergrößern zwingt, hat schon halb verloren.
Kein horizontales Scrollen. Wenn der Nutzer auf dem Handy nach rechts wischen muss, weil ein Element breiter ist als der Bildschirm, stimmt etwas nicht. Häufige Ursachen sind feste Pixelbreiten, überbreite Tabellen oder große Bilder ohne Begrenzung. Eine mobiltaugliche Seite passt in die Bildschirmbreite, immer.
Diese drei Punkte sind das, was Google unter Mobilfreundlichkeit zusammenfasst. Das Viewport-Tag öffnet die Tür, aber durch sie hindurchgehen muss das Design.
Das lang-Attribut, das die Sprache deklariert
Der zweite Tag steht ganz oben im HTML, am öffnenden <html>-Element:
<html lang="de">
Dieses kleine Attribut deklariert die Hauptsprache der Seite. Es klingt nach einer Formalität, hat aber drei konkrete Wirkungen, die ohne es alle ins Leere laufen.
Erstens die Aussprache durch Screenreader. Ein Vorleseprogramm für blinde Nutzer muss wissen, in welcher Sprache es einen Text vorlesen soll, sonst spricht es deutsche Wörter mit englischen Lautregeln aus, was unverständlich klingt. Das lang-Attribut gibt dem Screenreader genau diese Information.
Zweitens das Verständnis durch Google. Die Sprachangabe hilft der Suchmaschine zu bestätigen, in welcher Sprache deine Seite verfasst ist, und sie den richtigen Nutzern auszuspielen. Bei mehrsprachigen Seiten ist sie die Grundlage, auf der die Sprachverknüpfungen über hreflang überhaupt erst sauber funktionieren.
Drittens die Browser-Übersetzung. Die automatische Übersetzungsfunktion moderner Browser greift nur zuverlässig, wenn die Ausgangssprache korrekt deklariert ist. Steht dort die falsche Sprache, schlägt der Browser womöglich eine Übersetzung vor, wo keine nötig ist, oder unterlässt sie, wo sie gebraucht würde.
Probier es selbst: Der kostenlose SEO-Check unter yourseo.app/analyse prüft, ob deine Seite ein Viewport-Tag und eine gültige Sprachangabe hat, zusammen mit zehn weiteren Onpage-Feldern. So siehst du in unter 30 Sekunden, ob die beiden Grundlagen stehen.
Beide Tags richtig setzen
Bei beiden gibt es eine kleine Zahl von Regeln, die fast alles abdecken.
Das Viewport-Tag genau so übernehmen. Die Standardzeile width=device-width, initial-scale=1 passt für nahezu jede Seite. Finger weg von Einstellungen, die das Zoomen verbieten, etwa maximum-scale=1 oder user-scalable=no. Das mag ordentlich aussehen, nimmt aber sehbehinderten Nutzern die Möglichkeit, die Seite zu vergrößern, und ist ein Barrierefreiheits-Verstoß. Zoomen erlauben ist Pflicht, nicht Option.
Die Sprache nach Standard angeben. Das lang-Attribut nutzt die Sprachkürzel nach dem Standard BCP-47. Für reines Deutsch genügt de, für eine regionale Variante gibt es de-DE, de-AT oder de-CH. Für die meisten Seiten reicht das schlichte de völlig. Das W3C erklärt in seiner Anleitung zu Sprachangaben, wann eine Regionsangabe sinnvoll ist und wann sie überflüssig wird.
Sprache und Inhalt müssen zusammenpassen. Das Attribut muss die tatsächliche Sprache der Seite nennen. Eine englische Seite mit lang="de" ist schlimmer als gar keine Angabe, weil sie Screenreader und Suchmaschine aktiv in die Irre führt. Bei mehrsprachigen Websites trägt jede Sprachversion ihre eigene korrekte Angabe.
Einzelne fremdsprachige Abschnitte auszeichnen. Steht in einer deutschen Seite ein englisches Zitat, kann dieser Abschnitt ein eigenes lang="en" am umschließenden Element bekommen. Dann liest der Screenreader genau diesen Teil mit englischer Aussprache, den Rest auf Deutsch. Das ist Feinschliff, aber bei Seiten mit vielen Zitaten ein spürbarer Gewinn an Verständlichkeit.
Häufige Fehler mit Viewport und Sprache
Vier Muster sehe ich besonders oft.
Der erste ist das komplett fehlende Viewport-Tag bei älteren Seiten. Webseiten, die vor dem Smartphone-Zeitalter gebaut und nie überarbeitet wurden, haben es schlicht nicht. Sie erscheinen auf dem Handy winzig, und in Zeiten der Mobile-First-Indexierung ist das ein gravierendes Ranking-Problem, kein kosmetisches.
Der zweite ist das Zoomverbot. Aus dem Wunsch nach einem makellosen Layout sperren manche Entwickler das Zoomen per user-scalable=no. Das schließt sehbehinderte Nutzer aus und wird von Prüfwerkzeugen als Barrierefreiheits-Mangel markiert. Ein sauberes responsives Design braucht dieses Verbot nie.
Der dritte ist die falsche oder fehlende Sprachangabe. Mal fehlt das lang-Attribut ganz, mal steht aus einer Theme-Vorlage ein lang="en" auf einer deutschen Seite, weil das Standard-Template englisch war und niemand es angepasst hat. Beides verwirrt Screenreader und Suchmaschine.
Der vierte ist die Inkonsistenz bei mehrsprachigen Seiten. Die deutsche und die englische Version tragen beide dieselbe Sprachangabe, weil sie aus derselben Vorlage stammen. Damit wird die ganze Sprachtrennung untergraben. Wie eng Barrierefreiheit und saubere Auszeichnung zusammenhängen, zeigt sich auch bei der Überschriften-Struktur, die nach demselben Prinzip funktioniert: korrekte Auszeichnung hilft Mensch und Maschine gleichermaßen. Vor dem Veröffentlichen lohnt deshalb der Blick auf das ganze Bild über einen vollständigen Onpage-Check, der Viewport und Sprache zusammen mit den übrigen technischen Feldern bewertet.
So testest du Viewport und Sprache
Beide Tags lassen sich in Minuten prüfen, ganz ohne Spezialwerkzeug. Für die mobile Ansicht öffnest du deine Seite am Desktop und ziehst das Browserfenster ganz schmal. Springt das Layout sauber in eine handytaugliche Ansicht um, sitzt der Viewport richtig. Bleibt eine winzige Desktop-Seite stehen oder erscheint eine horizontale Bildlaufleiste, fehlt das Tag oder das responsive Design. Noch genauer geht es mit der Geräte-Ansicht in den Entwicklerwerkzeugen, die du mit F12 öffnest: Dort kannst du verschiedene Smartphone-Größen simulieren und siehst sofort, wo es klemmt.
Die Sprachangabe prüfst du über den Seitenquelltext. Klick mit der rechten Maustaste auf die Seite, wähle „Seitenquelltext anzeigen" und sieh ganz oben nach, was im <html>-Element steht. Dort sollte die Sprache stehen, die auch tatsächlich auf der Seite gesprochen wird. Bei mehrsprachigen Seiten machst du diesen Test für jede Sprachversion einzeln, denn genau hier schleichen sich die Vorlagen-Fehler ein, bei denen alle Versionen dieselbe Angabe tragen.
Diese kurze Routine nach jedem Relaunch oder Theme-Wechsel verhindert, dass eine der beiden Grundlagen still verloren geht. Gerade beim Wechsel des Themes werden solche Kopf-Tags oft überschrieben, ohne dass es im Alltag auffällt.
Quick-FAQ
Macht das Viewport-Tag meine Seite automatisch mobiltauglich? Nein. Das Tag ist die Voraussetzung, aber die eigentliche Anpassung leistet das responsive CSS. Ohne das Tag wirkt das beste responsive Design nicht, mit dem Tag, aber ohne responsives Design bleibt die Seite trotzdem unbrauchbar.
Reicht lang="de" oder brauche ich de-DE?
Für die meisten Seiten reicht de. Eine Regionsangabe wie de-AT ist nur sinnvoll, wenn du gezielt regionale Unterschiede in Sprache oder Inhalt abbildest, etwa österreichische Begriffe oder Preise.
Schadet ein falsches lang-Attribut wirklich?
Ja, mehr als ein fehlendes. Eine deutsche Seite mit lang="en" lässt Screenreader den Text falsch aussprechen und kann Google bei der Spracheinordnung in die Irre führen. Lieber keine Angabe als eine falsche.
Woran erkenne ich, ob mein Theme die Tags setzt?
Über die Ansicht des Seitenquelltextes im Browser. Suche im Kopfbereich nach name="viewport" und ganz oben nach <html lang=. Beide sollten vorhanden und korrekt sein.
Ist Mobile-Tauglichkeit wirklich so wichtig wie Desktop? Sie ist wichtiger. Google bewertet vorrangig die mobile Version, und bei den meisten Seiten kommt die Mehrheit der Besucher vom Smartphone. Eine Seite mobil zu vernachlässigen heißt, den Hauptkanal zu vernachlässigen.
Muss ich das lang-Attribut auch setzen, wenn meine Seite nur eine Sprache hat? Ja. Auch eine einsprachige Seite profitiert davon: Screenreader lesen korrekt vor, und Google bekommt die Sprache eindeutig bestätigt. Das Attribut ist kein reines Mehrsprachen-Werkzeug, sondern gehört auf jede Seite, ganz gleich wie viele Sprachen es gibt.
Übernimmt mein CMS diese Tags nicht ohnehin automatisch? Oft ja, aber nicht immer korrekt. Gerade die Sprachangabe steht in vielen Standard-Themes auf Englisch, und nach einem Theme-Wechsel kann das Viewport-Tag verschwinden. Ein kurzer Blick in den Quelltext ist immer schneller als die Annahme, es werde schon stimmen. Verlassen sollte man sich nie blind auf das CMS, prüfen kostet eine Minute.
Auf einen Blick
Zwei kleine Tags, zwei große Hebel. Das Viewport-Tag macht den Weg für ein mobiltaugliches Layout frei und ist in Zeiten der Mobile-First-Indexierung kein Detail, sondern Grundlage. Das lang-Attribut deklariert die Sprache und sorgt dafür, dass Screenreader richtig vorlesen, Google die Sprache kennt und Browser-Übersetzungen greifen. Beide kosten je eine Zeile Code, beide schaden in der falschen oder fehlenden Form deutlich mehr, als ihre Größe vermuten lässt. Wer das Standard-Viewport-Tag übernimmt, das Zoomen erlaubt und die Sprache korrekt nach BCP-47 angibt, hat zwei oft übersehene Grundlagen sauber gelegt. Es ist Aufwand von wenigen Minuten, der über jede einzelne Seite und jeden mobilen Besucher hinweg wirkt. Beide zahlen unmittelbar auf die Sichtbarkeit bei Google ein.