Mobile Shop-Optimierung: Checkliste für Smartphone-Kunden

Die Handyfassung Ihres Shops ist nicht die verkleinerte Desktop-Ansicht, sondern die Quelle für Googles Index: Der Crawler lädt die mobile Version einer Seite, und diese Fassung entscheidet über Index und Ranking (Google Search Central, Stand 10. Dezember 2025). Trägt die Handyfassung weniger Inhalt als die Desktopfassung, zieht Google daraus weniger Informationen und rechnet mit Traffic-Verlust (Google Search Central, Stand 10. Dezember 2025). Die folgenden Schritte prüfen die Stellen, an denen ein Shop auf einem kleinen Bildschirm bricht.

Was Sie vorab brauchen

Zugang zur Shopvorlage und, falls vorhanden, zu einer Testumgebung
zwei echte Telefone mit unterschiedlich großer Anzeige: ein kleines und ein großes Gerät
Kennzahlen Ihrer Webanalyse, nach Gerät getrennt: Aufrufe je Seite, Abbruch auf Produkt- und Checkout-Seite
Zugang zur Search Console für den Bericht Core Web Vitals und die URL-Prüfung
eine Liste der zehn Seiten mit den meisten Aufrufen in Ihrer Statistik
ein Testzugang beim Zahlungsdienstleister für Wallet-Zahlungen
eine Person, die Vorlage, Checkout und Zahlungsanbindung ändern darf

Schritt für Schritt: den mobilen Shop prüfen und verbessern

Schritt 1: Ladezeit am Handy messen

Google fasst die Ladeerfahrung in drei Kennzahlen zusammen: Largest Contentful Paint (LCP) für die Ladezeit, Interaction to Next Paint (INP) für die Reaktion auf Eingaben und Cumulative Layout Shift (CLS) für die Stabilität des Layouts (Google Search Central, Stand 10. Dezember 2025). Als gut gelten eine Ladezeit von höchstens 2,5 Sekunden (LCP), eine Reaktion von höchstens 200 Millisekunden (INP) und eine Layoutverschiebung von höchstens 0,1 (CLS); die Werte gelten an der 75. Perzentile der Seitenaufrufe, getrennt für Handy und Desktop (web.dev, Web Vitals, abgerufen am 14. Oktober 2026). INP hat am 12. März 2024 First Input Delay (FID) ersetzt (web.dev, Stand 31. Januar 2024).

Öffnen Sie in der Search Console den Bericht Core Web Vitals und filtern Sie auf Handy. LCP und CLS lassen sich im Labor nachstellen; INP verlangt echte Eingaben, dort dient Total Blocking Time als Ersatzwert (web.dev, Web Vitals). Wie Sie Bilder, Skripte und Serverantwort bearbeiten, steht in Ladezeit und Core Web Vitals im Shop.

Schritt 2: Textfluss prüfen

Ziehen Sie das Browserfenster auf 320 CSS-Pixel Breite; das entspricht einem 1280 Pixel breiten Fenster bei 400 Prozent Zoom (WCAG 2.2, 1.4.10, Stufe AA). Der Inhalt muss dabei ohne Scrollen in zwei Richtungen lesbar bleiben. Ausnahmen gelten nur für Teile, die eine zweidimensionale Darstellung brauchen, etwa Tabellen, Karten und Videos. Vergrößern Sie zusätzlich die Schrift auf 200 Prozent: Text muss skalierbar bleiben, ohne Inhalt und Funktion zu verlieren (WCAG 2.2, 1.4.4, Stufe AA).

Eine Seite mit Breitenangabe im Kopfbereich passt sich der Bildschirmbreite an; ohne diese Angabe wird sie auf dem Handy stark verkleinert und muss zum Lesen gezoomt werden (web.dev, Responsive web design basics). Prüfen Sie deshalb width=device-width in Ihrer Vorlage. Ein waagrechtes Scrollband in der Handyansicht zeigt, dass ein Element breiter ist als der Bildschirm, etwa eine breite Tabelle oder ein Video ohne Breitenbegrenzung.

