Mobile Conversion-Probleme in WooCommerce finden

Zwei Tatsachen, die jeder Solo-WooCommerce-Betreiber in seinem Analytics-Dashboard sehen kann:

• Mobile ist 70–78 % Ihres Traffics.
• Mobile konvertiert mit rund 60 % der Desktop-Rate.

Die Rechnung: Wenn Sie 10.000 Mobile-Besuche/Monat mit 1,8 % Conversion und 3.000 Desktop-Besuche/Monat mit 3,0 % Conversion haben, generiert Mobile 180 Bestellungen und Desktop 90. Mobile ist bereits Ihr größerer Umsatzmotor – aber ein Anstieg um einen Prozentpunkt auf Mobile ist doppelt so viel wert wie derselbe Anstieg auf Desktop.

Diese Mathematik ist der Grund, warum Mobile-CRO die wirksamste Einzelinvestition für einen Solo-Woo-Shop ist. Das Problem: Fast jeder „WooCommerce Mobile Optimization”-Beitrag in der SERP ist eine Taktikliste mit 25 Punkten. Das hilft nicht, wenn Sie nicht wissen, welches Mobile-Problem Ihres ist.

Dieser Beitrag ist die Diagnose, nicht die Liste. Vier Mobile-Probleme, nach Erkennungsmethode geordnet, ein Zwei-Tab-Workflow in 5 Minuten und die fünf evidenzbasierten Mobile-Engpässe in Prioritätsreihenfolge.

Was dieser Beitrag beantwortet

• Das Verhältnis Mobile-CR zu Desktop-CR als diagnostischer Ausgangspunkt.
• Die 4 Mobile-Probleme, jedes mit eigener Erkennungsregel (kein GA4 erforderlich).
• Das 5-Minuten-Zwei-Tab-Mobile-Audit nur mit Statnives Geräte- und Seiten-Bericht.
• Die 5 evidenzbasierten Mobile-Conversion-Engpässe in Prioritätsreihenfolge.
• Die 4 Mobile-Antipatterns, die die SERP noch empfiehlt – und die Forschung, die sie entkräftet.

Beginnen Sie mit dem Verhältnis: Mobile CR ÷ Desktop CR

Öffnen Sie Ihre WooCommerce-Berichte → Bestellungen. Filtern Sie nach Datumsbereich (die letzten 30 Tage sind für einen Solo-Shop sinnvoll). Sortieren Sie Bestellungen nach ihrem Quellgerät – die meisten WooCommerce-Themes speichern das in Bestellmetadaten, und falls Ihr Shop das nicht tut, übernimmt das die Order-Attribution-Funktion ab WC 8.5+.

Berechnen Sie:

mobile_orders ÷ mobile_visitors = mobile_CR
desktop_orders ÷ desktop_visitors = desktop_CR
mobile_CR ÷ desktop_CR = Ihr Verhältnis

Woher kommen Ihre Besucher? Öffnen Sie Statnive → Geräte-Bericht. Die Aufschlüsselung nach Gerätetyp liefert Ihnen mobile_visitors und desktop_visitors.

Basiszahlen (gemäß Dynamic-Yield-Benchmarkdaten, veröffentlicht über Oberlo, Oktober 2024):

• Desktop-E-Commerce-Conversion: 3,85 %
• Tablet: 3,49 %
• Mobile: 2,85 %
• Mobile ÷ Desktop ≈ 0,74

Einige Quellen berichten von Verhältnissen bis hinunter zu 0,50–0,55 für Bekleidung, Elektronik und Schmuck. Die richtige Referenz ist das Verhältnis Ihres eigenen Shops gegenüber seiner eigenen Historie, nicht ein universeller Benchmark. Verfolgen Sie das Verhältnis monatlich – das ist Ihr wichtigster einzelner Mobile-Health-KPI.

Die 4 Mobile-Probleme, jedes mit eigener Erkennungsmethode

