technical

Viewport-Meta-Tag setzen

MetricSpot prüft auf <meta name=viewport>. Ohne dieses Tag rendern Mobilbrowser mit 980 px Desktop-Breite und zoomen heraus — die Mobile-Usability-Prüfung schlägt fehl.

Was diese Prüfung macht

Sucht nach einem <meta name="viewport">-Tag im <head> und prüft, ob mindestens width=device-width und ein initial-scale gesetzt sind. Die Prüfung fällt durch, wenn das Tag komplett fehlt oder den Zoom sperrt (user-scalable=no, maximum-scale=1.0 — beides Verstöße gegen die Barrierefreiheit).

Warum es wichtig ist

Ohne Viewport-Tag gehen Mobilbrowser davon aus, dass die Seite Desktop ist, rendern sie mit 980 px Breite und zoomen heraus, um sie auf den Bildschirm zu bringen. Das Ergebnis ist unleserlich: 4-Pixel-Text, riesige Bilder, keine Responsive-Breakpoints, weil die Viewport-Mathematik nicht stimmt.

  • Googles Mobile-First-Indexing. Seit 2021 nutzt Google primär die mobile Darstellung deiner Seite für das Ranking. Eine Seite, die die Viewport-Prüfung nicht besteht, gilt als nicht mobilfreundlich — ein Ranking-Nachteil in der mobilen Suche.
  • Core Web Vitals. LCP, CLS und INP werden standardmäßig auf Mobilgeräten gemessen. Eine Seite ohne Viewport-Tag löst Desktop-Breiten-Rendering auf einem Telefon-Canvas aus, was CLS und LCP aufbläht.
  • Nutzererfahrung. Mobiler Traffic liegt bei den meisten Sites über 60 %. Das Viewport-Tag ist das, was responsives Design überhaupt funktionieren lässt.

Wie du es behebst

Setze das in den <head>, vor allem CSS, das von der Viewport-Breite abhängt:

<meta name="viewport" content="width=device-width, initial-scale=1">

Das ist das kanonische Rezept — jedes Framework, jedes CMS und jedes moderne Starter-Template liefert es mit aus. Wenn deine Seite es nicht hat, ist das <head>-Template kaputt.

Übliche Framework-Defaults.

  • Astro — <ViewTransitions /> setzt nichts Implizites. Füge das Meta-Tag in den <head> deines Basis-Layouts ein.
  • Next.js — App Router exportiert eine viewport-Konstante aus app/layout.tsx:
import type { Viewport } from "next";

export const viewport: Viewport = {
  width: "device-width",
  initialScale: 1,
};
  • WordPress — jedes moderne Theme gibt das Tag in header.php aus. Wenn deins das nicht tut, ist das Theme aus der Zeit vor 2014.
  • Vue / Nuxt / Svelte — im Starter-index.html integriert.

Brich die Barrierefreiheit nicht. Zwei Anti-Muster blockieren Pinch-to-Zoom und verstoßen gegen WCAG 1.4.4:

<!-- Schlecht — Barrierefreiheitsverstoß -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

Beides verhindert, dass sehschwache Nutzer den Text per Pinch zoomen. iOS 13+ ignoriert user-scalable=no ohnehin. Setze keins von beiden.

Native-App-Webviews. Wenn du die Seite in eine iOS-WKWebView oder Android-WebView mit eigenen Zoom-Controls einbettest, kannst du den Viewport auf das webview-spezifische HTML beschränken — aber die öffentliche Web-Version braucht trotzdem das Standard-Tag.

Selbst auditieren:

curl -s https://yourdomain.com/ | grep -o '<meta name="viewport"[^>]*>'

Erwartet wird width=device-width, initial-scale=1. Wenn grep nichts liefert, fehlt das Tag.

Häufig gestellte Fragen

Was ist der Unterschied zwischen initial-scale=1 und width=device-width?

width=device-width setzt die Viewport-Breite auf die CSS-Pixel-Breite des Geräts (375 beim iPhone, 360 bei den meisten Androids). initial-scale=1 setzt den Initial-Zoom auf 1.0. Beide werden gebraucht — setze sie zusammen.

Soll ich viewport-fit=cover für iPhone-Notches setzen?

Nur, wenn du env(safe-area-inset-*) im CSS verwendest, um Inhalt aus der Notch / Dynamic Island zu schieben. Sonst reicht der Standardwert.

Wirkt sich das Tag auf Desktop-Browser aus?

Desktop-Browser ignorieren das Viewport-Meta-Tag komplett — sie rendern immer mit der tatsächlichen Fensterbreite. Das Tag ist Mobile-only.

Quellen

Zuletzt aktualisiert 2026-05-11