Tools

Mobile Friendly Test

Machen Sie den kostenlosen Mobile Friendly Test und sehen Sie in einem Schritt, wie Ihre Seite auf dem Smartphone funktioniert: Viewport Tag, Schriftgröße, Tap Targets, mobiler Screenshot und Core Web Vitals. Ersatz für den eingestellten Google Test; kostenlos, ohne Anmeldung.

Mobilfreundlichkeit und Core Web VitalsGoogle Lighthouse · mobile Emulation · Felddaten echter Nutzer

Ergebnisse bleiben 1 Stunde im Cache; keine personenbezogenen Daten.

Testergebnis Wartet

Test ausstehend

Das Urteil beruht auf drei Kernprüfungen: Viewport, Schriftgröße und Tap Targets.

Viewport TagÖffnet die Seite in Smartphone Breite?
Wartet
SchriftgrößeIst der Text ohne Zoomen lesbar?
Wartet
Tap TargetsLassen sich Schaltflächen und Links bequem antippen?
Wartet
ZoomKönnen Nutzer vergrößern?
Wartet
Horizontales ScrollenPasst der Inhalt auf den Bildschirm?
Wartet

Core Web Vitals

LCP· Größter Inhalt0 s

INP· Interaktion0 ms

CLS· Layout Shift0

Gibt es Felddaten echter Nutzer, erscheinen diese zuerst, sonst die Labormessung.

Lighthouse Werte

0Leistung

0Barrierefreiheit

0Best Practices

0SEO

Ladeverlauf

Verfasst vonTalha AslanOnline Marketing Berater, Google Partner Zuletzt aktualisiert26. September 2026

Mobile Friendly Test: So funktioniert es

1Adresse eingeben
Tippen Sie die Adresse der Seite ein; fehlt https://, ergänzt das Tool es selbst. Testen Sie neben der Startseite auch Unterseiten mit viel Traffic einzeln.
2Test starten
Drücken Sie Test starten. Das Tool liest zuerst den Viewport Tag über unseren Server, danach öffnet Google PageSpeed Insights die Seite mit mobiler Emulation.
320 bis 40 Sekunden warten
Der Fortschrittsbalken zeigt, in welchem Schritt der Test steckt. Ergebnisse derselben Adresse bleiben eine Stunde im Cache; ein zweiter Test liefert daher sofort.
4Urteil und Checkliste lesen
Das Urteil oben beruht auf drei Kernprüfungen. Zudem sagt Ihnen eine rote Zeile in einem Satz, was fehlt und wie Sie es beheben.
5Screenshot und Core Web Vitals prüfen
Schauen Sie sich den Text im Smartphone Rahmen an. Auf den Karten für LCP, INP und CLS zeigt die Farbe, wo der Wert im Vergleich zu den Schwellen liegt.

Wie kommt der Mobile Friendly Test zu seinem Urteil?

Das Urteil stützt sich auf drei Kernprüfungen. Ladezeiten und Lighthouse Werte fließen dagegen nicht ein; sie stehen deshalb auf eigenen Karten.

MobilfreundlichViewport bestanden UND Schriftgröße ≥ 0,9 (falls die Prüfung vorliegt) UND Tap Targets ≥ 0,9

Probleme gefundenMindestens eine der drei Kernprüfungen ist gescheitert

TeilergebnisDer Google Test lief nicht durch, und die Viewport Daten allein reichen für kein Urteil

Viewport Prüfung

Der Tag enthält width=device-width UND die Lighthouse Prüfung zum Viewport ergibt 1 (fehlt eine Quelle, entscheidet die andere)

Tap TargetJedes Ziel mindestens 24 × 24 CSS px oder genug Abstand zwischen kleinen Zielen (WCAG 2.2, Kriterium 2.5.8)

Farbe der Core Web VitalsWert ≤ Schwelle für gut: grün; ≤ Schwelle für schlecht: orange; darüber: rot

Die Zeilen Zoom und horizontales Scrollen fließen nicht ins Urteil ein; sie erscheinen als Warnung. Mit Felddaten nutzt das Tool die CrUX Kategorie, im Labormodus zeigt es TBT statt INP.

Beispiele für Testergebnisse

Alle Zeilen sind Beispielszenarien; Urteil und Farben folgen den Regeln des Tools.

