Mobile Friendly Test

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. Mein Team und ich lassen 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.

1. Viewport: Fehlt der Tag oder hat er eine feste Breite, beheben Sie das zuerst; alle anderen Messungen hängen davon ab.
2. Horizontaler Überlauf: Ragt im Screenshot ein Bild, eine Tabelle oder ein iframe nach rechts hinaus, begrenzen Sie die Breite in Prozent.
3. Tap Targets: Geben Sie den gelisteten Elementen mehr Innenabstand oder mehr Luft zueinander.
4. LCP: Komprimieren Sie das größte Bild und liefern Sie es in passender Größe aus; dafür reicht der Bild verkleinern Rechner.
5. 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, machen mein Team und ich einen bestandenen Mobiltest in jedem Webdesign Projekt zur Abnahmebedingung; das heißt, ohne ihn gibt es keine Übergabe.

Was ist Mobile First Indexing und was ändert es für Ihre Website?

Mobile First Indexing bedeutet, dass Google für Indexierung und Ranking den Inhalt der mobilen Version einer Seite nutzt. Google hat die Umstellung über Jahre verteilt und im Oktober 2023 als abgeschlossen gemeldet. Danach crawlt Google seit dem 5. Juli 2024 auch die übrigen Websites nur noch mit dem Googlebot Smartphone. Ein Absatz, eine Überschrift oder strukturierte Daten, die nur auf dem Desktop stehen, gibt es für Google also nicht mehr.

Die Best Practices von Google Search Central lassen sich so zusammenfassen:

• derselbe Inhalt und dieselben klaren Überschriften mobil und auf dem Desktop,
• gleichwertige Titles und Meta Descriptions sowie dieselben Robots Meta Tags,
• dieselben strukturierten Daten in beiden Versionen,
• Lazy Loading ohne Wischen oder Klicken und Bilder mit demselben Alt Text.

Bei Responsive Design sind diese Bedingungen meist von selbst erfüllt, denn beide Geräte erhalten dasselbe HTML. Das Risiko entsteht dagegen bei dynamischer Auslieferung, separaten mobilen URLs und Themes, die Inhalte für Mobilgeräte kürzen. Warum strukturierte Daten so wichtig sind, zeigen wir in unserem Leitfaden zu Schema Markup.

Wie prüfen Sie mit diesem Tool den Unterschied zwischen mobiler und Desktop Version?

Wählen Sie oben im Tool den Modus Mobile First Indexing und geben Sie die Adresse ein. Unser Server ruft dieselbe Seite zweimal ab: zuerst als Googlebot Smartphone, danach als Googlebot Desktop. Anschließend stellt er 16 Prüfungen nebeneinander: Statuscode und Weiterleitungen, Title, Meta Description, Robots, Canonical, hreflang, die Überschriften H1, H2 und H3, sichtbare Wortzahl, interne Links, Bilder und Alt Texte, JSON-LD Typen, Lazy Loading, Viewport und Art der Auslieferung.

Der Übereinstimmungswert ist ein gewichteter Durchschnitt dieser Prüfungen. Abweichungen, die eine Seite aus dem Index werfen können, etwa noindex oder ein Fehlercode auf Mobilgeräten, kosten am meisten; danach folgen fehlender Text, strukturierte Daten und Überschriften. Ab 90 sind beide Versionen praktisch gleich. Unter 70 verliert das mobile Template dagegen spürbar Inhalt.

Beachten Sie eine Grenze: Das Tool liest das rohe HTML des Servers und führt kein JavaScript aus. Lädt Ihr Inhalt erst später im Browser, prüfen Sie das Ergebnis zusätzlich mit der URL Prüfung in der Search Console. Außerdem erkennen manche Sicherheitsdienste einen falschen Googlebot an der IP Adresse und sperren ihn; das Tool meldet diesen Fall eigens. Den Rest der Seite prüfen Sie mit unserem SEO Check.