Schritt 3: Zielgrößen vergrößern

Die Zielgröße eines Bedienelements ist die Fläche, die auf einen Fingertipp reagiert. WCAG 2.2 verlangt mindestens 24 mal 24 CSS-Pixel (2.5.8, Stufe AA), aber nur, wenn keine der fünf Ausnahmen greift: ausreichender Abstand, ein gleichwertiges Bedienelement auf derselben Seite, ein Ziel im Satz, eine vom Nutzeragenten bestimmte Größe oder eine wesentliche Darstellung. Die Ausnahme für den Abstand ist erfüllt, wenn ein Kreis von 24 CSS-Pixeln Durchmesser um jedes untermaßige Ziel weder ein anderes Ziel noch den Kreis eines anderen untermaßigen Ziels schneidet. Die strengere Stufe AAA verlangt 44 mal 44 CSS-Pixel (2.5.5), mit denselben Ausnahmen außer dem Abstand. Für wichtige Verweise und Bedienelemente empfiehlt die W3C-Dokumentation, die 44 mal 44 Pixel anzustreben.

Sehen Sie sich die Elemente an, die auf einem Handy eng liegen: Mengensteuerung im Warenkorb, Filterchips über der Trefferliste, Auswahl der Zahlungsart, Schließen-Schaltflächen in Overlays, Vorschaubilder der Galerie. Prüfen Sie jedes Element am Gerät mit dem Daumen. Bleibt unklar, ob Sie das richtige Element getroffen haben, fehlen Fläche oder Abstand: Prüfen Sie nach der Kreisregel aus dem ersten Absatz und vergrößern Sie die Ziele, statt die Ausnahme auszureizen (2.5.8, Ausnahme Spacing).

Schritt 4: Formulare kürzen und ausstatten

WCAG 2.2 verlangt, dass der Zweck jedes Eingabefelds, das Angaben über die Person erhebt und einen Zweck aus der Liste der Eingabezwecke erfüllt, programmatisch bestimmbar ist, sofern die Umsetzung die Kennzeichnung unterstützt; in HTML geschieht das über autocomplete (1.3.5, Stufe AA). Der HTML-Standard führt dafür feste Steuerwörter, unter anderem name, tel, email, street-address, postal-code, cc-number und one-time-code; für die Kartennummer zeigt er selbst das Muster type="text" inputmode="numeric" autocomplete="cc-number" (HTML Living Standard, Abschnitt Autofill, Stand 13. Oktober 2026).

Drei Anforderungen betreffen den Ablauf. Angaben, die Kundschaft im selben Vorgang schon gemacht hat, dürfen nicht erneut verlangt werden, sondern müssen vorbelegt oder zur Auswahl gestellt werden; ausgenommen sind Angaben, die erneut nötig sind (etwa aus Sicherheitsgründen) oder die nicht mehr gültig sind (3.3.7, Stufe A). Erkennt das Formular einen Fehler und ist eine Korrektur bekannt, muss es einen Vorschlag machen, sofern der Vorschlag die Sicherheit oder den Zweck des Inhalts nicht gefährdet (3.3.3, Stufe AA). Beim Anmelden darf kein kognitiver Test verlangt werden, es sei denn, der Schritt bietet eine der vier Möglichkeiten der Norm: eine Alternative ohne kognitiven Test, einen unterstützenden Mechanismus, Objekterkennung oder die Erkennung persönlicher Inhalte (3.3.8, Stufe AA); Passwortmanager und das Einfügen aus der Zwischenablage gelten nach der Norm als unterstützender Mechanismus. Passkeys sind im Web standardisiert (Web Authentication Level 3, W3C Recommendation vom 25. August 2026). Konto und Gastbestellung behandelt Kundenkonto und Login im Shop, die Feldliste im Bestellvorgang Checkout gestalten.