Beispielfall	Viewport	Tap Targets	LCP (Labor)	Urteil
width=device-width gesetzt, Ziele in Ordnung, LCP 2,1 s	Bestanden	Bestanden	2,1 s · Gut	Mobilfreundlich
Kein Viewport Tag, Ziele in Ordnung, LCP 1,1 s	Problem	Bestanden	1,1 s · Gut	Probleme gefunden
Feste Breite width=980, 6 kleine Links, LCP 3,2 s	Problem	Problem	3,2 s · Verbesserungswürdig	Probleme gefunden
width=device-width gesetzt, Ziele in Ordnung, LCP 4,9 s	Bestanden	Bestanden	4,9 s · Schlecht	Mobilfreundlich
width=device-width gesetzt, Google Test wegen Kontingent abgebrochen	Bestanden	Nicht geprüft	Nicht gemessen	Teilergebnis

Die vierte Zeile zeigt eine wichtige Trennung: Ein schlechter LCP ändert das Urteil nicht. Konkret öffnet die Seite auf dem Smartphone korrekt, lädt aber langsam; Tempo ist eine eigene Baustelle.

Schwellen und Quellen

Diese Schwellen nutzt das Tool für Farben und Urteil:

Kennzahl	Gut	Verbesserungswürdig	Schlecht	Quelle
LCP (größter Inhalt)	≤ 2,5 s	2,5 bis 4 s	> 4 s	web.dev
INP (Interaktion)	≤ 200 ms	200 bis 500 ms	> 500 ms	web.dev
CLS (Layout Shift)	≤ 0,1	0,1 bis 0,25	> 0,25	web.dev
TBT (Labor, mobil)	≤ 200 ms	200 bis 600 ms	> 600 ms	Lighthouse
Lighthouse Kategorie	90 bis 100	50 bis 89	0 bis 49	PageSpeed Insights
Tap Target	≥ 24 × 24 px	-	Klein und gedrängt	WCAG 2.2 (2.5.8)
Zoom	Keine Sperre oder maximum-scale ≥ 2	-	user-scalable=no oder maximum-scale < 2	WCAG 1.4.4, axe

Lesen Sie Core Web Vitals am 75. Perzentil. Die Schwellen stammen aus der Dokumentation von web.dev, Lighthouse und PageSpeed Insights. Google kann sie ändern; prüfen Sie vor wichtigen Entscheidungen die Quelle.

Was ist ein Mobile Friendly Test und was misst dieses Tool?

Ein Mobile Friendly Test prüft, ob sich eine Webseite auf dem Smartphone bequem lesen und bedienen lässt. Dieses Tool öffnet eine einzelne Adresse mit Lighthouse über Google PageSpeed Insights und emuliert dabei ein Mittelklasse Smartphone in einem langsamen Mobilnetz. Danach fasst es das Ergebnis in einem Urteil zusammen. Das Urteil beruht auf drei Kernprüfungen:

Viewport Tag: Öffnet die Seite in Smartphone Breite oder als verkleinerte Desktop Ansicht?
Schriftgröße: Können Besucher den Text ohne Zoomen lesen?
Tap Targets: Treffen Besucher Schaltflächen und Links bequem mit dem Finger?

Außerdem sehen Sie auf einem Bildschirm die Zoom Einstellung und das Risiko für horizontales Scrollen. Dazu kommen ein mobiler Screenshot, der Ladeverlauf, vier Lighthouse Werte und die Core Web Vitals. Ich lasse diesen Test in der ersten Woche jeder SEO Beratung laufen. Denn mobile Probleme fallen am Desktop kaum auf, während die meisten Kunden die Website auf dem Smartphone öffnen.

Google hat seinen Mobile Friendly Test eingestellt: Was nutzen Sie jetzt?

Google kündigte den Schritt im April 2023 an. Am 1. Dezember 2023 schaltete Google den Mobile Friendly Test, seine API und den Bericht zur mobilen Nutzerfreundlichkeit in der Search Console ab. Die Begründung war schlicht: Seit dem Start des Tools waren deutlich umfassendere Ressourcen zur Bewertung mobiler Nutzbarkeit entstanden. Deshalb verwies Google Websitebetreiber auf Lighthouse aus Chrome.