Das ist der diagnostische Rahmen. Die meisten „Mobile CRO”-Beiträge springen direkt zu Fixes; der eigentliche Gewinn liegt darin, zu wissen, welches Problem Sie haben.

Problem 1 – Traffic, der den Checkout nie erreicht

Erkennung: Im Geräte-Bericht von Statnive liegen die Mobile-Sessions im Bereich von ± 15 Prozentpunkten Ihrer Desktop-Sessions, aber in WooCommerce Analytics → Bestellungen liegen die Mobile-Bestellungen unter 30 % des aus dem Traffic-Anteil erwarteten Volumens.

Was passiert: Mobile-Besucher landen, sehen vielleicht eine Seite und springen ab – sie erreichen /cart oder /checkout nie. Der Funnel verliert oben.

Wo Sie als Nächstes hinschauen: Statnive → Seiten → Einstiegsseiten, sortiert nach Einstiegsanzahl. Identifizieren Sie mobile-lastige Einstiegsseiten (Querverweis auf den Geräte-Bericht). Wenn diese Einstiege eine hohe Ausstiegsanzahl haben, liegt ein Top-of-Funnel-Mobile-Problem vor – meist eine langsame Seite, ein nicht für Mobile optimierter Hero oder ein Above-Fold-CTA, der auf einem 375-px-Viewport nicht sichtbar ist.

Problem 2 – Traffic, der Cart/Checkout erreicht, aber scheitert

Erkennung: Mobile-Besucher erreichen /checkout (sichtbar in Ihrem Seiten-Bericht), aber Mobile-Bestellungen bleiben proportional niedrig. Der Funnel verliert unten.

Was passiert: Der Besucher legte ein Produkt in den Warenkorb, startete eventuell sogar den Checkout, und brach mitten im Formular ab. Das ist das klassische Baymard-Muster: zu spät offenbarte Versandkosten (39 % der US-Abbrecher), erzwungene Kontoerstellung (19 %), zu langes Checkout-Formular (18 %), Mismatch beim Zahlungsanbieter.

Wo Sie als Nächstes hinschauen: Öffnen Sie /checkout Ihres Shops aus einem mobilen Browser mit 375-px-Viewport. Gehen Sie durch. Zählen Sie die Felder. Stoppen Sie das Formular. Vergleichen Sie mit Baymards Mobile-Checkout-Checkliste.

Problem 3 – Mobile-Absprung auf der Produktseite

Erkennung: Im Seiten-Bericht von Statnive haben Ihre Top-PDP-Einstiegsseiten hohe Ausstiegsanzahlen. Im Geräte-Bericht dominiert Mobile. Es gibt heute in der Oberfläche keinen einfachen „Geräte-Filter auf Seiten” (Umgehung unten), also ist das eine Zwei-Tab-Inferenz.

Was passiert: Mobile-Besucher landen auf Ihrer Produktseite, finden den Kaufen-Button ohne Scrollen nicht oder werden von einem ruckelnden Bildgalerie-Verhalten getroffen oder warten zu lange auf den Seitenaufbau.

Wo Sie als Nächstes hinschauen: Öffnen Sie Ihre Top-PDP auf einem echten Mobilgerät (nicht ein auf 375 px verengter Desktop-Browser – echte Telefone haben Tastatur, Touch und Safari-ITP-Eigenheiten, die die Desktop-Emulation versteckt). Messen Sie den LCP mit Google PageSpeed Insights. Prüfen Sie, ob der „In den Warenkorb”-Button above the fold ohne Scrollen sichtbar ist. Stellen Sie sicher, dass die Bildgalerie ruckelfrei wischbar ist.

Problem 4 – Von Anfang an falsche Zielgruppe

Erkennung: Mobile-Traffic-Anteil ist hoch, aber die Traffic-Quelle ist ein bestimmter Channel (oft Paid Social auf Meta), und die Absprungrate liegt durchgängig > 75 % über alle mobilen Einstiegsseiten.

