Google hat 2018 auf Mobile-First-Indexierung umgestellt, und bis 2026 ist es seit über fünf Jahren der einzige Modus. Trotzdem werden in nahezu jeder Agentur SEO-Audits noch mit Lighthouse-Standardwerten gefahren, die ein schnelles Notebook auf einer Glasfaserleitung bevorzugen. Der Bericht sieht sauber aus, die Empfehlungen treffen nicht den Kern, und der Kunde fragt sich, warum die Rankings trotzdem absinken.
Diese Anleitung behebt das Ganze praxisnah. Sie erklärt, warum Mobile-Audits 2026 dominieren, was technisch beim Auditieren einer Mobile-Erfahrung anders ist, die Core-Web-Vitals-Realität auf langsamen Geräten, welche mobilspezifischen Probleme erkannt werden müssen, eine 12-Punkte-Checkliste, die wichtigen Tools, wie Sie Fixes priorisieren und wie Sie die Befunde an nicht-technische Kunden kommunizieren.
Möchten Sie SEO-Probleme auf jeder Website finden?
Testen Sie WebSEO Auditor kostenlos — führen Sie Ihr erstes Audit in Sekunden durch.
Kostenlos testenWarum Mobile-Audits 2026 dominieren
Google indexiert seit 2018 Mobile-First — bis 2026 ist das seit mehr als fünf Jahren der einzige Modus. Der Crawler, der entscheidet, welche Seitenversion in den Index gelangt, ist ein Mobile-Crawler. Die gespeicherte gerenderte Ausgabe ist die Mobile-Rendering. Die Core Web Vitals, die gewichtet werden, sind die Mobile-Werte. Es gibt keinen Rückfall auf Desktop.
Das Suchverhalten ist gefolgt. In den meisten Verbraucherbranchen liegt der Mobile-Anteil der organischen Suche heute bei 65 % oder höher, und in einigen Kategorien — lokale Dienstleistungen, Nachrichten, Unterhaltung, E-Commerce unterhalb eines bestimmten Preises — übersteigt Mobile 80 %. Desktop bleibt wichtig für B2B-Recherche und Käufe mit langer Überlegungszeit, der Entdeckungsmoment findet aber fast immer auf einem Smartphone statt.
Die geschäftliche Auswirkung ist eindeutig. Eine Seite, die auf einem schnellen Notebook in 2,1 Sekunden lädt, aber auf einem Mittelklasse-Android-Smartphone 6,8 Sekunden braucht, ist in der Praxis eine langsame Seite. Die Mobile-Erfahrung entscheidet, ob ein Besucher bleibt, ob er konvertiert und ob Google die Seite zu den relevanten Suchanfragen rankt. Den Desktop-Audit durchzuziehen und damit fertig zu sein, ist das SEO-Äquivalent dazu, die Fassade eines Gebäudes zu prüfen und den Eingang zu ignorieren.
Was an einem Mobile-Audit tatsächlich anders ist
Ein Mobile-Audit ist nicht einfach ein Desktop-Audit mit schmalerem Viewport. Die Unterschiede ziehen sich durch den gesamten Stack.
Gedrosselte CPU
Das Mobile-Preset von Lighthouse drosselt die CPU um etwa Faktor 4 und simuliert ein Gerät der Klasse Moto G Power — eine faire Darstellung des Median-Android-Geräts 2026. JavaScript, das auf einem Entwickler-Notebook in 200 ms geparst wird, kann auf diesem Gerät 1,5 Sekunden benötigen. Hydration, die den Haupt-Thread auf dem Desktop für 80 ms blockiert, blockiert ihn auf dem Smartphone für 400 ms. Jedes Skript-Bundle, jedes Polyfill und jeder Analytics-Tag hat einen Multiplikator.
Gedrosseltes 4G-Netzwerk
Das Standard-Mobile-Netzwerkprofil geht von einer regulären 4G-Verbindung aus — etwa 1,6 Mbit/s im Downlink mit 150 ms Round-Trip-Latenz. Reale Bedingungen variieren, aber das Profil ist bewusst pessimistisch gewählt, um Probleme aufzudecken, die auf einer Gigabit-Büroleitung verschwinden. Schwere Hero-Bilder, große Webfonts und Wasserfall-Request-Muster werden hier laut sichtbar.
Viewport-Unterschiede
Designs für einen 375 px breiten Viewport — die langjährige iPhone-Referenz — erzwingen Entscheidungen, die Desktop nie verlangt. Spalten kollabieren. Die Navigation versteckt sich hinter einem Burger. Hero-Text, der bei 1440 px wunderschön gelesen wurde, bricht bei 375 px unschön um. Ein Audit sollte testen, wie sich das Layout bei 360, 375 und 414 px verhält, weil echte Besucher auf allen drei Breiten ankommen.
Touch versus Hover
Auf dem Mobilgerät gibt es keinen Hover-Zustand. Ein Dropdown, das per Hover öffnet, ist kaputt. Ein Tooltip, der per Hover erscheint, ist unsichtbar. Jede Interaktion, die für einen Mauszeiger entworfen wurde, ist auf einem Touchscreen bestenfalls umständlich und schlimmstenfalls völlig unzugänglich.
Anforderungen an Touch-Ziele
Die Empfehlung von Google liegt bei mindestens 44x44 CSS-Pixeln pro Touch-Ziel, mit mindestens 8 px Abstand zwischen benachbarten Zielen. Schaltflächen darunter scheitern an der Barrierefreiheit, scheitern an Lighthouse und erzeugen echte Frustration auf kleinen Bildschirmen. Überraschend viele Cookie-Banner, Footer-Links und Pagination-Steuerelemente verletzen das immer noch.
Lesbarkeit bei kleinen Schriftgrößen
Fließtext unter 16 px ist auf einem Smartphone schwer zu lesen. Viele Themes liefern immer noch 14 oder 15 px als Standard, weil das auf einem Retina-Notebook elegant aussieht. Auf einem 375-px-Viewport zwingt das den Besucher zu zoomen — und Zoom ist ein Signal, dass etwas nicht stimmt.
Mobile Core Web Vitals: Warum die Werte typischerweise 25-35 Punkte unter Desktop liegen
Wer dieselbe URL je zweimal durch PageSpeed Insights gejagt hat — einmal im Desktop-Tab, einmal im Mobile-Tab —, hat die Lücke gesehen. 92 auf Desktop sinkt auf 58 auf Mobile. Diese Lücke ist kein Bug. Sie ist das Drosselungsprofil, das seine Arbeit macht.
Jedes der drei Core Web Vitals hat einen eigenen mobilen Versagensmodus:
LCP auf langsamen CPUs
Largest Contentful Paint wird auf Mobile von zwei Dingen dominiert: der Zeit, die das Hero-Bild zum Herunterladen und Decodieren braucht, und der Zeit, in der der Haupt-Thread durch JavaScript blockiert ist, bevor das Bild gerendert werden kann. Auf einer gedrosselten CPU kann ein 600 KB schweres Hero-Bild, das auf Desktop in 80 ms decodiert wurde, 350 ms benötigen. In Kombination mit Hydration landet LCP häufig über 4 Sekunden — der Schwelle für "schlecht".
INP bei Touch-Interaktionen
Interaction to Next Paint, das 2024 First Input Delay ersetzt hat, misst die Latenz jeder Interaktion über den gesamten Seitenlebenszyklus. Auf Mobile lösen Tipps Handler aus, die häufig in teure State-Updates kaskadieren. Ein Tipp, der unter 100 ms reagieren sollte, kann 400 ms dauern, wenn der Haupt-Thread mit dem Rendern eines Karussells oder dem Laden eines Drittanbieterskripts beschäftigt ist.
CLS durch spät ladende Anzeigen und Embeds
Cumulative Layout Shift ist auf Mobile häufig schlimmer, weil der Viewport kleiner ist — ein einzelnes Banner, das das Layout um 200 px verschiebt, ist ein viel größerer Anteil der sichtbaren Seite. Anzeigen, die nach dem ersten Paint laden, eingebettete Social-Cards, die spät eintreffen, und Webfonts, die per FOIT/FOUT swappen, treiben den Wert nach oben.
Ein vernünftiger Richtwert für 2026: Liegt der Desktop-Core-Web-Vitals-Score bei 90+, ist auf Mobile mit 55 bis 75 zu rechnen, sofern nicht aktiv optimiert wurde. Alles über 80 auf Mobile ist wirklich stark.
Mobilspezifische Probleme, die erkannt werden müssen
Einige Probleme treten nur auf Mobile auf. Ein reifer Audit jagt sie bewusst, statt zufällig auf sie zu stoßen.
Aufdringliche Interstitials
Googles Mobile-UX-Richtlinien bestrafen Seiten, die den Hauptinhalt unmittelbar nach der Navigation mit einem Popup verdecken. Dazu zählen Vollbild-Cookie-Banner, Newsletter-Anmeldeformulare und App-Installations-Prompts, die sich nicht leicht schließen lassen. Cookie-Compliance ist Pflicht, doch die Umsetzung ist entscheidend — ein kleines Banner unten ist in Ordnung; ein Vollbild-Overlay, das vor dem Sichten von Inhalt durchgeklickt werden muss, ist es nicht.
Render-blockierendes JavaScript
Auf einer gedrosselten Mobile-CPU kann ein einziges 200 KB schweres synchrones Skript im Head den First Contentful Paint um mehr als eine Sekunde verzögern. Render-blockierende Skripte, die sich auf Desktop "schnell anfühlen", werden auf Mobile sehr teuer.
Nicht optimierte Hero-Bilder
Das Hero-Bild ist auf Mobile fast immer das LCP-Element. Dasselbe 1920x1080-JPEG an einen 375-px-Viewport auszuliefern, ist Verschwendung — der Besucher lädt viermal mehr Pixel herunter, als er jemals sehen kann. Moderne Formate (AVIF, WebP), responsives srcset und explizite width/height-Attribute sind nicht verhandelbar.
Hover-abhängige UI
Mega-Menüs, die nur per Hover öffnen, Tooltips, die nur per Hover erscheinen, Bildergalerien, die Bildunterschriften per Hover offenbaren — all das geht auf Touch kaputt. Der Audit sollte jede Interaktion kennzeichnen, die einen Hover-Zustand erfordert, und eine Klick-/Tipp-Alternative empfehlen.
Akkuverbrauch durch Autoplay-Video
Ein automatisch abspielendes Hintergrundvideo auf einem Mobilgerät ist eine dreifache Strafe: Es verbraucht Daten, entleert den Akku und treibt LCP fast immer nach oben, weil der Browser das Video-Decoding priorisiert. Verlangt das Design unbedingt Bewegung, verwenden Sie einen kurzen WebM-Loop mit explizitem muted und playsinline, idealerweise nur in ausreichend schnellen Netzwerken.
Kaputtes Viewport-Meta
Ein fehlendes oder falsch konfiguriertes <meta name="viewport">-Tag ist eines der häufigsten — und schädlichsten — Mobile-Probleme. Ohne width=device-width, initial-scale=1 fällt der Browser auf einen virtuellen Viewport von 980 px zurück und schrumpft die gesamte Seite. Jeder Mobile-Audit muss das Viewport-Tag prüfen.
Desktop- versus Mobile-Audit-Überlegungen
| Faktor | Desktop-Audit | Mobile-Audit |
|---|---|---|
| CPU-Drosselung | Keine (1x) | 4x Verlangsamung (Moto G Power-Klasse) |
| Netzwerk | Kabel / schnelles Breitband | Gedrosseltes 4G (~1,6 Mbit/s, 150 ms RTT) |
| Viewport | 1350-1920 px breit | 360-414 px breit |
| Eingabemodell | Maus + Tastatur, Hover verfügbar | Nur Touch, kein Hover |
| LCP-Realität | Häufig unter 2 s | Häufig 3-5 s ohne Optimierung |
| Touch-Ziele | Pixelgenauigkeit möglich | Mindestens 44x44, 8 px Abstand |
| Schriftgrößen-Untergrenze | 14 px meist okay | 16 px Minimum für Fließtext |
| Toleranz für Interstitials | Höher | Aggressiv bestraft |
Eine 12-Punkte-Checkliste für den Mobile-Audit
Wenden Sie diese Liste auf jede Seite an. Sie erfasst die relevanten Probleme und überspringt das Rauschen.
- Viewport-Meta-Tag. Prüfen Sie, dass
<meta name="viewport" content="width=device-width, initial-scale=1">im Head vorhanden ist. Keinuser-scalable=no. - Mobile-Lighthouse-Wert. Führen Sie Lighthouse mit dem Mobile-Preset aus. Notieren Sie Performance, Accessibility, Best Practices und SEO. Vergleichen Sie mit Desktop. Eine Lücke größer als 35 Punkte weist auf reale Mobile-Probleme hin.
- Core Web Vitals aus CrUX. Ziehen Sie Felddaten echter Nutzer aus PageSpeed Insights. Laborwerte können täuschen, Felddaten nicht.
- Prüfung des LCP-Elements. Identifizieren Sie das LCP-Element auf Mobile. Ist es ein Hero-Bild, prüfen Sie Preload, Responsive Sizing und modernes Format.
- Audit der Touch-Ziele. Gehen Sie die Hauptnutzerreise auf einem echten Gerät durch. Jedes interaktive Element muss mindestens 44x44 mit ausreichendem Abstand sein.
- Hover-Abhängigkeitsprüfung. Besuchen Sie die Startseite und Hauptnavigation auf einem Touch-Gerät. Markieren Sie jede UI, die nicht korrekt auf Tipps reagiert.
- Schriftlesbarkeit. Bestätigen Sie, dass Fließtext mindestens 16 px ist. Prüfen Sie, dass Überschriften bei 375 px angemessen skalieren.
- Interstitial-Prüfung. Laden Sie die Seite auf Mobile. Verdeckt ein Element mehr als 30 % des Viewports, bevor Inhalt lesbar ist, markieren Sie es als Risiko.
- Bildoptimierung. Nehmen Sie fünf Bildproben aus der Seite. Bestätigen Sie moderne Formate, responsive Größen und explizite Abmessungen.
- JavaScript-Bundle-Größe. Erstanbieter-JS über 300 KB auf Mobile ist eine rote Flagge. Über 500 KB verlangt eine Überarbeitung.
- Audit von Drittanbieterskripten. Zählen Sie Drittanbieterskripte. Jedes ist ein potenzieller Blocker. Tag-Manager, Chat-Widgets und synchrone Analytics-Tags sind typische Verursacher.
- Search Console Mobile Usability. Prüfen Sie die Search Console auf gemeldete Mobile-Usability-Probleme. Das sind Probleme, die Google bei realen Besuchen schon gesehen hat.
Ein sauberer Desktop-Lighthouse-Wert kombiniert mit einem schlechten Mobile-Wert ist kein kleines Problem. Es ist die Differenz zwischen dem Auftritt des Audits und dem, was Google auf der Seite sieht.
Wichtige Tools
- Lighthouse Mobile-Preset. Standard in Chrome DevTools. Als Ausgangspunkt jedes Audits. Das Mobile-Preset wendet CPU-Drosselung, Netzwerkdrosselung und mobilen Viewport an.
- Chrome DevTools Geräteemulation. Wechseln Sie in der Device Toolbar zu iPhone 14, Pixel 7 und Galaxy S22, um Layout-Reaktionen über Referenzgeräte zu sehen. Mit dem Performance-Tab für CPU-Profiling kombinieren.
- Search Console Mobile Usability-Report. Zeigt Googles tatsächliche Befunde aus dem Mobile-Crawler. Achten Sie auf Warnungen zu Viewport, Schriftgröße und Touch-Zielen.
- PageSpeed Insights. Kombiniert Labordaten (Lighthouse) mit Felddaten (CrUX). Der Feld-Tab ist die ehrlichste Einschätzung dessen, was echte Nutzer erleben.
- BrowserStack oder echtes Gerät. Bei kritischen Audits reicht Emulation nicht. Testen Sie mindestens auf einem Mittelklasse-Android. CPU, Touch-Latenz, Netzwerkverhalten — alles ehrlicher als Simulation.
- WebSEO Auditor. Führt den vollständigen Mobile- und Desktop-Lighthouse-Stack aus, zeigt die Lücke und ergänzt GEO-Wert, Barrierefreiheit und Prüfungen für strukturierte Daten.
Was zuerst beheben: die Prioritätsmatrix
Nicht jeder Befund verdient gleich viel Aufmerksamkeit. Der schnellste Weg zu einer messbaren Mobile-Verbesserung ist Triage nach Wirkung und Aufwand.
Schnelle Gewinne (hohe Wirkung, geringer Aufwand)
- Viewport-Meta-Tag korrigieren
- Hero-Bild in AVIF/WebP mit responsivem srcset konvertieren
- Nicht kritische Drittanbieterskripte verzögern
- Fließtext auf mindestens 16 px anheben
- Zu kleine Touch-Ziele in Hauptnavigation und CTA-Buttons vergrößern
Große Projekte (hohe Wirkung, hoher Aufwand)
- Erstanbieter-JavaScript-Bundle reduzieren
- Hover-abhängige Menüs touchfreundlich neu aufbauen
- Layout so umstrukturieren, dass CLS durch spätes Nachladen verschwindet
- Render-blockierendes CSS durch kritisches Inline-CSS ersetzen
Aufräumen (geringe Wirkung, geringer Aufwand)
- Explizite width/height bei verbleibenden Bildern ergänzen
- Bitmap-Icons durch SVG ersetzen
- Ungenutztes CSS entfernen
Depriorisieren (geringe Wirkung, hoher Aufwand)
- SSR-Migrationen rein wegen marginaler Performance-Gewinne
- Framework-Migrationen ohne klare Performance-Obergrenze
Bei einer typischen Seite verschiebt das Beheben der schnellen Gewinne den Mobile-Performance-Wert um 15-25 Punkte. Das genügt, um den Audit aus dem "braucht sofort Arbeit"-Bereich in den "graduell optimieren"-Bereich zu heben.
Befunde an Kunden berichten
Die meisten Kunden sind nicht technisch. Ein Befund, geschrieben für Entwickler — "LCP liegt bei 4,2 s wegen render-blockierendem JS und einem nicht optimierten Hero-Bild" —, bedeutet einem Kleinunternehmer nichts. Ein Mobile-Audit-Bericht muss übersetzen.
- Mit dem Geschäftsergebnis beginnen. "Ihre Seite braucht auf einem typischen Android-Smartphone über 4 Sekunden, bis sie nutzbar ist. Das ist doppelt so lange wie Ihre Wettbewerber und kostet Sie Besucher, bevor diese überhaupt Ihr Angebot sehen."
- Zeigen, nicht erzählen. Ein Screenshot-Paar der Seite, die auf einem schnellen Desktop und auf einem gedrosselten Mobilgerät lädt, ist überzeugender als jeder Punkt. Eine 30-sekündige Bildschirmaufnahme ist noch besser.
- Befunde nach Wirkung gruppieren, nicht nach Kategorie. "Die drei Dinge, die am meisten bewegen" ist nützlicher als "alle SEO-Befunde" gefolgt von "alle Performance-Befunde".
- Den Gewinn quantifizieren. "Allein das Hero-Bild zu korrigieren bringt Ihren Mobile-Performance-Wert von 54 auf rund 72." Konkrete Zahlen wirken erreichbar.
- Mit einer einzelnen Empfehlung enden. Entscheidungslähmung tötet Nachverfolgung. Empfehlen Sie die Maßnahme mit dem höchsten ROI und bieten Sie an, sie umzusetzen.
Zusammenfassung
Die Audits, die 2026 etwas bewegen, sind die, die Mobile ernst nehmen. Lighthouse-Standardwerte, echtes Gerätetesten, die obige 12-Punkte-Checkliste und eine Prioritätsmatrix, die den Aufwand respektiert — das sind die Zutaten eines Audits, der die echten Probleme findet und eine Fix-Liste produziert, die der Kunde tatsächlich umsetzt.
Wenn Sie einen kompletten Mobile-First-Audit für jede Seite in unter einer Minute durchführen möchten — inklusive Performance, SEO, Accessibility, Best Practices, GEO und strukturierter Daten —, testen Sie WebSEO Auditor kostenlos unter webseoauditor.com/try. Mobile- und Desktop-Werte sind beide enthalten, nebeneinander, sodass die Lücke ab dem ersten Bericht sichtbar ist.