Mobile-Friendly Test: So prüfst du deine Website, nachdem Googles Tool abgeschaltet wurde

Kurz gesagt: Google hat am 1. Dezember 2023 den Mobile-Friendly Test, die Mobile-Friendly Test API und den Bericht „Nutzerfreundlichkeit auf Mobilgeräten“ (Mobile Usability) in der Search Console eingestellt. Mobile ist dadurch nicht unwichtiger geworden: Google crawlt und indexiert Websites ausschließlich mit seinem Smartphone-Crawler, und Inhalte, die sich auf einem Smartphone nicht erreichen lassen, sind nicht indexierbar. Um eine Website heute zu testen, prüfst du die Grundlagen (Viewport-Tag, skalierende Bilder, lesbarer Text, Tap-Ziele) mit einem schnellen Checker und Lighthouse, schaust dir die Seite auf echten Smartphones an und stellst sicher, dass die mobile Version dieselben Inhalte hat wie die Desktop-Version.

Jahrelang bedeutete „Mobile-Friendly Test“ nur eines: URL in Googles Tool einfügen und das grüne Banner „Seite ist für Mobilgeräte optimiert“ erhalten. Dieses Tool gibt es nicht mehr, und viele Ratgeber verlinken trotzdem noch darauf. Dieser Artikel erklärt, was passiert ist, was Google heute von mobilen Seiten erwartet, wie du sie mit funktionierenden Tools testest, darunter unser kostenloser Mobile-Friendly Test, und wie du jedes Problem behebst.

Was mit Googles Mobile-Friendly Test passiert ist

In einem Beitrag vom April 2023 zur Seitenerfahrung (Page Experience) kündigte Google an: „Also starting December 1, 2023, we'll be retiring Search Console's 'Mobile Usability' report, the Mobile-Friendly Test tool and Mobile-Friendly Test API.“ Als Grund nannte Google nicht, dass Mobile unwichtig geworden wäre. Es verwies darauf, dass inzwischen viele leistungsfähige Ressourcen zur Bewertung der mobilen Nutzbarkeit entstanden seien, „including Lighthouse from Chrome“.

Seit Dezember 2023 gibt es also kein offizielles Bestanden oder Nicht bestanden von Google mehr für die Mobilfreundlichkeit. Tools von Drittanbietern, Lighthouse und eigene Tests füllen diese Lücke.

Warum Mobile weiterhin über deine Indexierung entscheidet

Zwei Ankündigungen sind wichtiger als das eingestellte Tool:

1. Mobile-First-Indexierung ist abgeschlossen. Im Oktober 2023 schrieb Google: „the trek to Mobile First Indexing is now complete“ (Ankündigung). Die Best-Practices-Seite definiert, was das bedeutet: „Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking.“
2. Das Desktop-Crawling für die Suche ist beendet. Im Juni 2024 erklärte Google: „After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone“ und „If your site's content is not accessible at all with a mobile device, it will no longer be indexable“ (Ankündigung).

Die praktische Folge: Was deine mobile Version zeigt, ist für Google deine Seite. Text, der mobil ausgeblendet ist, ein fehlender Abschnitt oder ein anderer Title im mobilen Template wird indexiert.

Die Seitenerfahrung kommt als zweite Ebene hinzu. Googles Leitfaden zur Seitenerfahrung fragt: „Does your content display well on mobile devices?“ und sagt, dass die zentralen Ranking-Systeme „look to reward content that provides a good page experience“, betont aber zugleich, dass es kein einzelnes Signal für die Seitenerfahrung gibt.

Was „mobilfreundlich“ in der Praxis bedeutet

Eine offizielle Checkliste gibt es nicht mehr, aber Googles Dokumentation und web.dev decken das Feld ab:

Google empfiehlt Responsive Webdesign, „because it's the easiest design pattern to implement and maintain.“ Eine URL, ein HTML-Dokument, CSS, das sich anpasst: Probleme mit der Inhaltsgleichheit verschwinden dadurch größtenteils.

So testest du die Mobilfreundlichkeit heute

Nutze mehrere Tools, denn jedes zeigt einen anderen Ausschnitt:

