Klassisches vs. headless WooCommerce
Die Kurzfassung: Bleiben Sie bei klassischem WooCommerce, wenn ein PHP-Server mit gutem Caching einen einzelnen Shop bedienen kann, und gehen Sie headless, wenn mobile Geschwindigkeit den Umsatz deckelt, der Katalog groß ist oder ein Katalog mehrere Frontends speisen muss. Headless ist nicht automatisch besser. Es ist unter bestimmten Bedingungen besser, und ein Neubau außerhalb dieser Bedingungen fügt nur Kosten hinzu.
Headless WooCommerce bedeutet, dass WordPress und WooCommerce als Backend bestehen bleiben, bereitgestellt über die Store API oder WPGraphQL, während das PHP-Theme durch ein entkoppeltes Frontend auf Next.js oder Astro ersetzt wird, das am Edge gecachtes HTML rendert.
Die Entscheidungsmatrix
| Kriterium | Klassisches WooCommerce | Headless WooCommerce |
|---|---|---|
| Katalogvolumen | Bis zu einigen Tausend SKUs | Große Kataloge, facettiertes Browsing |
| Mobile Core Web Vitals | Gut mit Full-Page-Caching | Am besten, null PHP pro Anfrage am Edge |
| Aufbau- und Betriebskosten | Niedriger, ein Stack | Höher, zwei Stacks zu pflegen |
| Redaktionserfahrung | Natives WordPress | Natives WordPress, Vorschau auf separater Domain |
| Mehrere Frontends | Ein Shop | Ein Katalog, viele Frontends |
| Checkout-Komplexität | Nativ, am einfachsten | Serverseitig autoritativ, mehr Verdrahtung |
| Time to ship | Schneller | Etwa sechs Wochen für einen mittelgroßen Shop |
Wann das klassische Modell weiterhin gewinnt
Für einen einzelnen Shop unter einigen Tausend Produkten erreicht ein klassisches WooCommerce auf hochwertigem EU-Hosting mit Full-Page-Caching, sauberer Datenbank und optimierten Assets ein mobiles LCP unter zwei Sekunden ohne Neubau. Ein deutscher Mittelstandsshop mit ein paar Hundert Artikeln und sauberem Theme braucht keine zweite Codebasis, um schnell zu sein. Wenn Ihr Shop heute langsam ist, liegt die Ursache fast immer an Infrastruktur und technischen Schulden, nicht am Rendering-Modell. Beheben Sie das zuerst. Der Leitfaden zur WooCommerce-Performance-Optimierung zeigt genau wie, und er ist weitaus günstiger als der Wechsel auf headless.
Ein Shop in Visitenkartengröße, ein Shop mit kleinem Katalog oder ein Team ohne Frontend-Kapazität, einen zweiten Stack zu pflegen, sollte klassisch bleiben. Die Wartungskosten zweier Stacks sind real und wiederkehrend.
Wann headless gewinnt
Headless verdient seine Kosten in drei Situationen. Erstens, wenn mobile Core Web Vitals den Umsatz direkt formen und ein caching-optimierter Monolith das LCP unter Last weiterhin nicht unter zwei Sekunden halten kann. Zweitens, wenn der Katalog groß ist und facettiertes Browsing das PHP-Rendering zum Engpass macht. Drittens, wenn ein Katalog mehrere Oberflächen speisen muss, etwa einen Web-Shop, eine native App und einen Kiosk im Ladengeschäft, aus einer einzigen Quelle der Wahrheit. Ein DACH-Modehändler, der Black-Friday-Lastspitzen auf dem Smartphone bedient, ist genau der Fall, in dem sich das Edge-Rendering auszahlt.
In diesen Fällen rendert das Frontend vorgefertigtes HTML am Edge ohne PHP pro Anfrage, was die schlimmsten Tail-Latency-Fälle beseitigt, während WooCommerce weiterhin Katalog, Bestellungen, Steuer und Lagerbestand besitzt.
Der Teil, den alle unterschätzen: der Checkout
Der Checkout ist die Stelle, an der headless WooCommerce-Migrationen gelingen oder scheitern. Zahlung, Steuer und Bestellanlage müssen serverseitig autoritativ in WooCommerce bleiben. Das Frontend orchestriert die Schritte, aber das Backend besitzt das Geld. Die Checkout-Logik im Frontend neu zu implementieren ist der Weg, auf dem Shops mit falsch berechneten Bestellungen und kaputter Mehrwertsteuer enden. Wir halten den Checkout serverseitig und lassen das Frontend die Erfahrung darum herum führen.
Wie die Migration abläuft
Der Zeitplan wird von zwei Dingen dominiert: den Checkout korrekt zu halten und das SEO verlustfrei zu übertragen. Zuerst frieren wir den Datenvertrag ein, bauen das Frontend gegen die Store API, halten den Checkout in WooCommerce, bewahren jede URL und jeden Block strukturierter Daten und schalten dann hinter einem CDN um, mit dem alten Shop weiterhin erreichbar, bis das neue sich bewährt hat. Ein Crawl-Diff vor dem Start ist das, was die Ranking-Einbrüche verhindert, die headless einen schlechten Ruf geben.
WordPress-Newsletter
Tipps, Updates und WordPress-Best-Practices einmal im Monat.
Wir respektieren Ihre Privatsphäre. Kein Spam.
Nicht sicher, auf welcher Seite Sie stehen?
Wir zerlegen den Trade-off gegen Ihren realen Katalog, Traffic und Ihr Team, bevor wir irgendetwas empfehlen. Oft ist die ehrliche Antwort, zuerst den klassischen Shop zu optimieren und headless später erneut zu prüfen.
Klassisch gegen headless abwägen?
Holen Sie sich eine Migrationsbewertung. Wir bewerten Ihren Shop anhand der Entscheidungsmatrix, modellieren die Kosten in beide Richtungen und sagen Ihnen klar, welche Variante passt, auch wenn die Antwort lautet, klassisch zu bleiben.
Bewertung anfordern →Verwandte Ressourcen
- WooCommerce-Performance-Optimierung - probieren Sie dies vor einem Neubau
- WooCommerce-Entwickler - wie wir an Shops arbeiten
- Shopify Plus vs. headless WooCommerce - falls Sie auch Shopify abwägen
- Headless WordPress: Next.js vs. Astro - die Wahl des Frontend-Frameworks
- Migrations-Fallstudie: PageSpeed 18 auf 99 - ein realer Neubau auf einen modernen Stack, Ladezeit 12 s auf 0,3 s, mit vollständigen Metriken