Genau diese Lücke füllt dieses Tool. Lighthouse können Sie zwar auch lokal in den Chrome DevTools starten; allerdings hängt das Ergebnis dann von Ihrem Rechner und Ihrem Netz ab. PageSpeed Insights testet dagegen auf Servern von Google mit einem festen mobilen Profil und ergänzt zudem Felddaten echter Nutzer, sofern vorhanden. Wie Sie einen Lighthouse Bericht Schritt für Schritt lesen, zeige ich im Beitrag zum Google Lighthouse Test.

Ein Detail ist wichtig: Lighthouse 13 erschien im Oktober 2025 und hat die alte Prüfung der Schriftgröße gestrichen. Außerdem hat es die Viewport Prüfung in eine neue Insight Prüfung umgebaut. Darum liest das Tool den Viewport Tag zusätzlich über unseren eigenen Server. Fehlt die Prüfung der Schriftgröße, erscheint die Zeile als Hinweis außerhalb des Urteils.

Beeinflusst Mobilfreundlichkeit das Google Ranking?

Indirekt, aber deutlich. Seit dem 5. Juli 2024 crawlt Google alle Websites mit dem Smartphone Crawler und indexiert die mobile Version jeder Seite. Text, Überschriften oder strukturierte Daten, die mobil fehlen, existieren für Google also womöglich gar nicht. Inhalte, die auf einem Mobilgerät überhaupt nicht laden, schaffen es folglich nicht in den Index.

Andererseits schreibt Google in der Dokumentation zur Page Experience klar, dass Core Web Vitals in die Rankingsysteme einfließen. Dieselbe Seite betont allerdings, dass gute Werte keine Top Position garantieren. Der relevanteste Inhalt kann auch mit schwacher Nutzererfahrung vorne landen. Meine Erfahrung aus der Praxis: Mobilfreundlichkeit und Tempo räumen Hindernisse vor gutem Inhalt weg; schwachen Inhalt heben sie allein nicht nach oben.

Wie die Ladezeit Rankings und Conversions beeinflusst, erkläre ich mit Beispielen im Beitrag Wie beeinflusst die Ladezeit SEO.

Warum ist der Viewport Tag so wichtig?

Der Viewport Tag sagt dem Browser, in welcher Breite er die Seite aufbauen soll. Fehlt er, rendern manche mobilen Browser die Seite in einer virtuellen Desktop Breite von 980 Pixeln und verkleinern sie dann auf die Bildschirmgröße. Das Ergebnis ist eine winzige Desktop Ansicht, die niemand ohne Zoomen lesen kann. Im Screenshot des Tools sehen Sie das deshalb sofort.

Der richtige Tag ist eine einzige Zeile: <meta name="viewport" content="width=device-width, initial-scale=1">. Trotzdem sehe ich in dieser einen Zeile immer wieder drei Fehler:

Feste Breite: Ein Wert wie width=980 zwingt das Smartphone in eine Desktop Breite.
Zoom Sperre: user-scalable=no oder ein maximum-scale unter 2 hindert Menschen mit Sehschwäche daran, Text zu vergrößern. WCAG verlangt mindestens 2fache Vergrößerung.
Doppelte Tags: Geben Theme und Plugin je einen Tag aus, nimmt der Browser den letzten; Ihre Einstellung verliert dann still.

Den Tag samt Title und Description erzeugen Sie bequem mit dem Meta Tag Generator.

Welche Maße gelten für Tap Targets und Schriftgröße?

Für Tap Targets ist heute WCAG 2.2 mit dem Kriterium 2.5.8 der Maßstab. Jedes Ziel sollte mindestens 24 × 24 CSS Pixel groß sein. Sonst brauchen kleine Ziele so viel Abstand, dass sich Kreise mit 24 Pixeln Durchmesser um sie nicht überschneiden. Genau diese Regel prüft die Lighthouse Prüfung target-size. Vor allem für wichtige Schaltflächen sind die 44 × 44 Pixel aus Kriterium 2.5.5 das bequemere Ziel. Die alte Lighthouse Prüfung tap-targets rechnete sogar mit 48 × 48 Pixeln.

In der Praxis finde ich diese kleinen Ziele am häufigsten: gedrängte Links im Footer, Social Media Symbole, Punkte unter Slidern und Links direkt nebeneinander im Fließtext. Zudem zerstört die Lösung selten das Design. Mehr Innenabstand (padding) vergrößert die antippbare Fläche, das sichtbare Symbol bleibt gleich.