1. Ein schneller Basis-Check. Unser kostenloser Mobile-Friendly Test prüft Viewport-Tag, responsive Bilder, Favicon und Seitensprache in etwa 20 Sekunden (Details unten).
2. Lighthouse in Chrome. Starte es in den DevTools mit der Mobile-Einstellung. Seit Lighthouse 13 (Oktober 2025) steckt die Viewport-Prüfung im Insight „Optimize viewport for mobile“, und das alte Audit zur lesbaren Schriftgröße wurde ohne Ersatz entfernt.
3. Gerätemodus der Chrome DevTools. Ziehe die Breite ab 320 px nach oben und achte auf horizontale Scrollbalken, überlappende Elemente und Text, der aus seinem Container läuft.
4. Echte Smartphones. Nutze mindestens ein kleines Android-Smartphone und ein iPhone. Probiere Menü, Formulare und Checkout mit dem Daumen aus.
5. URL-Prüfung in der Search Console. Der Live-Test zeigt einen Screenshot der Seite, wie Googlebot Smartphone sie rendert, plus das gerenderte HTML, sodass du bestätigen kannst, dass die wichtigen Inhalte vorhanden sind.
6. Geschwindigkeitsdaten echter Nutzer. Core Web Vitals für Smartphone-Besucher aus dem Chrome User Experience Report. Unser Core-Web-Vitals-Leitfaden erklärt, wie du sie liest.

So funktioniert der Mobile-Friendly Test von Searvia

Der kostenlose Mobile-Friendly Test führt unser vollständiges Website-Audit (38 Checks) aus und stellt die vier Mobile-Checks an den Anfang. Du gibst eine Domain oder eine Seitenadresse ein, und er ruft diese Seite ab (bei einer reinen Domain die Startseite), folgt Weiterleitungen und liest das HTML, das dein Server liefert, ohne JavaScript auszuführen.

Einige Details zur Bewertung:

• Der Viewport-Check schlägt fehl, statt nur zu warnen, weil eine Seite ohne Viewport-Tag auf jedem Smartphone kaputt ist und nicht bloß etwas schlechter.
• Beim Favicon zählt der Fallback /favicon.ico nur, wenn er eine echte Datei liefert und keine HTML-Fehlerseite.
• Der Sprach-Check zeigt die ersten zwei Buchstaben des Codes, en-GB erscheint also als „en“.

Der vollständige Bericht enthält außerdem den Geschwindigkeitsbereich, in dem der Core-Web-Vitals-Check die 75.-Perzentil-Werte für LCP, INP und CLS für Smartphone-Besucher aus den Echtnutzerdaten von Chrome liest: für die eingegebene Seite, wenn Chrome dafür genug Daten hat, sonst für die gesamte Website.

Was er nicht tut: Er rendert die Seite nicht in einem Browser mit Smartphone-Größe und sieht daher kein horizontales Überlaufen, keine Schriftgrößen, keine Abstände der Tap-Ziele und keine Pop-ups. Dafür sind Lighthouse, der Gerätemodus und echte Smartphones da. Betrachte den Checker als Fünf-Minuten-Triage und die manuellen Tests als die eigentliche Prüfung.

So liest du die Ergebnisse

• Viewport fehlgeschlagen: Behebe das zuerst; nichts anderes auf der Seite zählt, solange das Layout nicht auf den Bildschirm passt.
• Warnung bei responsiven Bildern: Smartphones laden Bilder in Desktop-Größe. Das ist nicht kaputt, aber langsamer, vor allem in Mobilfunknetzen.
• Warnungen zu Favicon oder Sprache: Kleine, schnelle Korrekturen, die verbessern, wie du in den Google-Ergebnissen erscheinst und wie Screenreader die Seite behandeln.
• „Too few images to judge“: Neutral. Bei weniger als drei Bildern sagt der Anteil nicht viel aus.

So behebst du jedes Problem

„The page has no mobile viewport tag.“

1. Füge diese Zeile in jedem Template innerhalb von <head> ein:

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

1. Füge weder user-scalable=no noch einen niedrigen maximum-scale-Wert hinzu. web.dev rät davon ab, „because they can prevent the user from zooming.“
2. Prüfe, dass es nur einen Viewport-Tag gibt. Ein Theme und ein Plugin können beide einen ausgeben; der zweite kann den ersten überschreiben.
3. Lade die Seite auf einem Smartphone neu. Zeigt sie nun ein gedrängtes Desktop-Layout statt eines winzigen, funktioniert der Viewport, und das CSS braucht responsive Regeln (siehe unten).