Was passiert: Die Anzeigen sprechen Menschen an, die nicht wollen, was Sie verkaufen, oder das Anzeigenmotiv passt nicht zur Landingpage. Die Mobile-UX Ihres Shops ist in Ordnung; die vorgelagerte Aussteuerung ist kaputt.

Wo Sie als Nächstes hinschauen: Statnive → Referrer → Filter auf UTM-Quelle/Medium der verdächtigen Kampagne. Vergleichen Sie Absprünge + Dauer gegen den Seitendurchschnitt. Wenn die Kampagne die Channel-Health-Regel verletzt (Absprünge über Durchschnitt + Dauer unter Durchschnitt), liegt das Problem bei der Kampagne, nicht bei der Mobile-UX. Siehe das Traffic-Quellen-Playbook für die vollständige Diagnose.

Das 5-Minuten-Zwei-Tab-Mobile-Audit

Das ist der Workflow. Kein GA4. Kein Lighthouse-Dashboard. Kein Heatmap-Tool. Zwei Browser-Tabs und Ihr WooCommerce-Admin.

Tab 1 – Statnive-Geräte-Bericht:

• Wie hoch ist Ihr Mobile-Anteil an den Gesamt-Sessions? (Sollte 60–80 % für die meisten konsumentenorientierten Woo-Shops sein.)
• Wie hoch ist Ihre Mobile-Absprungrate vs. Ihre Desktop-Absprungrate? (Berechnen Sie das Delta in Prozentpunkten.)
• Welche Browser dominieren auf Mobile (mobiles Safari vs. Android Chrome)?

Tab 2 – Statnive-Seiten-Bericht:

• Absteigend nach Einstiegsanzahl sortieren. Das sind auch Ihre mobilen Landingpages (Mobile ist der Großteil des Traffics).
• Absteigend nach Ausstiegsanzahl sortieren. Notieren Sie jede /product/-, /cart/- oder /checkout-Seite in den Top 5.

Tab 3 – WooCommerce Analytics → Bestellungen:

• Auf die letzten 30 Tage filtern. Mobile-zugeordnete Bestellungsanzahl notieren.
• Berechnen: mobile_orders ÷ (mobile_sessions aus Tab 1) = Mobile-CR.
• Dasselbe für Desktop.
• Verhältnis berechnen. Mit dem Basiswert 0,60–0,75 vergleichen.

Entscheidungsregel:

Verhältnis	Interpretation	Aktion
0,70+	Innerhalb des Normalbereichs	Beibehalten – kein dringender Mobile-Fix
0,50–0,69	Leichte Unterperformance	Mit Problem 3 (PDP-Mobile-Absprung) beginnen
0,30–0,49	Materielles Problem	Alle 4 Problemerkennungen durchführen; meist Problem 2 oder 4
< 0,30	Katastrophal	Wahrscheinlich Problem 4 (falsche Zielgruppe) UND Problem 1 kombiniert

Fünf Minuten, kein Drittanbieter-Tool, eine belastbare Antwort.

Ehrlicher Vorbehalt: Der Seiten-Bericht lässt sich in der aktuellen Statnive-Oberfläche nicht nach Gerätetyp filtern – der Querverweis ist manuell, nicht automatisiert. Ein nach Gerät gefilterter Endpunkt steht auf der Roadmap. Bis dahin ist der Zwei-Tab-Workflow der funktionierende Ersatz.

Die 5 evidenzbasierten Mobile-Engpässe, in Prioritätsreihenfolge

Wenn Sie identifiziert haben, welches Problem Sie haben, hier die Prioritätswarteschlange der Fixes. Jeder ist an konkrete Forschung gebunden, nicht an Bauchgefühl.

Engpass 1 – Mobiler LCP (Largest Contentful Paint) über 2,5 Sekunden