Schritt 5: Wallet-Schaltflächen einbinden und testen

Wallet-Schaltflächen zahlen mit einer im Gerät hinterlegten Zahlungsmethode, ohne dass die Kundschaft Kartendaten eintippt; ob Ihr Shop eine Wallet anbieten kann, hängt von Gerät, Browser und Zahlungsdienstleister ab. Welchen Weg die Anbindung nimmt, gibt die Integrationsanleitung des gewählten Anbieters vor; ein möglicher Weg im Web ist die Payment Request API des Browsers. Bei ihr vermittelt der Browser zwischen Shop, Kundschaft und Zahlungsmethode, und sie steht nur in einem sicheren Kontext bereit, also über eine verschlüsselte Verbindung (W3C, Payment Request API, Candidate Recommendation Draft vom 22. Juni 2026). Prüfen Sie in der Integrationsanleitung, welche Kennungen und Domainfreigaben der gewählte Weg verlangt.

Prüfen Sie die gewählte Anbindung im Testmodus mit einer Testzahlung: Die Schaltfläche steht vor dem manuellen Formular, die Zahlung läuft durch, der Auftrag erscheint im Shop und in der Buchhaltung, die Rückerstattung ist möglich. Welche Verträge, Kennungen und Freigaben Ihr Zahlungsdienstleister verlangt, klären Sie vor dem Einbau; das behandelt Wallets im Shop einbinden.

Schritt 6: Mobile und Desktop auf denselben Stand bringen

Handyfassung und Desktopfassung sollen denselben Inhalt, dieselben Überschriften, denselben Titel, dieselbe Meta-Beschreibung und dieselben strukturierten Daten tragen; für den Anfang nennt Google Breadcrumb-, Produkt- und Video-Auszeichnungen (Google Search Central, Stand 10. Dezember 2025). Inhalte, die erst nach einem Tippen, Wischen oder Ausfüllen geladen werden, erfassen die Suchsysteme nicht: Laden Sie Hauptinhalte nicht erst nach einer Interaktion nach, und sperren Sie Ressourcen nicht über robots.txt oder ein noindex in der Handyfassung.

Google findet Bilder im src-Attribut eines img-Elements und indexiert keine CSS-Hintergrundbilder (Image SEO Best Practices, Stand 2. März 2026). Unterstützte Formate sind dort BMP, GIF, JPEG, PNG, WebP, SVG und AVIF. Als verbreitete Zahl nennt die Google-Dokumentation drei bis fünf Fassungen je Bild für die verschiedenen Bildschirmbreiten (web.dev, Serve responsive images). Die Aufnahme selbst behandelt Produktfotos für den Onlineshop.

Die Checkliste: Zielgrößen, Formulare und Wallets

Die Tabelle sammelt die Zielwerte aus den Prüfschritten samt ihrer Grundlage. CSS-Pixel sind eine Recheneinheit des Browsers, keine physische Länge.

Prüfpunkt	Wert	Grundlage
Zielgröße von Bedienelementen	mindestens 24 mal 24 CSS-Pixel	WCAG 2.2, 2.5.8, Stufe AA; Ausnahmen für Abstand, gleichwertige Alternativen, Verweise im Satz, Nutzeragenten-Vorgaben und wesentliche Fälle
Zielgröße wichtiger Schaltflächen	mindestens 44 mal 44 CSS-Pixel	WCAG 2.2, 2.5.5, Stufe AAA; Ausnahmen für gleichwertige Alternativen, Verweise im Satz, Nutzeragenten-Vorgaben und wesentliche Fälle
Lesbarkeit ohne zweidimensionales Scrollen	vertikal scrollender Inhalt: Breite entsprechend 320 CSS-Pixeln; horizontal scrollender Inhalt: Höhe entsprechend 256 CSS-Pixeln	WCAG 2.2, 1.4.10, Stufe AA; Ausnahmen sind Teile, die eine zweidimensionale Darstellung brauchen
Textvergrößerung	bis 200 Prozent ohne Verlust	WCAG 2.2, 1.4.4, Stufe AA; Ausnahmen sind Untertitel und Bilder von Text
Ladezeit (LCP)	bis 2,5 Sekunden	Core Web Vitals, 75. Perzentile
Reaktion auf Eingaben (INP)	bis 200 Millisekunden	Core Web Vitals, 75. Perzentile
Layoutstabilität (CLS)	bis 0,1	Core Web Vitals, 75. Perzentile
Bildfassungen je Bild	drei bis fünf Größen	web.dev, Serve responsive images