Das Layout responsiv machen

Ein Viewport-Tag sagt dem Browser nur, dass er die Bildschirmbreite verwenden soll. Das CSS muss sich trotzdem anpassen:

• Gib Bildern und Videos max-width: 100%; height: auto;, damit sie nie überlaufen.
• Verwende flexible Breiten (Prozent, fr, min()) statt fester Pixelbreiten für Container.
• Setze Media Queries dort, wo das Design bricht, nicht bei bestimmten Gerätebreiten. web.dev: „Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary.“
• Packe breite Tabellen in einen scrollbaren Container, statt die Seite seitwärts scrollen zu lassen.

„N of M images use srcset.“

Biete mehrere Größen an und lass den Browser wählen, wie auf MDN beschrieben:

<img
  src="/img/boots-800.jpg"
  srcset="/img/boots-480.jpg 480w, /img/boots-800.jpg 800w, /img/boots-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Brown leather hiking boots on a wet rock"
  width="800" height="600">

srcset listet die Dateien und ihre Breiten auf; sizes sagt dem Browser, wie breit das Bild auf dem Bildschirm sein wird. Für Bilder mit fester Größe wie Logos nutzt du x-Deskriptoren (logo.png, logo@2x.png 2x). WordPress ergänzt srcset bei Bildern, die über den Editor eingefügt werden, automatisch; die meisten Bild-CDNs können die Größen für dich erzeugen. Ergänze auch width und height, damit der Browser Platz reserviert und das Layout nicht springt.

„No favicon was found.“

1. Erstelle ein quadratisches Icon. Google verlangt ein Seitenverhältnis von 1:1, mindestens 8 × 8 px, und empfiehlt mehr als 48 × 48 px (Favicon-Richtlinien).
2. Füge es im Head der Startseite ein:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

1. Halte die URL stabil und stelle sicher, dass die robots.txt die Datei nicht blockiert; Google muss sowohl die Startseite als auch das Icon crawlen können. Google unterstützt ein Favicon pro Hostname.

„The page does not declare its language.“

Lege die Sprache am Root-Element fest:

<html lang="de">

Verwende einen gültigen BCP-47-Code wie en, en-GB, pt-BR oder tr. Das lang-Attribut sorgt dafür, dass Screenreader Text korrekt aussprechen, und ist für das WCAG-Kriterium „Language of Page“ erforderlich (MDN). Eine Klarstellung: Google erkennt die Sprache einer Seite laut eigener Aussage am Text selbst, nicht am lang-Attribut; das ist also eher eine Korrektur für Barrierefreiheit und Browser als für das Ranking.

Über die vier Checks hinaus

Wenn die Grundlagen bestehen, arbeite die Punkte durch, die kein automatischer Checker vollständig abdeckt:

• Inhaltsgleichheit (Content Parity). Vergleiche Mobil und Desktop für dieselbe URL: Haupttext, Überschriften, Bilder mit gleichem Alt-Text, strukturierte Daten, Title, Meta-Description und Robots-Meta-Tags. Google führt all das in seinen Best Practices zur Mobile-First-Indexierung auf.
• Lazy Loading. Google warnt: „Don't lazy-load primary content upon user interaction.“ Googlebot tippt nicht auf „Mehr lesen“ und wischt nicht durch Karussells.
• Tap-Ziele. Buttons und Links mit etwa 48 × 48 px und Abstand dazwischen. Lighthouse markiert Ziele, die kleiner als 48 × 48 px sind, wenn sie Nachbarn überlappen.
• Textgröße. Fließtext, der ohne Zoomen lesbar ist. Lighthouse prüft die Schriftgröße nicht mehr, also kontrolliere sie auf einem echten Smartphone.
• Pop-ups. Cookie-Banner und Newsletter-Formulare, die auf einem kleinen Bildschirm den Inhalt verdecken, fallen unter Googles Frage zu aufdringlichen Interstitials.
• Geschwindigkeit auf Smartphones. Smartphone-CPUs und -Netze sind langsamer; prüfe die Felddaten für Mobil getrennt von Desktop.

Wenn du eine separate mobile Website betreibst

Manche ältere Websites liefern Smartphones von einer anderen Adresse aus, etwa m.example.com, oder senden unter derselben URL anderes HTML an Smartphones (Dynamic Serving). Google unterstützt beides weiterhin, aber es erschwert die Inhaltsgleichheit, und die Best Practices ergänzen zusätzliche Regeln für separate URLs:

