Wer heute search.google.com/test/mobile-friendly aufruft, bekommt kein Eingabefeld für die eigene URL mehr, sondern die Lighthouse-Dokumentation von Chrome. Google hat den Mobile-Friendly-Test abgeschaltet, zusammen mit dem Bericht zur Nutzerfreundlichkeit auf Mobilgeräten in der Search Console. Der Blogbeitrag, mit dem das Tool 2016 vorgestellt wurde, trägt im Titel inzwischen den Zusatz „(retired)".
Nachgemessen am 23. August 2026: Die alte Adresse antwortet mit einem 302 und endet auf developer.chrome.com/docs/lighthouse/overview/.
Warum der tote Link noch überall steht
Das ist der eigentlich interessante Teil. Die Weiterleitung landet auf einer Seite, die sauber mit Status 200 antwortet. Ein Linkchecker sieht damit eine funktionierende Kette und meldet nichts. Der Verweis bleibt jahrelang stehen, ohne dass jemand darauf aufmerksam wird, und schickt Leser auf eine englische Entwicklerdoku, die ihre Frage nicht beantwortet.
755 deutschsprachige Seiten verlinken das abgeschaltete Tool nach unserer Auswertung noch mit einem Dofollow-Link. Darunter sind Handbücher von Behörden, Fachverlage und Kammern, also Seiten, die sonst gut gepflegt werden.
Gut zu wissen: Ein HTTP-Status 200 sagt nur, dass am Ende der Kette irgendein Dokument ausgeliefert wurde. Ob es inhaltlich noch zum Linktext passt, prüft kein Statuscode. Weiche Weiterleitungen auf Startseiten oder Übersichtsseiten sind der häufigste Fall von totem Link, der nirgends als tot auffällt.
Was der Test überhaupt geprüft hat
Der Mobile-Friendly-Test war ein sehr schmales Werkzeug. Er lud eine URL mit dem Smartphone-Crawler, rechnete ein paar Regeln durch und gab ein Urteil in zwei Zuständen aus: für Mobilgeräte optimiert oder nicht. Geprüft wurden im Kern das Viewport-Meta-Tag, Schriftgrößen, die Größe von Tippzielen, horizontales Scrollen und Inhalte, die auf Mobilgeräten gar nicht laufen.
Das war 2016 nützlich, weil damals viele Seiten schlicht keine mobile Version hatten. Heute liefert jedes halbwegs aktuelle Theme ein responsives Grundgerüst, und die Frage ist nicht mehr, ob eine Seite mobil funktioniert, sondern wie gut.
Lighthouse in Chrome, der offizielle Nachfolger
Google selbst verweist von der alten Adresse auf Lighthouse. Das Werkzeug steckt in jedem Chrome, es muss nichts installiert werden.
Rechtsklick auf die Seite, „Untersuchen", im Entwicklerwerkzeug den Reiter Lighthouse öffnen, als Gerät „Mobile" wählen, Analyse starten. Nach etwa einer halben Minute steht der Bericht da: Leistung, Bedienungshilfen, Best Practices und SEO, jeweils mit einer Liste der Prüfungen, die durchgefallen sind.
Der entscheidende Unterschied zum alten Test: Lighthouse sagt nicht ja oder nein, sondern nennt die Stelle. Statt „nicht für Mobilgeräte optimiert" steht dort, welches Element den Viewport sprengt und in welcher Zeile. Wie Sie die Werte lesen, steht ausführlich in unserem Beitrag zu Lighthouse und seinen Prüfkategorien.
PageSpeed Insights für den Blick von außen
Lighthouse im eigenen Browser misst auf dem eigenen Rechner, mit der eigenen Leitung und den eigenen Erweiterungen. Für einen neutralen Wert nimmt man pagespeed.web.dev. Dieselbe Prüfengine, aber auf Googles Infrastruktur, und zusätzlich mit den Felddaten aus dem Chrome User Experience Report, also echten Messwerten von echten Besuchern der letzten 28 Tage.
Die Felddaten sind der ehrlichere Teil. Ein Labortest zeigt, wie sich die Seite unter Idealbedingungen verhält. Die Felddaten zeigen, was Ihre Besucher tatsächlich erleben, mit alten Geräten und schlechtem Netz. Wo die beiden Werte weit auseinanderliegen, lohnt der genauere Blick. Die Zusammenhänge dahinter behandeln wir bei den Core Web Vitals.
Die Search Console zeigt, was Google wirklich sieht
Kein externes Werkzeug beantwortet die Frage, die im Zweifel zählt: Was hat der Googlebot von dieser Seite geladen? Dafür gibt es die URL-Prüfung in der Search Console. Sie liefert den gerenderten Quelltext, einen Screenshot der gerenderten Seite und die Liste der Ressourcen, die beim Abruf nicht geladen werden konnten.
Wer die Search Console noch nicht eingerichtet hat, findet die Schritte in unserer Anleitung zur Einrichtung der Search Console. Der Bericht zur Nutzerfreundlichkeit auf Mobilgeräten ist dort verschwunden, die URL-Prüfung nicht.
Der Geräte-Modus im Browser
Für die schnelle Sichtprüfung während der Arbeit reicht der Geräte-Modus in den Chrome-Entwicklerwerkzeugen. Er zeigt die Seite in einer gewählten Bildschirmgröße und lässt sich mit gedrosselter Verbindung kombinieren.
Er hat eine Grenze, die man kennen sollte: Er emuliert die Größe, nicht das Gerät. Touch-Verhalten, Schriftglättung, die Adressleiste, die beim Scrollen einklappt, und die tatsächliche Rechenleistung eines vier Jahre alten Android-Telefons bildet er nicht ab.
Was kein Test ersetzt
Nehmen Sie das eigene Telefon in die Hand und bedienen Sie die Seite so, wie ein Kunde es täte. Draußen, mit einer Hand, mit Sonne auf dem Display.
Was dabei auffällt und in keinem Bericht steht: Ein Formularfeld, das beim Antippen unter die eingeblendete Tastatur rutscht. Ein Cookie-Banner, dessen Schließen-Kreuz zu klein für einen Daumen ist. Eine Telefonnummer, die nicht als Anruf-Link hinterlegt ist. Ein Bildkarussell, das beim Wischen die Seite mitzieht.
Praxis-Tipp: Testen Sie mit einem alten Gerät, nicht mit dem neuesten. Wer die Seite auf einem drei bis vier Jahre alten Mittelklasse-Telefon flüssig bedienen kann, hat den Großteil seiner Besucher abgedeckt. Auf einem aktuellen Spitzenmodell fühlt sich fast jede Seite schnell an.
Die Prüfpunkte, die geblieben sind
Das Tool ist weg, die Anforderungen dahinter sind es nicht. Diese Punkte lohnen sich unabhängig davon, womit Sie messen:
- Viewport-Tag. Ohne
<meta name="viewport" content="width=device-width, initial-scale=1">rendert das Telefon die Seite als Desktop-Layout und zoomt heraus. - Tippziele. Als Faustzahl haben sich 48 mal 48 Pixel gehalten, mit etwas Abstand zum nächsten Element. Links in einer Fließtextzeile sind die häufigste Ausnahme.
- Kein horizontales Scrollen. Meist verursacht durch ein Bild ohne
max-width, eine breite Tabelle oder ein Element mit fester Pixelbreite. - Lesbare Schrift ohne Zoom. Alles unter 16 Pixeln im Fließtext wird auf dem Telefon anstrengend, besonders für ältere Leser.
- Bedienbarkeit mit dem Daumen. Wichtige Aktionen gehören in die untere Bildschirmhälfte, nicht an den oberen Rand.
Was aus dem Ranking-Faktor geworden ist
Dass Google das Testwerkzeug abgeräumt hat, heißt nicht, dass die mobile Darstellung an Gewicht verloren hat. Das Gegenteil stimmt: Google crawlt und indexiert längst nur noch die mobile Version einer Seite. Was dort fehlt, existiert für die Suche nicht. Was dort langsam ist, ist für die Suche langsam.
Der Test wurde eingestellt, weil ein binäres Urteil in einer Welt, in der praktisch jede Seite responsiv ist, keine Information mehr trägt. Die Anforderung selbst ist in die Bewertung der Seitenerfahrung eingewandert. Was das für Aufbau und Gestaltung bedeutet, steht in unseren Beiträgen zum Mobile-First Indexing und zu den Gestaltungsentscheidungen bei Mobile-First.
Den eigenen Bestand prüfen
Wenn Sie älteren Bestand pflegen, steht die alte Testadresse mit einiger Wahrscheinlichkeit noch in einem Ihrer Beiträge. Sie fällt keinem Prüfprogramm auf, weil die Kette auf 200 endet.
Unser Redirect-Checker zeigt die vollständige Weiterleitungskette samt Endadresse, sodass genau solche Fälle sichtbar werden. Er läuft im Browser, ohne Anmeldung, und erlaubt zehn Prüfungen pro Minute.
Danach ist der Austausch schnell erledigt: Wo bisher auf den Mobile-Friendly-Test verwiesen wurde, passt heute PageSpeed Insights oder Lighthouse. Und wo der Link in einer Anleitung steht, gehört meist ein Satz dazu, warum das alte Werkzeug nicht mehr existiert. Ihre Leser haben es sonst schon vergeblich versucht.