Zielgrößen und Daumenbedienung

Mengensteuerung, Filterchips und Zahlungsarten-Auswahl sind mindestens 24 mal 24 CSS-Pixel groß; bei kleineren Zielen schneidet ein Kreis von 24 CSS-Pixeln Durchmesser um jedes Ziel weder ein anderes Ziel noch den Kreis eines anderen untermaßigen Ziels.
Die Schaltflächen für Warenkorb und Kasse erreichen 44 mal 44 CSS-Pixel; der Kaufabschluss liegt im unteren Drittel des Bildschirms.
Bei 320 CSS-Pixel Breite erscheint kein waagrechtes Scrollband.
Text bleibt bis 200 Prozent vergrößerbar, ohne dass Inhalt oder Funktionen verschwinden.
Feste Leisten, Chatfenster und Hinweisfelder verdecken keine Bedienelemente.

Formulare

Der Zweck jedes Felds mit Angaben über die Person und einem Zweck aus der Liste der Eingabezwecke ist programmatisch bestimmbar; in HTML trägt jedes solche Feld das passende autocomplete-Steuerwort aus dem HTML-Standard.
Liefer- und Rechnungsanschrift werden nicht doppelt abgefragt, sondern übernommen oder zur Auswahl gestellt; nur Angaben, die erneut nötig sind (etwa aus Sicherheitsgründen) oder nicht mehr gültig sind, werden erneut verlangt.
Erkennt das Formular einen Fehler, nennt es Feld, Ursache und Korrekturvorschlag, sofern der Vorschlag die Sicherheit nicht gefährdet.
Die Anmeldung verlangt keinen kognitiven Test, außer der Schritt bietet eine Alternative, einen unterstützenden Mechanismus, Objekterkennung oder persönliche Inhalte; Passwortmanager, Einfügen aus der Zwischenablage und Passkeys funktionieren.
Das Adressformular folgt der Konvention des Ziellands.
Die Gastbestellung ist vom ersten Schritt an sichtbar, nicht erst nach der Kontoanlage.
Die Kartennummer folgt dem Muster des HTML-Standards (type="text" inputmode="numeric" autocomplete="cc-number"); für Postleitzahlen ist eine numerische Tastatur (inputmode="numeric") eine eigene, nur für Zielländer mit rein numerischer Postleitzahl passende Empfehlung, weil der Standard das Postleitzahlfeld als freien Text führt.

Wallet-Schaltflächen

Der Shop läuft über eine verschlüsselte Verbindung; ein Weg über die Payment Request API steht ohne sie nicht bereit.
Welche Kennungen und Domainfreigaben der gewählte Anbindungsweg verlangt, ist aus der Integrationsanleitung übernommen.
Die Wallet-Schaltfläche steht über dem manuellen Zahlungsformular und wird von der Anbindung des Anbieters erzeugt.
Eine Testzahlung je angebotener Wallet ist im Testmodus durchgelaufen, bis der Auftrag im Shop erscheint.
Für jedes Zielland ist mit dem Zahlungsdienstleister geklärt, welche Wallet er dort unterstützt.
Bricht eine Wallet ab, bleibt der reguläre Zahlungsweg sichtbar.

So prüfen Sie das Ergebnis