Evidenz: Die Deloitte/55/Google-Studie „Milliseconds Make Millions” (Ende 2019, vor Core Web Vitals): Eine Verbesserung der mobilen Geschwindigkeit um 0,1 Sekunden brachte einen Retail-Conversion-Anstieg von 8,4 % und einen AOV-Anstieg von 9,2 % über 30 Millionen Sessions bei 37 Markenseiten. Die Studie liegt vor dem offiziellen Core-Web-Vitals-Signal, aber der Effekt wird weiterhin breit zitiert.

So messen Sie: Google PageSpeed Insights. Geben Sie Ihre Top-Mobile-Einstiegsseite ein. Notieren Sie den mobilen (nicht den Desktop-) LCP. Ziel ≤ 2,5 Sekunden; die LCP-Schwellen-Updates 2026 setzen „gut” auf ≤ 2,0 Sekunden.

So beheben Sie: Bildoptimierung (WebP/AVIF), Lazy-Loading unterhalb der Falz, Server-Caching-Plugin (WP Rocket, Cache Enabler), JavaScript auf Landingpages reduzieren.

Engpass 2 – Above-the-Fold-CTA auf 375 px nicht sichtbar

Evidenz: Baymards Mobile-PDP-Forschung – der primäre CTA muss auf einem 375-px-Viewport (Breite von iPhone SE / iPhone Mini) ohne Scrollen erreichbar sein. Laut Nielsen-Norman-Group-Forschung zur Aufmerksamkeit entfallen 57 % der Betrachtungszeit auf den Bereich oberhalb der Falz bei modernen responsiven Sites.

So messen Sie: Öffnen Sie Ihre Top-PDP in Chrome DevTools bei 375 × 667. Den Kaufen-Button ohne Scrollen sehen? Nein = Problem.

So beheben Sie: Hero-Bildhöhe reduzieren, Titel-und-Preis-Block nach oben verschieben, CTA in die Daumenzone (unten rechts für rechtshändigen Daumen).

Engpass 3 – Reibung in der Produktbildgalerie

Evidenz: Baymard-Korrelation: Die Fähigkeit, alle Produktbilder flüssig zu durchblättern, korreliert mit ~ 0,6 mit der „In den Warenkorb”-Rate. Die häufigsten Fehlerformen: Zoom funktioniert nicht, Swipen ruckelt, Galerie zeigt nur 1 Bild ohne Indikator, dass mehr existieren.

So messen Sie: Öffnen Sie auf einem echten Telefon (keine Desktop-Emulation) eine PDP. Wischen Sie durch alle Bilder. Versuchen Sie zu zoomen. Wenn etwas stockt oder nicht funktioniert, beheben Sie es.

So beheben Sie: Auf ein Theme/Plugin mit bewährter Mobile-Galerie wechseln (Astra, Botiga, Storefront 4.x, Kadence). Speziell auf iOS Safari testen.

Engpass 4 – Checkout-Formular zu lang, Passwort-Pflicht, Captcha

Evidenz: Baymards Forschung zum Checkout-Flow: Der Median eines Großshop-Checkouts hat 14,88 Felder; eine Reduzierung auf das Minimum bringt 25–35 % Conversion-Anstieg in mobilen Kontexten. 24 % der US-Abbrecher nennen die erzwungene Kontoerstellung; 19 % nennen speziell die Passwortanforderung.

So messen Sie: Zählen Sie die sichtbaren Pflichtfelder auf /checkout auf Mobile. Bei > 8 sind Sie über dem Optimum. Prüfen Sie, ob eine Kontoerstellung erforderlich ist.

So beheben Sie: WooCommerce → Einstellungen → Konten & Datenschutz → „Kunden Bestellungen ohne Konto ermöglichen” aktivieren. Optionale Felder (Firma, Adresszeile 2, Bestellnotizen, oft Telefon) in WooCommerce → Einstellungen → Erweitert → Konto & Datenschutz deaktivieren. Stellen Sie sicher, dass jedes Input den richtigen inputmode hat, damit Mobile-Tastaturen optimiert werden (numerisch für Postleitzahl, email für E-Mail).

