Canonical: https://www.strataigize.com/de/insights/check-mobile-friendliness-website/ Description: Google hat den Mobile-Friendly-Test eingestellt. Die kostenlosen Tools, die ihn ersetzen, ein Beispiel für die PageSpeed-API und die Grenzwerte. Published: 2025-12-15T00:00:00.000Z Modified: 2026-09-06T00:00:00.000Z [← Blog](https://www.strataigize.com/de/insights/) ![](https://www.strataigize.com/blog/real/cover-check-mobile-friendliness-website.webp) # Mobile-Friendly-Test 2026: Kostenlose Tools und PSI-API Von [**Ian McGavin**](https://www.strataigize.com/de/about/team/ian/), Gründer und CMO · Veroeffentlicht 15\. Dezember 2025 · Aktualisiert 6\. September 2026 · 15 Min. Lesezeit Um 2026 die Mobilfreundlichkeit zu prüfen, testen Sie Ihre URL in Google PageSpeed Insights, prüfen sie mit Lighthouse in den Chrome DevTools, sehen sich die Breakpoints im Gerätemodus der DevTools an, lesen den Core-Web-Vitals-Bericht in der Search Console und bestätigen alles auf einem echten Smartphone. Google hat den eigenständigen Mobile-Friendly-Test im Dezember 2023 eingestellt, und diese Tools haben ihn ersetzt. In diesem Artikel 1. [Welche Prüftools für Mobilfreundlichkeit 2026 noch funktionieren](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#welche-pr%C3%BCftools-f%C3%BCr-mobilfreundlichkeit-2026-noch-funktionieren) 2. [Ein mobiles Audit mit PageSpeed Insights und Lighthouse](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#ein-mobiles-audit-mit-pagespeed-insights-und-lighthouse) 3. [Gibt es einen Ersatz für die Mobile-Friendly-Test-API?](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#gibt-es-einen-ersatz-f%C3%BCr-die-mobile-friendly-test-api) 4. [Lighthouse lokal ausführen](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#lighthouse-lokal-ausf%C3%BChren) 5. [Schritt für Schritt: Geräteemulation in den Chrome DevTools](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#schritt-f%C3%BCr-schritt-ger%C3%A4teemulation-in-den-chrome-devtools) 6. [Mobile Core-Web-Vitals-Daten in der Search Console lesen](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#mobile-core-web-vitals-daten-in-der-search-console-lesen) 7. [Die häufigsten mobilen Fehler und ihre Lösungen](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#die-h%C3%A4ufigsten-mobilen-fehler-und-ihre-l%C3%B6sungen) 8. [Unser Audit, Schritt für Schritt](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#unser-audit-schritt-f%C3%BCr-schritt) 9. [Was, wenn Sie WordPress oder Shopify nutzen](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#was-wenn-sie-wordpress-oder-shopify-nutzen) 10. [Häufige Fragen](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#h%C3%A4ufige-fragen) 11. [Vier Tools haben das eine Abzeichen ersetzt](https://www.strataigize.com/de/insights/check-mobile-friendliness-website/#vier-tools-haben-das-eine-abzeichen-ersetzt) [Uns als bevorzugte Quelle bei Google hinzufügen](https://www.google.com/preferences/source?q=strataigize.com) Eine kostenlose Google-Einstellung, um mehr unserer relevanten Artikel in Ihrer Suche zu sehen. Sie können sie jederzeit ändern. Google hat den eigenständigen Mobile-Friendly-Test im Dezember 2023 eingestellt, aber Sie können die mobile Nutzbarkeit weiterhin kostenlos prüfen. Nutzen Sie PageSpeed Insights und Lighthouse für die Leistungsdiagnose, die Chrome DevTools für Layoutprüfungen und ein echtes Smartphone für Navigation und Formulare. Diese Prüfungen beantworten unterschiedliche Fragen. Eine schnelle Seite kann trotzdem Schaltflächen haben, die man nicht erreicht, und eine gut bedienbare Seite kann trotzdem langsam laden. > Das Urteil in 20 Sekunden? Nutzen Sie unseren kostenlosen [Mobile-Friendly-Test](https://www.strataigize.com/tools/mobile-friendly-test/): URL einfügen, und Viewport, feste Breiten, zu kleine Schrift, Seitengewicht und Crawlbarkeit werden bewertet, jeweils mit der passenden Lösung. Ohne E-Mail. ![Mobiler Bericht von PageSpeed Insights mit der Felddatenbewertung der Core Web Vitals und einem Lighthouse-Leistungswert, die Prüfung, die Googles eingestellten Mobile-Friendly-Test ersetzt hat](https://www.strataigize.com/blog/real/pagespeed-result.webp) ## Welche Prüftools für Mobilfreundlichkeit 2026 noch funktionieren Der Rat, „Googles Mobile-Friendly-Test auszuführen“, ist überholt. Google kündigte an, [den Bericht zur mobilen Nutzerfreundlichkeit in der Search Console, das Tool Mobile-Friendly-Test und die Mobile-Friendly-Test-API ab dem 1. Dezember 2023 einzustellen](https://developers.google.com/search/blog/2023/04/page-experience-in-search), und die Abschaltung wurde am [4\. Dezember 2023](https://searchengineland.com/google-officially-drops-mobile-usability-report-mobile-friendly-test-tool-and-mobile-friendly-test-api-435377) öffentlich bestätigt. Googles Begründung in dieser Ankündigung: Mobile Nutzbarkeit bleibt Teil der Richtlinien zur Nutzererfahrung, aber seit 2015 sind andere Ressourcen entstanden, „including Lighthouse from Chrome“. Google hat außerdem [am 1. Dezember 2023 jede Erwähnung des Tools aus der Hilfe für die Google-Suche entfernt](https://www.seroundtable.com/google-search-consoles-mobile-usability-report-mobile-friendly-tests-are-gone-36497.html) und die URLs zur mobilen Nutzerfreundlichkeit in der Search Console auf die Property-Übersicht umgeleitet. In der [Ankündigung vom April 2023](https://developers.google.com/search/blog/2023/04/page-experience-in-search) verweist Google auf [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) als Ersatz. Ein Leitfaden, der das eingestellte Tool noch als aktive Option anbietet, ist veraltet. Ein eigenständiges Prüftool gibt es noch: [Bings Mobile Friendliness Test Tool](https://www.bing.com/webmaster/tools/mobile-friendliness). Es prüft, wie Bing die Seite mobil sieht, darunter Viewport-Konfiguration, Inhaltsbreite, Lesbarkeit und Abstand der Tippziele. Sein Urteil sagt nichts darüber aus, wie Google oder ein KI-Assistent die Seite bewertet oder zitiert. | Tool | Kosten | Was es misst | Grenzen | | --- | --- | --- | --- | | PageSpeed Insights | Kostenlos | Mobiler Lighthouse-Laborlauf plus Core Web Vitals echter Nutzer | Felddaten brauchen genug Traffic; teilbare Berichtslinks bleiben als Momentaufnahme [bis zu 30 Tage](https://developers.google.com/speed/docs/insights/release_notes) erhalten | | Lighthouse in den Chrome DevTools | Kostenlos | Leistung, Barrierefreiheit, Best Practices, SEO und Tippziele in mobiler Emulation | Nur Labor; Ergebnisse schwanken mit der Auslastung Ihres Rechners | | Gerätemodus der Chrome DevTools | Kostenlos | Layout, Überlauf und fixierte Elemente bei echten Viewport-Größen | Emulation, keine echte Hardware und keine echte Touch-Bedienung | | Core Web Vitals in der Search Console | Kostenlos | Mobile Felddaten der ganzen Website, nach URL-Gruppen | Gleitendes Fenster von 28 Tagen; keine Prüfung von Tippzielen oder Viewport | | Bing Mobile Friendliness Test | Kostenlos | Viewport, Inhaltsbreite, Lesbarkeit, Tippabstand, Plug-ins | Das Urteil von Bing, kein Rankingsignal von Google | | Echte Geräte oder BrowserStack | Gratis-Stufe, kostenpflichtige Tarife | Echte Touch-Bedienung, Gesten, Eigenheiten der Browserdarstellung | Viele Geräte kosten Geld und Zeit | | Google Mobile-Friendly-Test | Eingestellt | Nichts | Eingestellt am 1. Dezember 2023 | ### Mobile Nutzbarkeit und Mobile-First-Indexierung sind verschiedene Prüfungen Google verwendet die mobile Version eines Seiteninhalts für Indexierung und Ranking. Die [Richtlinien zur Mobile-First-Indexierung](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) unterstützen responsives Design, dynamische Bereitstellung und separate mobile URLs. Responsives Design ist die empfohlene Option, weil es sich leichter umsetzen und pflegen lässt. Prüfen Sie, ob der Googlebot mobil auf Inhalte, Bilder und Metadaten zugreifen kann. Prüfen Sie dann, wie leicht ein Mensch sie nutzen kann. Eine blockierte mobile Seite ist ein Crawling-Problem, eine gedrängte Schaltfläche ein Nutzbarkeitsproblem. Weder ein Lighthouse-Wert noch eine Messung der Tippziele allein sagt Ihnen, ob eine Seite indexiert wird. > Lieber ein fachkundiger Blick auf Ihre Website statt eines weiteren Audit-Tabs? Sehen Sie sich unsere [Leistungen zur Website-Optimierung](https://www.strataigize.com/de/services/website-optimization/) an. ## Ein mobiles Audit mit PageSpeed Insights und Lighthouse Beginnen Sie mit [PageSpeed Insights](https://pagespeed.web.dev/). URL einfügen, Test starten und den Tab „Mobil“ vor dem Tab „Desktop“ lesen. Der Bericht hat zwei Hälften, die ständig verwechselt werden: - **Felddaten** oben: Messungen echter Chrome-Nutzer aus dem Chrome UX Report, täglich aktualisiert in einem [gleitenden Fenster von 28 Tagen](https://developer.chrome.com/docs/crux/methodology/tools). Genau diese Daten nutzen Googles Signale zur Nutzererfahrung. - **Labordaten** darunter: ein einzelner simulierter Lighthouse-Lauf auf Googles Servern. Nützlich für die Diagnose, aber kein Urteil über echte Nutzer. Um eine vollständige Bewertung der Core Web Vitals mit allen drei Messwerten zu bestehen, muss eine Seite den Grenzwert „gut“ beim [75\. Perzentil für alle drei Messwerte](https://web.dev/articles/vitals) erreichen. Fehlende Felddaten bedeuten, dass der Bericht diese vollständige Bewertung nicht liefern kann; sie sind kein Beleg dafür, dass die Seite durchgefallen ist. Lighthouse kann INP aus Felddaten nicht mit einem einzelnen Navigationslauf messen. | Messwert | Gut | Schlecht | | --- | --- | --- | | Largest Contentful Paint (LCP) | 2,5 s oder weniger | über 4,0 s | | Interaction to Next Paint (INP) | 200 ms oder weniger | über 500 ms | | Cumulative Layout Shift (CLS) | 0,1 oder weniger | über 0,25 | Quelle: [Grenzwerte der Core Web Vitals auf web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds), Stand 2026. INP [hat am 12. März 2024 First Input Delay (FID) als Core Web Vital ersetzt](https://web.dev/blog/inp-cwv-march-12), ignorieren Sie also jede Checkliste, die Ihnen noch rät, FID zu optimieren. ### Zwei Änderungen an PageSpeed Insights, die die Messlatte verschoben haben Am [5\. Dezember 2024 hat PageSpeed Insights angepasst, wie stark die CPU (der Prozessor) gedrosselt wird](https://developers.google.com/speed/docs/insights/release_notes), was die Total Blocking Time in mobilen Laborläufen meist erhöht hat. Feld- und Desktop-Ergebnisse waren nicht betroffen. Wenn Ihr mobiler Laborwert gesunken ist, ohne dass etwas veröffentlicht wurde, ist das eine plausible Ursache. PageSpeed Insights (PSI) und seine API sind [am 20. Oktober 2025 auf Lighthouse 13.0 umgestiegen](https://developers.google.com/speed/docs/insights/release_notes). Versionen können ändern, welche Diagnosen Sie sehen, notieren Sie also bei jedem Ergebnis die Lighthouse-Version. Für die laufende Überwachung echter Nutzer empfiehlt Google die [CrUX API oder die CrUX History API](https://developers.google.com/speed/docs/insights/v5/get-started): Google plant, CrUX-Felddaten nicht mehr in die PSI-API aufzunehmen. ## Gibt es einen Ersatz für die Mobile-Friendly-Test-API? Die alte Mobile-Friendly-Test-API wurde mit dem Tool eingestellt. Die **PageSpeed-Insights-API** kann einen mobilen Lighthouse-Lauf automatisieren, liefert aber nicht das alte Bestanden-oder-nicht-Ergebnis zur Mobilfreundlichkeit. Layout- und Interaktionsprüfungen brauchen Sie weiterhin. Diese Anfrage fordert Diagnosen zu mobiler Leistung, Barrierefreiheit und SEO an. Ersetzen Sie die Beispiel-URL durch eine öffentliche Seite, die Sie testen möchten: ``` curl --get \ 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \ --data-urlencode 'url=https://example.com/' \ --data-urlencode 'strategy=mobile' \ --data-urlencode 'category=performance' \ --data-urlencode 'category=accessibility' \ --data-urlencode 'category=seo' ``` Googles [Einstiegsleitfaden](https://developers.google.com/speed/docs/insights/v5/get-started) erlaubt es, die API ohne Schlüssel auszuprobieren, und empfiehlt einen Schlüssel für häufige automatisierte Anfragen. Prüfen Sie das aktuelle Kontingent Ihres Projekts, bevor Sie einen Stapel planen. Kommt HTTP 429 zurück, untersuchen Sie das Kontingent, statt die Antwort als Ergebnis für die getestete Seite zu werten. Die [API-Referenz](https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed) dokumentiert die Parameter und Antwortfelder. Lesen Sie `lighthouseResult.categories` für die Kategoriewerte und `lighthouseResult.audits` für die einzelnen Ergebnisse. Die Werte liegen auf einer Skala von null bis eins; 0,92 entspricht 92 von 100. Speichern Sie `fetchTime` und `lighthouseVersion` zusammen mit der getesteten URL, damit spätere Vergleiche auf einem bekannten Lauf beruhen. Behandeln Sie HTTP-Fehler und `runtimeError`, bevor Sie eine Antwort als Audit werten. Für die Leistung im Feld nutzen Sie die [CrUX API](https://developer.chrome.com/docs/crux/api) oder die [CrUX History API](https://developer.chrome.com/docs/crux/history-api). Für eine URL gibt es womöglich nicht genug Daten echter Nutzer. Halten Sie diesen Zustand von einem schlechten Ergebnis getrennt, und melden Sie einen Laborwert nie als bestandene Core Web Vitals im Feld. ## Lighthouse lokal ausführen Lighthouse ist in die Chrome DevTools eingebaut. Öffnen Sie Ihre Seite, klicken Sie mit der rechten Maustaste, wählen Sie „Untersuchen“, öffnen Sie den Bereich **Lighthouse**, wählen Sie **Mobil** und klicken Sie auf „Bericht erstellen“. Es [läuft in Ihrem installierten Chrome und sendet Ergebnisse nie an einen entfernten Server](https://github.com/GoogleChrome/lighthouse), so können Sie auch Staging- und passwortgeschützte Versionen prüfen, die PSI nicht erreicht. Die mobile Voreinstellung ist keine Schätzung. Lighthouse wendet einen [4-fachen CPU-Verlangsamungsfaktor](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md) an, um eine Desktop-CPU auf das Niveau eines Mittelklasse-Smartphones zu bringen, dazu eine Netzwerkvoreinstellung „Slow 4G“, die das untere Viertel der 4G-Verbindungen abbildet. Die Geräteemulation nutzt ein Moto-G-Power-Profil mit einem [Viewport von 412 mal 823 und einem Geräteskalierungsfaktor von 1,75](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js), mit aktivierter Mobil- und Touch-Emulation, laut Lighthouses eigener Datei `constants.js` (eine frühere Version dieses Artikels nannte 2,625, den Skalierungsfaktor des älteren Moto-G4-Profils, das Lighthouse ausgemustert hat, nicht den aktuellen Wert). [Lighthouse 13 hat viele Leistungsaudits durch Insights ersetzt, die an den DevTools ausgerichtet sind](https://developer.chrome.com/blog/lighthouse-13-0), und `unsized-images` sowie `non-composited-animations` als Diagnosen behalten. Außerdem wurde das alte Audit zur Schriftgröße entfernt. Eine entfernte Diagnose macht unleserlichen Text nicht akzeptabel; prüfen Sie den tatsächlichen Text der Seite auf einem Smartphone. ## Schritt für Schritt: Geräteemulation in den Chrome DevTools Werte sagen Ihnen etwas über Geschwindigkeit. Die Emulation zeigt, ob die Seite nutzbar ist. Machen Sie beides. 1. Öffnen Sie die Seite in Chrome, drücken Sie das Tastenkürzel für „Untersuchen“ und schalten Sie die **Gerätesymbolleiste** ein. 2. Wählen Sie zuerst einen schmalen Viewport. Testen Sie bei 360 mal 800 und 390 mal 844, dann schrittweise bis zu Tablet-Breiten. 3. Stellen Sie die Drosselung auf **Mid-tier mobile** oder wenden Sie Slow 4G plus 4-fache CPU manuell an, passend zum Lighthouse-Profil. 4. Drehen Sie ins Querformat. Öffnen Sie in jeder Ausrichtung Ihre Hauptnavigation, ein Formular und einen Checkout- oder Kontaktschritt. 5. Beobachten Sie beim Ändern der Größe den Bereich „Elements“, um den Container zu finden, der überläuft. Was die Emulation findet und ein Wert nie finden wird: - Kleine Tippziele, die an ein Nachbarelement gedrängt sind, einschließlich der Fälle, die das [Lighthouse-Audit für Tippziele](https://developer.chrome.com/docs/lighthouse/seo/tap-targets) abdeckt - Horizontaler Überlauf durch eine Tabelle mit fester Breite, eine Einbettung oder ein zu großes Bild - Fixierte Kopfzeilen und Cookie-Banner, die auf einem kurzen Bildschirm den halben Viewport belegen - Modalfenster, deren Schließen-Schaltfläche aus dem sichtbaren Bereich geschoben wird - Eingabefelder, die beim Fokus die falsche Tastatur öffnen oder den Zoom auslösen Für angenehme Touch-Bedienelemente sollten Sie 48 mal 48 CSS-Pixel anstreben, wo das Layout es erlaubt. Die dokumentierte Regel von Lighthouse berücksichtigt sowohl die Größe des Ziels als auch die Überlappung mit benachbarten Zielen; nicht jedes kleinere Element fällt durch. Das separate [Kriterium zur Zielgröße der WCAG 2.2 AA](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) nutzt 24 mal 24 CSS-Pixel mit Abständen und weiteren Ausnahmen. Keiner der beiden Werte ist ein universeller Rankinggrenzwert von Google. Kennen Sie die Grenze. Die Emulation verkleinert einen Desktop-Browser und täuscht eine langsame CPU vor. Sie bildet weder die echte Touch-Latenz noch Eigenheiten von Safari auf iOS, die Reichweite des Daumens oder das Verhalten eines Android-Mittelklassegeräts mit einem schweren Skript unter thermischer Drosselung ab. Schließen Sie jedes Audit auf einem echten Smartphone ab. ## Mobile Core-Web-Vitals-Daten in der Search Console lesen Der alte Bericht zur mobilen Nutzerfreundlichkeit ist weg. Nutzen Sie den Core-Web-Vitals-Bericht der Search Console für die Leistung bei echten Nutzern und prüfen Sie Layout und Interaktionen separat. Öffnen Sie die [Search Console](https://search.google.com/search-console), gehen Sie zu „Core Web Vitals“ und arbeiten Sie den Bericht für Mobilgeräte ab. Google [teilt die Übersicht nach Gerät auf, fasst URLs mit ähnlicher Nutzererfahrung zu Gruppen zusammen und gibt jeder Gruppe den Status ihres schlechtesten Messwerts](https://support.google.com/webmasters/answer/9205520). Ein schlechter Messwert in einer Vorlage zieht also jede URL dieser Vorlage auf „Schlecht“. So lesen wir ihn: - Klicken Sie neben dem Diagramm für Mobilgeräte auf **Bericht öffnen** und wechseln Sie zwischen den Tabs „Schlecht“, „Optimierung erforderlich“ und „Gut“. - Lesen Sie die Tabelle „Gründe, warum URLs nicht als gut eingestuft werden“. Sie nennt den durchgefallenen Messwert und den überschrittenen Grenzwert. - Beheben Sie die Vorlage, nicht die URL. Der Status auf Gruppenebene bedeutet, dass eine Korrektur der Vorlage viele Seiten bewegt. - Nutzen Sie nach der Veröffentlichung **Überwachung starten**. Google führt eine [Überwachung über 28 Tage durch und markiert das Problem nur dann als behoben, wenn es über das gesamte Fenster ausbleibt](https://support.google.com/webmasters/answer/9205520). Zwei Einschränkungen. Die Daten sind ein gleitendes Aggregat über 28 Tage, eine Korrektur vom Dienstag zeigt sich also nicht am Mittwoch. Und Google sagt klar, dass [die Daten von PageSpeed Insights vom Core-Web-Vitals-Bericht abweichen können](https://support.google.com/webmasters/answer/9205520), weil das eine ein Laborlauf mit einem Geräteprofil ist und das andere Tausende echter Sitzungen. Wenn sie sich widersprechen, vertrauen Sie den Felddaten und nutzen den Laborlauf, um die Ursache zu finden. [web.dev erklärt den Unterschied zwischen Labor- und Felddaten](https://web.dev/articles/lab-and-field-data-differences) ausführlicher. Dieselben Messwerte stecken in unserem Vorgehen bei der [Website-Optimierung](https://www.strataigize.com/de/services/website-optimization/). ## Die häufigsten mobilen Fehler und ihre Lösungen Das sind die Fehler, für die die Tools oben gebaut sind, jeweils mit dem Grenzwert oder der Regel, die sie anwenden. | Fehler | Erkannt durch | Grenzwert oder Regel | Lösung | | --- | --- | --- | --- | | Fehlendes oder falsch konfiguriertes Viewport-Meta-Tag | DevTools-Emulation, Bing-Test | Desktop-Layout wird aufs Smartphone gezwungen | `` hinzufügen | | Langsames LCP-Hauptbild | PSI Feld und Labor, Search Console | LCP muss beim p75 bei 2,5 s oder weniger liegen | Komprimieren, moderne Formate ausliefern, das LCP-Element vorab laden, Lazy Loading dafür entfernen | | Bilder und Einbettungen ohne Abmessungen | Lighthouse-Diagnose `unsized-images` | CLS muss beim p75 bei 0,1 oder weniger liegen | Breite und Höhe oder aspect-ratio für jedes Medienelement festlegen | | Schweres JavaScript von Drittanbietern | Lighthouse für blockierende Arbeit; CrUX oder Echtnutzer-Monitoring für INP | Guter INP im Feld liegt beim p75 bei 200 ms oder weniger | Lange Tasks aufteilen; Skripte prüfen und dabei Einwilligung und nötige Funktionen erhalten | | Tippziele zu klein oder zu dicht | Lighthouse-Audit für Tippziele und Prüfung auf echtem Smartphone | Größe und Überlappung mit Nachbarzielen zählen beide | Bedienelemente vergrößern und Abstand hinzufügen; 48 px sind ein angenehmes Ziel | | Inhalt breiter als der Bildschirm | Gerätemodus der DevTools, Bing-Test | Kein horizontales Scrollen bei einem Viewport von 360 px | Flexible Tabellen, `max-width: 100%` für Medien, keine Container mit festen Pixelbreiten | | Aufdringliche Interstitials | Manuelle Prüfung auf echtem Smartphone | Inhalt beim Laden verdeckt | Vollbild-Pop-ups verzögern, verkleinern oder entfernen | | Spät ladende Schriften und eingeblendete Banner | CLS-Gruppe in der Search Console | CLS beim p75 | Schriften vorab laden, Platz für Banner und Anzeigen reservieren | Achten Sie darauf, welches Tool was erkennt. Kein einzelnes Prüftool deckt die ganze Liste ab, und genau deshalb hat das alte Bestanden-oder-nicht-Abzeichen nie gereicht. ## Unser Audit, Schritt für Schritt Das ist die Reihenfolge, die wir auf unserer eigenen Website und bei Kundenwebsites nutzen. 1. **Drei URLs wählen, nicht eine.** Startseite, eine wichtige Leistungs- oder Produktseite und ein Blogartikel. Vorlagen scheitern auf unterschiedliche Weise. 2. **Zuerst die Search Console.** Core Web Vitals, Ansicht für Mobilgeräte. Notieren Sie, welche URL-Gruppen auf „Schlecht“ oder „Optimierung erforderlich“ stehen und welcher Messwert genannt wird. Das sind echte Nutzer, das bestimmt also die Priorität. 3. **PSI für eine URL aus jeder durchgefallenen Gruppe.** Vergleichen Sie Felddaten mit Labordaten. Sagen die Felddaten „Schlecht“ und das Labor „in Ordnung“, suchen Sie nach Drittanbieterskripten, angemeldeten Zuständen oder langsamen Ursprungsservern, die ein sauberer Laborlauf nie sieht. 4. **Lighthouse lokal für dieselben drei URLs.** Mobile Voreinstellung. Lesen Sie die Diagnosen zu Tippzielen und `unsized-images` sowie den Bereich „Barrierefreiheit“ für Kontrastfehler. 5. **Gerätemodus der DevTools bei 360 mal 800.** Öffnen Sie die Navigation, ein Formular und den wichtigsten Conversion-Schritt. Drehen Sie das Gerät. Suchen Sie nach Überlauf und verdeckten Inhalten. 6. **Bings Mobile Friendliness Test** für dieselben URLs, als Urteil eines zweiten Crawlers zu Viewport, Breite, Lesbarkeit und Tippabstand. 7. **Ein echtes Smartphone, möglichst ein Android-Mittelklassegerät.** Über Mobilfunk laden, nicht über das Büro-WLAN. Die Conversion-Aktion vollständig durchspielen. 8. **Korrekturen an Vorlagen veröffentlichen, dann in der Search Console „Überwachung starten“** und mit 28 Tagen rechnen, bis die Validierung abgeschlossen ist. ### Warum Felddaten und Labordaten sich widersprechen Google sagt ausdrücklich, dass [die Daten von PageSpeed Insights vom Core-Web-Vitals-Bericht abweichen können](https://support.google.com/webmasters/answer/9205520). Labordaten sind ein simulierter Lauf mit einem Geräteprofil. Felddaten sind ein gleitendes Aggregat echter Chrome-Nutzer über 28 Tage. [Der Leitfaden von web.dev zu Labor- und Felddaten](https://web.dev/articles/lab-and-field-data-differences) nennt die üblichen Ursachen: Echte Geräte und Netze schwanken stärker als das Labor, Drittanbieterskripte verhalten sich bei echten Nutzern anders, Cache und Back-Forward-Cache verändern wiederholte Besuche, und CrUX meldet nur URLs mit genug Traffic. Wenn sie sich widersprechen, gelten die Felddaten als Urteil und der Laborlauf als Diagnose. Wenn wir eine Website prüfen, schauen wir zuerst auf die Felddaten der Search Console und nutzen dann PSI und Lighthouse, um das Element oder Skript zu benennen. Googles eigene Optimierungsleitfäden sind die Handbücher: - Langsamer LCP: [Largest Contentful Paint optimieren](https://web.dev/articles/optimize-lcp). Hauptbild komprimieren, ein modernes Format ausliefern, das LCP-Element vorab laden und nicht per Lazy Loading laden. - Hoher INP: [Interaction to Next Paint optimieren](https://web.dev/articles/optimize-inp). Lange Tasks aufteilen und JavaScript von Drittanbietern, das den Hauptthread blockiert, verzögern oder entfernen. - Hoher CLS: [Cumulative Layout Shift optimieren](https://web.dev/articles/optimize-cls). Breite, Höhe oder aspect-ratio für Bilder und Einbettungen festlegen, damit das Layout beim Laden nicht springt. Die Search Console [fasst URLs mit ähnlicher Nutzererfahrung zu Gruppen zusammen und gibt jeder Gruppe den Status ihres schlechtesten Messwerts](https://support.google.com/webmasters/answer/9205520). Eine Korrektur an einer Vorlage, etwa Bildabmessungen in einer gemeinsamen Kartenkomponente, kann viele URLs auf einmal bewegen. Nutzen Sie nach der Veröffentlichung **Überwachung starten** und warten Sie das volle Fenster von 28 Tagen ab, bevor Google das Problem als behoben markiert. Wiederholen Sie die acht Schritte nach Theme-Wechseln, nach der Installation von Plug-ins oder Apps und nach jeder Veröffentlichung im Tag Manager, dazu einmal pro Quartal nach Plan. Drittanbieterskripte sind in [Googles INP-Leitfaden](https://web.dev/articles/optimize-inp) als Risiko für den INP dokumentiert, deshalb vergleicht Schritt 3 die Felddaten mit einem sauberen Laborlauf. Für Crawling, Indexierung und die Arbeit auf der Seite rund um diese mobile Prüfung sehen Sie sich unsere Leistung zur [Suchmaschinenoptimierung](https://www.strataigize.com/de/services/website-optimization/search-engine-optimization/) an. ## Was, wenn Sie WordPress oder Shopify nutzen Beide Plattformen bringen Sie mit Konfiguration statt Code den größten Teil des Weges: - Ein responsives Theme, bei 360 px getestet, bevor Sie sich festlegen - Natives Lazy Loading überall außer beim LCP-Bild - Moderne Bildformate in der richtigen Größe, keine Desktop-Dateien, die per CSS (Cascading Style Sheets) verkleinert werden - Vorlagen von Shopify Online Store 2.0 und Bildgrößen auf Abschnittsebene - Ein Audit der installierten Apps und Plug-ins, denn jedes fügt meist rendering-blockierendes JavaScript hinzu Führen Sie Lighthouse nach jeder Änderung an Theme oder Apps erneut aus. Genau dort sinken mobile Werte unbemerkt. Wenn das Theme selbst die Grenze ist, besteht die Lösung in einem Neuaufbau auf einem modernen Framework, bei dem Leistung und SEO von Anfang an eingebaut sind, und genau das liefert unsere [Website-Entwicklung](https://www.strataigize.com/services/development-services/website-development/). ## Häufige Fragen ### Wie prüfe ich die Mobilfreundlichkeit, seit Googles Test weg ist? Führen Sie Lighthouse in den Chrome DevTools mit der mobilen Voreinstellung aus, prüfen Sie den Tab „Mobil“ in PageSpeed Insights, lesen Sie den mobilen Core-Web-Vitals-Bericht in der Search Console und bestätigen Sie alles auf einem echten Smartphone. Bings Mobile Friendliness Test liefert weiterhin ein Bestanden-oder-nicht-Urteil, wenn Sie eines möchten. ### Was ist der Unterschied zwischen mobilfreundlich und responsiv? Mobilfreundlich heißt, dass die Seite auf einem Smartphone nutzbar ist. Responsives Design passt dieselbe Seite mit flexiblen Layouts und CSS-Media-Queries an verschiedene Viewports an. Google [empfiehlt responsives Design, weil es leichter zu pflegen ist](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing), unterstützt aber auch dynamische Bereitstellung und separate mobile URLs. ### Brauche ich eine separate mobile Website? Nein. Eine einzige responsive URL ist einfacher zu pflegen, vermeidet den Umgang mit doppelten Inhalten und liefert einen einzigen Satz Signale für SEO und [Generative Engine Optimization](https://www.strataigize.com/de/insights/what-is-generative-engine-optimization/). ### Straft Google Websites ab, die nicht mobilfreundlich sind? Prüfen Sie Zugriff auf Inhalte und Nutzererfahrung getrennt. Google muss Ihre mobilen Inhalte für die Indexierung abrufen und rendern können. Core Web Vitals fließen ins Ranking ein, aber [Google sucht weiterhin nach relevanten Inhalten, auch wenn die Nutzererfahrung mangelhaft ist](https://developers.google.com/search/docs/appearance/page-experience). Ein schlechter mobiler Wert beweist für sich allein weder eine Deindexierung noch eine Abstrafung oder einen bestimmten Rankingverlust. ### Warum widersprechen sich PageSpeed Insights und die Search Console? Google sagt, dass die beiden abweichen können. Die Labordaten von PSI sind ein simulierter Lauf mit einem Geräteprofil. Die Search Console meldet ein gleitendes Aggregat echter Chrome-Nutzer über 28 Tage für eine ganze URL-Gruppe. [Googles Dokumentation zum Core-Web-Vitals-Bericht](https://support.google.com/webmasters/answer/9205520) und [der Artikel von web.dev zu Labor- und Felddaten](https://web.dev/articles/lab-and-field-data-differences) sagen beide, dass Felddaten als Urteil und Labordaten als Diagnose gelten. ## Vier Tools haben das eine Abzeichen ersetzt Das einzelne Bestanden-oder-nicht-Abzeichen ist weg und kommt nicht zurück. Was es ersetzt hat, ist besser: Feldmessung echter Nutzer, ein Laboraudit, das Sie auf Staging ausführen können, Viewport-Emulation für das Layout und das Urteil eines zweiten Crawlers von Bing. Bauen Sie Ihren Prozess um diese vier herum, priorisieren Sie nach dem, was echte Nutzer laut Search Console erleben, und korrigieren Sie Vorlagen statt einzelner URLs. Wir übernehmen das von Vancouver aus als [Website-Optimierung](https://www.strataigize.com/de/services/website-optimization/). Wenn die mobile Leistung Sie Rankings oder Conversions kostet, ist ein [Growth-Audit](https://www.strataigize.com/de/audit/) der richtige Anfang. Autor **Ian McGavin** Naechster Schritt Traffic in Ordnung, aber die Conversion auf dem Smartphone schwach? In zwanzig Sekunden wissen Sie, ob die Seite überhaupt als Mobilseite rendert. [Meine Seite testen →](https://www.strataigize.com/tools/mobile-friendly-test/) Sprechen Sie mit uns ### Sprechen Sie mit dem Team, das es betreiben würde Sagen Sie uns, wohin wir schauen sollen, und wir antworten innerhalb von 24 Stunden mit dem Startpunkt. Kein Pitch, bevor Sie den Wert sehen. [Uns als bevorzugte Quelle bei Google hinzufügen](https://www.google.com/preferences/source?q=strataigize.com) Eine kostenlose Google-Einstellung, um mehr unserer relevanten Artikel in Ihrer Suche zu sehen. Sie können sie jederzeit ändern. [Alle Website und CRO-Artikel →](https://www.strataigize.com/de/insights/topics/cro-lifecycle/) ## Wollen Sie, dass wir das fuer Sie tun? Buchen Sie eine kostenlose 30-Minuten-Beratung. Kein Pitch, bis Sie den Wert sehen. [Wachstumsberatung buchen →](https://www.strataigize.com/de/audit/) [Bewertung **5,0** auf Clutch](https://clutch.co/profile/strataigize-marketing)