Zwei echte Telefone mit unterschiedlich großer Anzeige, ein kleines und ein großes Gerät, zeigen dieselben Inhalte und Funktionen.
Bei 320 CSS-Pixel Breite und 200 Prozent Schriftvergrößerung bleibt die Seite ohne waagrechtes Scrollen lesbar.
Im Labor mit gedrosselter Verbindung liegen LCP und CLS nahe an den Werten der Search Console.
Eine Testbestellung mit Wallet und eine mit Rechnung laufen durch, samt Bestätigungs-E-Mail und Rückerstattung.
Die URL-Prüfung in der Search Console zeigt für eine Produktseite die Handyfassung mit denselben Inhalten und strukturierten Daten.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Die Seite lässt sich am Handy nur gezoomt lesen	Im Vorlagenkopf fehlt die Breitenangabe	`width=device-width` ergänzen und die Vorlage ausrollen
Ein waagrechtes Scrollband erscheint	Ein Element ist breiter als der Bildschirm	Das Element begrenzen oder in einen eigenen Scrollbereich setzen
Tipps landen auf dem falschen Element	Ein Ziel ist kleiner als 24 mal 24 CSS-Pixel, oder die Kreise von 24 CSS-Pixeln Durchmesser um zwei untermaßige Ziele schneiden einander oder ein anderes Ziel	Die Fläche auf mindestens 24 mal 24 CSS-Pixel vergrößern oder den Abstand so erhöhen, dass die Kreise einander und andere Ziele nicht mehr schneiden, ohne den Text zu ändern
Passwortmanager füllen das Anmeldeformular nicht	In HTML fehlen die `autocomplete`-Steuerwörter, oder ein Skript blockiert das Ausfüllen	Steuerwörter setzen und die Blockade entfernen
Die Wallet-Schaltfläche erscheint nicht	Die Verbindung ist nicht verschlüsselt, oder die Domain ist beim Anbieter nicht freigegeben	TLS prüfen und die Freigabe nachholen
Der Laborwert ist gut, der Feldwert schlecht	Gemessen wurde auf einem schnellen Rechner, nicht auf Geräten Ihrer Kundschaft	Feldwerte nach Gerät trennen und die schwerste Vorlage zuerst ändern

Was in Deutschland, Österreich und der Schweiz zu prüfen ist

Die technischen Werte gelten in allen drei Ländern gleich, die Formulare nicht: Der HTML-Standard rät, Adressformulare an die Konventionen des Landes anzupassen, weil die Zahl der Adressebenen unterschiedlich ist (HTML Living Standard, Abschnitt Autofill, Stand 13. Oktober 2026). Prüfen Sie Reihenfolge und Pflichtfelder je Zielland, sobald Sie dorthin verkaufen.

Beim Bezahlen unterscheiden sich die angebotenen Wallets je Land und Zahlungsdienstleister; prüfen Sie für jedes Zielland, welche Wallet Ihr Dienstleister dort anbietet und welche Nachweise er verlangt. WCAG 2.2 ist eine Empfehlung des W3C und keine staatliche Vorschrift; verbindlich wird sie dort, wo Recht oder Vertrag auf sie verweisen. Ob für Ihr Angebot eine Pflicht zur Barrierefreiheit gilt, hängt vom Land und von der Art des Angebots ab: Die Prüfung beschreiben Barrierefreiheit im Onlineshop nach BFSG für Deutschland, Barrierefreiheit in Österreich und Barrierefreiheit in der Schweiz.

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung für Vorlage und Checkout, wenn Ihr Shopsystem Felder, Steuerwörter und Zielgrößen nicht über Einstellungen ausgibt. Für Wallets ist der Zahlungsdienstleister die richtige Stelle. Bleibt unklar, ob für Ihr Angebot besondere Pflichten gelten, klären Sie das mit Ihrer Rechtsberatung, bevor Sie den Umbau beauftragen.