Shop ohne Theme — deutlich aufwendiger als Inhalte.

Warum Shop anders ist.

Bei Inhalten fließen Daten in eine Richtung: WordPress gibt heraus, das Frontend stellt dar. Bei einem Shop fließen sie in beide Richtungen, und zwar mit Zustand — ein Warenkorb gehört zu einer Sitzung, eine Bestellung verändert Lagerbestände, eine Zahlung muss bestätigt werden.

Dazu kommt, dass fast jeder Schritt rechtliche Pflichten hat: Preisangaben, Versandkosten, Widerrufsbelehrung, Bestellübersicht, Bestätigungsschaltfläche. Das ist nicht Darstellung, sondern Vorschrift (WooCommerce-Fehler).

Katalog und Produktseiten.

Der einfachste Teil. Produkte, Kategorien, Bilder, Beschreibungen und Attribute lassen sich über die Schnittstelle abrufen und darstellen wie andere Inhalte auch.

Zwei Dinge sind trotzdem zu beachten. Erstens: Varianten mit ihren Kombinationen, Preisen und Verfügbarkeiten sind deutlich verschachtelter als ein Beitrag — hier spielt eine Abfragesprache ihren Vorteil aus (REST oder GraphQL). Zweitens: Preise und Verfügbarkeit dürfen nicht aus einer alten gespeicherten Fassung kommen. Diese Angaben gehören beim Aufruf frisch geholt (Lagerbestand).

Warenkorb und Sitzung.

Hier beginnt die eigentliche Arbeit. Klassisch führt WooCommerce den Warenkorb in einer Sitzung, die über ein Cookie an den Besucher gebunden ist. Im entkoppelten Aufbau liegt das Frontend woanders, und diese Sitzung muss übertragen werden.

Üblich ist ein Zugangsmerkmal, das der Shop ausstellt und das Frontend bei jeder Anfrage mitschickt. Daran hängen mehrere Fragen: Wie lange ist es gültig? Was passiert, wenn es abläuft, während jemand einkauft? Wie wird der Warenkorb eines Gastes übernommen, wenn er sich anmeldet? Wie funktioniert es auf zwei Geräten?

Jede dieser Fragen ist beantwortbar, aber keine beantwortet sich von selbst. Ein verlorener Warenkorb ist ein verlorener Kauf (Warenkorb leert sich).

Kasse.

Der kritischste Teil. Nachzubauen sind: Adressformulare mit Prüfung, Lieferadresse abweichend, Versandartenauswahl mit Neuberechnung, Gutscheincodes, Zahlungsartenauswahl, Bestellübersicht, Einwilligungen und die Bestellschaltfläche.

Jeder Schritt löst Neuberechnungen aus: Eine geänderte Lieferadresse ändert Versandkosten und womöglich die Steuer, ein Gutschein ändert den Betrag, eine Zahlungsart kann Gebühren haben. All das muss serverseitig berechnet werden — Berechnungen im Browser sind manipulierbar und damit keine Grundlage für eine Bestellung.

Dazu die Fehlerbehandlung: Was passiert bei ausverkaufter Ware während der Kasse, bei abgelehnter Zahlung, bei Verbindungsabbruch nach dem Absenden? Diese Fälle entscheiden darüber, ob der Shop im Alltag trägt (Kasse).

Zahlung.

Die meisten Zahlungs-Plugins für WooCommerce sind für den klassischen Betrieb gebaut: Sie erzeugen Formulare, leiten weiter, verarbeiten Rückmeldungen im Theme-Kontext. Im entkoppelten Aufbau funktioniert das nicht automatisch.

Zwei Wege: Die Zahlung läuft über die eigene Schnittstelle des Zahlungsanbieters, direkt aus dem Frontend — dann umgeht man das Plugin. Oder der Shop behält die Zahlungsstrecke, und das Frontend leitet dorthin weiter, was den Bruch im Ablauf sichtbar macht.

Prüf vor dem Projektstart, welche Zahlungsarten du brauchst und ob sie den entkoppelten Betrieb unterstützen. Das ist eine Frage, die ein Projekt kippen kann — und zwar nachdem schon gebaut wurde (Zahlung, Stripe).

Preise, Steuern, Versand.

Alle Berechnungen gehören auf die Shop-Seite, nicht ins Frontend. Das Frontend fragt nach und stellt dar, rechnet aber nicht selbst.

Besonders zu beachten: Steuersätze hängen von Produkt, Zielland und Kundenart ab; bei Verkäufen ins EU-Ausland gilt gegebenenfalls das besondere Verfahren. Versandkosten hängen von Gewicht, Zielgebiet und Warenwert ab. Kundengruppenpreise im Geschäftskundenbereich kommen dazu.