Engpass 5 – Mismatch beim Zahlungsanbieter

Evidenz: Stripes Forschung zur Apple-Pay-Adoption deutet auf 8–15 % Mobile-Conversion-Anstieg hin, wenn Apple Pay verfügbar ist, variierend nach Kategorie und Region. Laut Daten von Stripe und PayPal bevorzugen mobile Käufer One-Tap-Zahlung gegenüber manueller Karteneingabe.

So messen Sie: Öffnen Sie /checkout auf einem iPhone. Ist ein Apple-Pay-Button sichtbar? Auf Android Google Pay? Wenn nur „Kreditkarte” erscheint, haben Sie ein Reibungsproblem bei der Zahlung.

So beheben Sie: Apple Pay + Google Pay über WooPayments, Stripe oder Square aktivieren. Die Plugin-Installation dauert 5 Minuten; die Aktivierung von Apple Pay erfordert einen Domain-Verifizierungsschritt, der weitere 15 Minuten dauert.

Vier Mobile-Antipatterns, die Sie auslassen sollten

Diese tauchen in jedem „Mobile-WooCommerce-Optimization”-Beitrag auf. Die Forschung entkräftet sie.

1. „Machen Sie Ihre Site responsiv – das ist Mobile-Optimierung.” Laut Nielsen Norman Group ist Responsive Design ein Ausgangspunkt, keine Strategie. Responsive stellt sicher, dass die Site auf Mobile lädt; es optimiert nicht das Erlebnis für daumengesteuerte Eingaben, langsamere Netze oder kleinere Viewport-Prioritäten.
2. „Fügen Sie ein Mobile-only-Popup zum Sammeln von E-Mails ein.” Laut Googles Richtlinie zu aufdringlichen Interstitials (2017) können Vollbild-Mobile-Interstitials eine Ranking-Strafe auslösen. Laut Baymards Mobile-UX-Forschung haben Mobile-Popups einen Abbruch-Aufschlag von 23–31 % gegenüber ihren Desktop-Äquivalenten. Verwenden Sie stattdessen Inline-Formulare auf Seiten ohne Kaufabsicht; setzen Sie auf PDP, Cart oder Checkout kein Popup ein.
3. „Überall Hamburger-Menüs.” Laut NN/gs Hamburger-Menü-Forschung reduzieren versteckte Menüs die Auffindbarkeit um etwa 50 %. Mobil-essenzielle Primärnavigation (Kategorie, Warenkorb, Suche) sollte sichtbar sein, nicht hinter einem Hamburger. Der Hamburger ist nur für Sekundärnavigation akzeptabel.
4. „Mobile-First bedeutet kleinere Schriftgrößen, um mehr above the fold unterzubringen.” Laut WCAG 1.4.4 muss Text auf 200 % skalierbar sein. Apples HIG schreibt 17 pt als Mindest-Body-Text vor; Material Design schreibt 16 sp vor. Kleinere Schriftgrößen verletzen die Barrierefreiheit und reduzieren die Conversion bei den über 50 % der mobilen Käufer über 40 mit leichter Sehschwäche.

WooCommerce-spezifische Mobile-Stolperfallen

Drei Theme- und Plugin-Fakten, die ändern, wie Ihre Mobile-Daten zu lesen sind.

