Wie lässt sich die mobile Optimierung nach der Einstellung des Google Mobile-Friendly Test überprüfen?

Google hat im Dezember 2023 den google mobile friendly test sowie den Bericht zur „Nutzerfreundlichkeit auf Mobilgeräten“ in der Search Console eingestellt. Der frühere Einstieg „einmal testen und erfahren, ob eine Seite für Mobilgeräte geeignet ist“ ist verschwunden. Das bedeutet jedoch nicht, dass die mobile Optimierung keinen Einfluss mehr auf Indexierung und Ranking hat; Google crawlt Webseiten weiterhin hauptsächlich mit dem Smartphone Googlebot und verwendet die mobilen Inhalte als Grundlage für Indexierung und Bewertung.

Was tatsächlich ersetzt werden muss, ist nicht ein grünes „Bestanden“-Symbol, sondern die Beurteilung von drei Aspekten: Kann Google die mobile Seite crawlen und rendern? Können Nutzer sie unter realen Mobilfunknetzbedingungen normal verwenden? Beeinträchtigen Geschwindigkeit und Layout-Stabilität der Seite das Nutzungserlebnis? Ein einzelnes Tool kann diese drei Punkte nicht abdecken. Die zuverlässigere Vorgehensweise besteht darin, die URL-Prüfung, PageSpeed Insights und Tests auf echten Geräten zu kombinieren.

Zuerst mit der URL-Prüfung bestätigen: Wird die Seite von Google korrekt erkannt?

Öffnen Sie in der Google Search Console die „URL-Prüfung“, geben Sie die vollständige URL ein und prüfen Sie vorrangig die indexierte Version. Hier geht es nicht darum, ob sich die Seite auf dem eigenen Computer öffnen lässt, sondern darum, ob die zuletzt von Google gecrawlte Seite indexierbar ist, ob die erwartete kanonische Seite ausgewählt wurde und ob der Crawl mit dem Smartphone Googlebot erfolgt ist.

Wenn eine Seite gerade geändert wurde und noch nicht erneut gecrawlt wurde oder wenn der Verdacht besteht, dass Google Inhalte anders als der Browser ausliest, kann „Live-URL testen“ verwendet werden. Prüfen Sie insbesondere die Crawl- und Rendering-Ergebnisse: Wenn im Screenshot leere Bereiche, fehlende Hauptinhalte, überlagernde Pop-ups, fehlerhafte Styles oder Fehlermeldungen erscheinen, liegt das Problem meist nicht an der „Bildschirmgröße“, sondern am Laden von Ressourcen, am Frontend-Rendering oder an Zugriffsbeschränkungen.

• JavaScript-Abhängigkeiten: Wenn die Hauptinhalte im sichtbaren Bereich, Produktspezifikationen oder Inhalte für den Sprachwechsel vollständig per Skript asynchron geladen werden, muss bestätigt werden, dass Google diese Inhalte nach dem Rendering tatsächlich abrufen kann.
• Zugänglichkeit von Ressourcen: Wenn CSS, JavaScript, Bild-CDNs oder Schriftdateien durch robots.txt, WAF, regionale Beschränkungen oder Anmeldeprüfungen blockiert werden, erhält Googlebot eine unvollständige Seite.
• Konsistenz des responsiven Designs: Auf Desktop- und Mobilversionen dürfen durch CSS-Ausblendungen keine wesentlichen Produktinformationen, Haupttexte, internen Links oder strukturierten Daten verloren gehen.
• Ungewöhnliche Statuscodes: Wenn der Zugriff über Mobilgeräte falsch weitergeleitet wird, 4xx/5xx zurückgibt oder auf irrelevante Seiten führt, wird das normale Crawlen beeinträchtigt.

Die URL-Prüfung eignet sich zur Beantwortung der Frage, ob die Suchmaschine die Seite sehen kann. Sie ist jedoch kein Tool für Geschwindigkeitstests und kann keine Tests der Nutzerinteraktion ersetzen. Ein unauffälliges Prüfergebnis bedeutet lediglich, dass in der Indexierungskette keine offensichtlichen Hindernisse bestehen.

PageSpeed Insights zur Erkennung mobiler Leistungs- und Layoutprobleme verwenden

PageSpeed Insights (PSI) sollte als Einstieg für die tägliche Analyse dienen. Achten Sie nach Eingabe der URL auf die Unterscheidung zwischen „echten Nutzerdaten“ und Lighthouse-Labordaten. Erstere stammen aus den Chrome UX Report-Daten qualifizierter Nutzer und spiegeln die Erfahrung bestehender Besuche wider; Letztere werden in einer simulierten mobilen Umgebung ausgeführt und eignen sich zur Identifikation aktuell reproduzierbarer Leistungsprobleme einer Seite.

Auf Mobilgeräten sollten insbesondere drei Core Web Vitals beachtet werden: LCP zeigt die Geschwindigkeit an, mit der der Hauptinhalt erscheint, INP die Reaktion auf Interaktionen wie Klicks, das Öffnen von Menüs oder das Absenden von Formularen, und CLS, ob Elemente beim Laden der Seite springen. Sie umfassen nicht die gesamte „mobile Optimierung“, decken jedoch häufig Probleme auf, die Anfragen und das Browsen beeinträchtigen, etwa unkomprimierte große Bilder im sichtbaren Bereich, zu viele Tracking-Skripte von Drittanbietern, Cookie-Banner, die Inhalte verdrängen, oder Bilder und eingebettete Inhalte ohne reservierte Abmessungen.