Bei der Schriftgröße erwartete Lighthouse früher, dass mindestens 60 Prozent des Textes 12 Pixel oder größer sind. Lighthouse 13 hat diese Prüfung entfernt; einen automatischen Wert gibt es also nicht mehr. Ich empfehle für Fließtext mindestens 16 Pixel und urteile anhand des Screenshots: Wenn Sie den Text ohne Zoomen nicht lesen können, kann es Ihr Besucher auch nicht.

Wie lesen Sie die Core Web Vitals richtig?

Das Tool zeigt zwei Arten von Daten und schreibt immer dazu, welche Sie gerade sehen. Der Reiter Echte Nutzer stammt aus dem Chrome User Experience Report (CrUX). Er enthält Daten echter Chrome Nutzer, die Ihre Seite in den letzten 28 Tagen geöffnet haben; PageSpeed Insights meldet sie am 75. Perzentil. Hat die Seite zu wenig Daten, weicht PageSpeed Insights zunächst auf die gesamte Website aus. Reicht auch das nicht, erscheinen keine Felddaten.

Der Reiter Labor ist ein einzelner Lighthouse Durchlauf. Im Labor tippt niemand wirklich auf die Seite, daher kann der Test INP nicht messen; stattdessen zeigt das Tool die Total Blocking Time (TBT). Die Schwellen:

LCP: bis 2,5 Sekunden gut, über 4 Sekunden schlecht.
INP: bis 200 ms gut, über 500 ms schlecht.
CLS: bis 0,1 gut, über 0,25 schlecht.
TBT: bis 200 ms gut, über 600 ms schlecht.

Widersprechen sich beide Quellen, zählen die Felddaten, denn diese Erfahrung bewertet Google. Das Labor eignet sich dagegen ideal, um die Ursache zu finden und eine Korrektur sofort zu testen. Alle Signale zur Nutzererfahrung habe ich im Beitrag SEO und UX gesammelt.

Was sollten Sie nach dem Mobile Friendly Test zuerst beheben?

Aus einem Testergebnis mache ich eine Aufgabenliste in dieser Reihenfolge.

Viewport: Fehlt der Tag oder hat er eine feste Breite, beheben Sie das zuerst; alle anderen Messungen hängen davon ab.
Horizontaler Überlauf: Ragt im Screenshot ein Bild, eine Tabelle oder ein iframe nach rechts hinaus, begrenzen Sie die Breite in Prozent.
Tap Targets: Geben Sie den gelisteten Elementen mehr Innenabstand oder mehr Luft zueinander.
LCP: Komprimieren Sie das größte Bild und liefern Sie es in passender Größe aus; dafür reicht der Bild verkleinern Rechner.
CLS und INP: Geben Sie Bildern feste Maße und laden Sie schwere Skripte von Drittanbietern später.

Probleme aus dem Theme kehren nach jedem Flicken zurück. In so einem Fall ist ein Umbau nach dem Prinzip Mobile First auf Dauer günstiger; den Unterschied erkläre ich im Beitrag Was ist Mobile First Design. Brauchen Sie einen Neuaufbau, mache ich einen bestandenen Mobiltest in jedem Webdesign Projekt zur Abnahmebedingung; das heißt, ohne ihn gibt es keine Übergabe.

Häufige Fehler beim mobilen Test

FehlerNur die Startseite testenBesser soTesten Sie deshalb jede Vorlage mit viel Traffic einzeln. Produkt, Kategorie, Blogbeitrag und Kontaktseite enthalten unterschiedliche Elemente.
FehlerDas Browserfenster verkleinern und es mobil nennenBesser soEin schmales Fenster emuliert weder ein langsames Netz noch einen Touchscreen. Nutzen Sie die mobile Emulation von Lighthouse oder ein echtes Smartphone.
FehlerZoom mit user-scalable=no sperrenBesser soMenschen mit Sehschwäche können den Text dann nicht vergrößern. WCAG verlangt mindestens 2fache Vergrößerung, also entfernen Sie diese Einstellung.
FehlerEinen einzelnen Laborwert für endgültig haltenBesser soLaborwerte schwanken von Lauf zu Lauf. Google bewertet die CrUX Daten, deshalb zählt der Reiter Echte Nutzer, sobald es ihn gibt.
FehlerInhalte nur mobil ausblendenBesser soGoogle indexiert die mobile Version. Text, Überschriften und strukturierte Daten, die mobil fehlen, fehlen auch im Index.