Jede dieser Regeln ist in WooCommerce bereits umgesetzt — sie im Frontend nachzubauen wäre nicht nur Arbeit, sondern eine Fehlerquelle mit steuerlichen Folgen (OSS, Versandkosten).

Lagerbestand.

Bestände dürfen nicht aus einer gespeicherten Fassung kommen. Bei statisch erzeugten Produktseiten heißt das: Die Seite kann statisch sein, Bestand und Preis werden beim Aufruf nachgeladen.

Dazu die Reservierung: Klassisch reduziert WooCommerce den Bestand beim Bestellvorgang. Dieser Mechanismus muss weiter greifen, sonst entstehen Überverkäufe bei gleichzeitigen Käufen (Lagerbestand).

Kundenkonto.

Registrierung, Anmeldung, Passwort zurücksetzen, Adressverwaltung, Bestellübersicht, Downloads, Abonnements — all das muss im Frontend neu gebaut werden, mit Anmeldung gegen den Shop.

Sicherheitsrelevant und oft unterschätzt: Die Anmeldung muss gegen wiederholte Versuche geschützt sein, Zugangsmerkmale brauchen eine sinnvolle Gültigkeit, und Kundendaten dürfen nicht in einer gespeicherten Fassung landen (Mein Konto, Kundendaten).

Rechtliche Pflichten.

Der Teil, bei dem Fehler teuer werden. Im Bestellprozess vorgeschrieben sind unter anderem: Preisangaben einschließlich Steuer und Versandkosten, Angaben zur Lieferzeit, die Bestellübersicht unmittelbar vor dem Absenden, eine eindeutig beschriftete Bestellschaltfläche, die Widerrufsbelehrung und die Bestellbestätigung.

Klassisch bringt WooCommerce das mit oder Plugins ergänzen es. Im entkoppelten Aufbau muss jede dieser Pflichten bewusst umgesetzt werden — und ob sie korrekt umgesetzt ist, kann ich als Entwickler nicht abschließend beurteilen. Das gehört anwaltlich geprüft, bevor der Shop live geht.

Dazu die Barrierefreiheit: Für Shops gegenüber Verbrauchern gelten gesetzliche Anforderungen, und ein selbst gebauter Bestellprozess muss sie erfüllen (BFSG im Shop).

Der Mittelweg.

Die Lösung, die ich am häufigsten empfehle: Katalog und Inhalte entkoppelt, Bestellprozess klassisch.

Also: Startseite, Kategorien, Produktseiten, Blog und Ratgeber laufen im schnellen Frontend. Sobald jemand in den Warenkorb legt, geht es in den klassischen Shop. Damit bekommt man Tempo genau dort, wo viele Besucher sind und wo es für die Sichtbarkeit zählt — und riskiert nichts an der Stelle, an der Geld und Recht hängen.

Der sichtbare Bruch im Ablauf lässt sich durch einheitliche Gestaltung so weit abmildern, dass er kaum auffällt. Das ist ein Kompromiss, aber ein sehr vernünftiger.

Ehrliche Abwägung.

Zeile eins deckt die große Mehrheit ab. Ein WooCommerce-Shop mit ordentlichem Hosting, vernünftigen Bildern, sauberem Caching und aufgeräumten Plugins ist schnell genug — und dieser Weg kostet einen Bruchteil (WooCommerce langsam, Ladezeit).

Zeile drei meint echte Sonderfälle: ein Konfigurator als zentrales Kaufelement, eine stark interaktive Produktdarstellung, 3D-Ansichten. Dort ist der Mehraufwand gerechtfertigt, weil er den Umsatz trägt (3D-Konfigurator).

Wenn du weiterkommen willst.

Wenn du über einen entkoppelten Shop nachdenkst und eine Einschätzung ohne Technikbegeisterung willst. Ich schaue mir an, was du vorhast, und sage dir, ob headless passt — und wenn nicht, was stattdessen: Headless WordPress. Geht es nur um Tempo, ist oft Ladezeitarbeit an der bestehenden Seite der günstigere Weg.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich arbeite seit Jahren mit WordPress und baue daneben eigene Plattformen mit Next.js — Lernplattformen mit mehreren tausend Seiten, bei denen WordPress als Redaktionssystem im Hintergrund läuft und das Frontend davon getrennt ist. Das ist also keine Theorie, sondern das, womit ich meine eigenen Projekte betreibe.

Genau deshalb sage ich auch offen, wann es sich nicht lohnt. Headless ist aufwendiger im Bau und im Betrieb, und für eine normale Unternehmenswebsite ist es fast immer die falsche Antwort. Wer mir schreibt und eine fünfzehnseitige Firmenwebsite headless bauen lassen will, bekommt von mir eine Rückfrage und keinen Kostenvoranschlag.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.