1. Block-basierter Checkout > Shortcode-Checkout auf Mobile, sowohl für UX als auch für saubere Analytics. Der block-basierte Checkout wurde mobile-first mit kürzeren sichtbaren Feldern und besserem Tastatur-Handling neu gestaltet. Wenn Sie 2026 noch auf dem Shortcode-Checkout sind, ist die Migration der wirksamste einzelne Mobile-Fix, den Sie machen können.
2. AMP für WooCommerce ist für Statnive unsichtbar. AMP-Seiten werden aus Googles Cache ausgeliefert und laufen in einer eingeschränkten JavaScript-Laufzeit. Statnives Tracker feuert auf AMP-Seiten nicht, daher erscheint AMP-Traffic in Ihrer Webanalyse als null. Die Lösung ist nicht, eine AMP-Integration hinzuzufügen (AMP ist faktisch abgekündigt); die Lösung ist, AMP zu deaktivieren und stattdessen auf die Optimierung der Core Web Vitals zu setzen.
3. Apple-Pay/Google-Pay-Verfügbarkeit variiert je Gateway. WooPayments (Automattic): beide, nativ. Stripe: beide, mit einmaliger Domain-Verifizierung für Apple Pay. PayPal Payments: Apple Pay über den PayPal-Flow, nicht Apple-nativ. Square: regional, nur US/CA/UK/AU. Prüfen Sie die Dokumentation Ihres Gateways, bevor Sie Kunden „Apple Pay an der Kasse” versprechen.

Was der v1.0.0 Revenue-Report hinzufügt – und was er weiterhin nicht abdeckt

Ab v1.0.0 deckt der Cart-to-Purchase-Funnel im Revenue-Report den prominenten Checkout-Abbruch ab – Produkt angesehen → In den Warenkorb gelegt → Checkout gestartet → Kauf abgeschlossen, serverseitig aus WooCommerce. Sie sehen Mobile-Engpässe sofort auf Stufenebene.

Zwei feinkörnigere Grenzen bleiben, ehrlich gerahmt:

1. Pro Teil-Schritt innerhalb /checkout. Statnives Funnel endet bei „Checkout gestartet” / „Kauf abgeschlossen”. Ob mobile Besucher konkret bei Versandauswahl, Zahlungsauswahl oder Bestellprüfung abgebrochen haben, wird nicht ausgewiesen – ein checkout_step-Event ist eine künftige Ergänzung.
2. Pro-Bild-Interaktionsanalyse. Haben mobile Besucher durch 1 Bild oder alle 5 gewischt? Sie gehen Ihre eigene PDP auf einem echten Telefon durch. Per-Interaktion-Event-Tracking ist nicht in v1.0.0.

Für die übergeordnete Mobile-vs-Desktop-Diagnose treiben das 4-Problem-Framework + Zwei-Tab-Audit + 5-Engpass-Prioritätswarteschlange weiterhin die Priorisierung. Der Revenue-Report fügt obenauf ein Ranking nach Umsatzwirkung hinzu: Ein Mobile-Fix auf einem Top-Products-Eintrag ist mehr wert als derselbe Fix auf einer Long-Tail-PDP.

Was als Nächstes zu tun ist

1. Öffnen Sie den Statnive-Geräte-Bericht. Berechnen Sie Ihren Mobile-Anteil + Mobile-Absprung.
2. Öffnen Sie WC Analytics → Bestellungen. Berechnen Sie Ihr Verhältnis Mobile CR ÷ Desktop CR.
3. Nutzen Sie die Entscheidungstabelle oben, um zu identifizieren, welches der 4 Probleme Ihres ist.
4. Wenden Sie den Engpass-Fix mit der höchsten Evidenz für dieses Problem an.
5. Warten Sie 30 Tage. Messen Sie absolute Bestellungen davor vs. danach. Behalten Sie, wenn der Anstieg ≥ 20 % beträgt.

Für den breiteren wöchentlichen CRO-Loop siehe den Pillar zu datenschutzfreundlicher Webanalyse für WooCommerce-CRO. Für die Mathematik des absoluten Verlusts auf Ausstiegsseiten siehe Einstiegs- und Ausstiegsseiten. Für Channel-Qualitätsentscheidungen, die Ihren Mobile-Traffic speisen, siehe WooCommerce-Traffic-Quellen ohne GA4.