• Der Fehlerstatus muss auf beiden Versionen gleich sein: Eine Seite, die auf dem Desktop 404 liefert, sollte mobil nicht 200 liefern, und umgekehrt.
• Die mobile Version sollte keine URL-Fragmente (#) für Inhalte verwenden.
• Die robots.txt-Regeln sollten übereinstimmen, damit Googlebot auf beiden Hosts dieselben Bereiche crawlen kann.
• Desktop-Seiten verweisen mit rel="alternate" auf ihre mobilen Versionen, und mobile Seiten verweisen mit rel="canonical" zurück.
• hreflang muss für jede Version separat eingerichtet werden.

Wenn du ohnehin einen Relaunch planst, beseitigt der Wechsel zu einem responsiven Design auf einer URL diese ganze Problemkategorie. Unser kostenloser Checker liest die Version, die dein Server an den eigenen Crawler sendet; teste bei einer Website mit Dynamic Serving die Smartphone-Version daher separat mit Lighthouse oder der URL-Prüfung.

Praxisbeispiel (hypothetisch)

Das folgende Beispiel ist hypothetisch und enthält keine echten Daten. Cobble & Crumb, eine erfundene Bäckerei mit einer 2016 von Hand programmierten Website, bekommt die meisten Besuche von Smartphones, aber kaum Bestellungen. Der Mobile-Friendly Test meldet:

• Mobile Viewport, Fehler: kein Viewport-Tag.
• Responsive Bilder: 1 von 14 Bildern nutzt srcset.
• Favicon: bestanden.
• Seitensprache, Warnung: kein lang-Attribut.

Der Inhaber ergänzt den Viewport-Tag und lang="en" und öffnet die Website auf einem Smartphone: Der Text hat nun volle Größe, aber der Container mit fester Breite von 960 px erzwingt seitliches Scrollen. Ein Entwickler ersetzt die feste Breite durch max-width: 960px; width: 100%, ergänzt max-width: 100% bei den Bildern, stapelt das dreispaltige Menü unterhalb von 600 px in eine Spalte und vergrößert die Bestell-Buttons auf 48 px Höhe. Die Produktfotos erhalten srcset mit Versionen in 480, 800 und 1600 px. Ein zweiter Durchlauf besteht bei Viewport und Sprache, responsive Bilder bestehen nun mit 13 von 14, und Lighthouses Viewport-Insight ist sauber. Bleibt die Arbeit am Inhalt: Das mobile Layout hatte die Öffnungszeiten ausgeblendet, sie kommen wieder auf die Seite.

Eine Mobile-Checkliste für 30 Minuten

1. Führe den Mobile-Friendly Test aus und behebe zuerst einen fehlenden Viewport-Tag.
2. Öffne deine fünf wichtigsten Seiten auf einem echten Smartphone. Achte auf seitliches Scrollen, winzigen Text und Buttons, die schwer zu treffen sind.
3. Führe Lighthouse im Mobile-Modus auf denselben Seiten aus.
4. Vergleiche die mobilen und die Desktop-Inhalte für jedes Seitentemplate.
5. Ergänze srcset bei großen Bildern, ein Favicon und das lang-Attribut.
6. Prüfe die Core Web Vitals für Smartphones und behebe das langsamste Template.

So hilft dir Searvia, mobilfit zu bleiben

Der kostenlose Mobile-Friendly Test prüft die Grundlagen auf deiner Startseite oder einer beliebigen eingegebenen Seite in etwa 20 Sekunden und ohne Anmeldung, zusammen mit 34 weiteren Checks zu Suchauftritt, Crawling, KI-Suche-Tauglichkeit, Geschwindigkeit und Sicherheit.

Für die laufende Überwachung ergänzt ein kostenloses Searvia-Konto das Page-Speed-Tracking: Lab-Werte und echte Chrome-Nutzerdaten für deine meistbesuchten Seiten, jede Woche neu geprüft, mit Fixes, sortiert nach geschätzter Zeitersparnis. Das Site-Audit crawlt jede Seite nach Problemen, die Mobil und Desktop gleichermaßen schaden, etwa fehlende Titel, defekte Links und dünner Content. Für den Rest der technischen Checkliste lies unseren Leitfaden zum technischen SEO-Audit.