Die Diagnoseempfehlungen von PSI sollten anhand der tatsächlichen Seitenfunktionen beurteilt werden; eine perfekte Punktzahl sollte nicht mechanisch angestrebt werden. Auf Außenhandelswebsites erhöhen mehrsprachige Skripte, Kundenservice-Tools, Formularvalidierungen, Karten und Videos häufig den Ladeaufwand. Eine sinnvollere Reihenfolge ist: Zuerst sicherstellen, dass die Kerninhalte im sichtbaren Bereich und die Kontaktanfrage-Möglichkeiten funktionieren, dann Bilder komprimieren und nicht kritische Skripte verzögert laden und zuletzt bewerten, ob nicht notwendige Drittanbieter-Komponenten entfernt werden sollten.

Der Gerätemodus des Browsers dient nur der ersten Prüfung, Tests auf echten Geräten bleiben unverzichtbar

Über die Gerätesymbolleiste in Chrome DevTools können Bildschirmbreite, Pixeldichte und Netzwerkdrosselung schnell umgestellt werden. Sie eignet sich bei Überarbeitungen zur Prüfung von Breakpoints: Wird die Navigation korrekt eingeklappt, laufen Tabellen horizontal über, werden Buttons abgeschnitten oder verdecken fest positionierte Kontaktmöglichkeiten im unteren Bereich Formulare? Ihr Vorteil liegt in der hohen Effizienz, ihre Einschränkung darin, dass unterschiedliche Systembrowser, das Einblenden der Tastatur, Berechtigungsdialoge und reale Netzwerkschwankungen nicht vollständig simuliert werden können.

Seiten mit Kontaktanfragen, Bestellungen oder Downloads von Materialien sollten mindestens in gängigen mobilen Browsern entlang des vollständigen Pfads getestet werden: Von der Such-Landingpage aus eintreten, die Sprache wechseln, Produktdetails öffnen, auf WhatsApp, E-Mail oder Formular klicken und nach dem Absenden prüfen, ob die Erfolgsmeldung und die E-Mail-Benachrichtigung korrekt funktionieren. Viele Seiten sind optisch „angepasst“, doch Eingabefelder für internationale Vorwahlnummern öffnen keine Zifferntastatur, Bestätigungscodes werden von schwebenden Buttons verdeckt oder Datei-Uploads schlagen fehl. Solche Probleme wurden vom früheren mobile friendly test nicht automatisch erkannt.

„Responsives Design“ nicht fälschlich mit „mobil geeignet“ gleichsetzen

Responsives CSS löst das Problem, dass sich das Layout an unterschiedliche Bildschirmgrößen anpasst, kann jedoch das mobile Nutzungserlebnis nicht automatisch gewährleisten. Zu den häufigen Risiken gehören: Große Desktop-Bilder werden direkt verkleinert und verlangsamen dadurch das Laden des sichtbaren Bereichs; Produktspezifikationstabellen sind auf Mobilgeräten schwer lesbar; Menüebenen sind zu tief verschachtelt; kleine Schriftgrößen und dicht platzierte Links führen zu Fehlberührungen; Pop-ups oder Werbung überdecken Hauptinhalte; in der Mobilversion bleiben zu viele Animationen und automatisch abgespielte Videos erhalten.

Bei Seiten, die auf organischen Google-Traffic angewiesen sind, sollte außerdem geprüft werden, ob die Inhaltssignale der Mobil- und Desktopversion übereinstimmen. Wenn in der Mobilversion zur „Vereinfachung“ Produktmodelle, Anwendungsbeschreibungen, FAQ, Breadcrumbs und Links zu verwandten Produkten entfernt werden, verringern sich auch die Informationen, die Google beim Aufbau des Index anhand der mobilen Version auslesen kann. Der richtige Ansatz besteht nicht darin, Informationen einfach auszublenden, sondern die Lesbarkeit durch aufklappbare Bereiche, Ankernavigation, kurze Absätze und horizontal scrollbare Tabellen zu verbessern und gleichzeitig die crawlbaren Kerninhalte beizubehalten.

Die Prüfung in den Veröffentlichungsprozess integrieren, statt erst nach Indexierungsproblemen nachzubessern

Nach jedem Themenwechsel, jeder Anpassung der Navigation, Integration von Marketing-Skripten, Ergänzung mehrsprachiger Seiten oder Anpassung des CDN sollten die Startseite, zentrale Produktseiten, Inhaltsseiten und Formular-Landingpages stichprobenartig geprüft werden. Bestätigen Sie zunächst im Gerätemodus des Browsers das Layout, prüfen Sie dann mit PSI die mobile Leistung und Layoutverschiebungen und führen Sie abschließend für wichtige URLs über die Search Console einen Live-URL-Test durch. Wenn eine Seite bereits indexiert ist, aber Traffic oder Impressionen ungewöhnlich ausfallen, lässt sich der Umfang des Problems zusätzlich anhand des Status „Seitenindexierung“, der Crawl-Zeit und der Informationen zur kanonischen Seite in der Search Console beurteilen.

Nach der Einstellung des google mobile friendly test hat sich die Prüfung von einer einmaligen Bewertung „geeignet/nicht geeignet“ zu einer kontinuierlichen Validierung entwickelt. Für die operative Umsetzung ist es entscheidend, nicht nach einem völlig identischen Ersatz-Button zu suchen, sondern zwischen drei Problemarten zu unterscheiden: Kann Google die Seite nicht sehen, müssen zuerst Crawling und Ressourcen behandelt werden; lädt die Seite langsam, sind zuerst der sichtbare Bereich und Skripte zu optimieren; können Nutzer keine Aktion abschließen, muss der Ablauf auf echten Geräten Schritt für Schritt geprüft und korrigiert werden.