Headless oder klassisch: Wann sich die getrennte Shop-Architektur wirklich rechnet

„Wir hätten gern einen Headless-Shop, das ist ja Stand der Technik“ — diesen Satz hören wir seit etwa zwei Jahren regelmäßig in Erstgesprächen. Die ehrliche Reaktion: Headless ist eine Architektur-Wahl, kein Premium-Versprechen. Sie hat einen konkreten Sinn, sie hat einen konkreten Preis, und sie passt nicht für jeden Shop.

Dieser Artikel sortiert den Unterschied zwischen Headless und klassisch, beschreibt die drei Treiber, die Headless rechtfertigen, und benennt die Stellen, an denen die Architektur regelmäßig überschätzt wird. Wer die Entscheidung sauber trifft, baut schneller, günstiger und mit weniger Folge-Kosten.

Was Headless technisch wirklich heißt

Ein klassischer Shop ist ein einziges System. Wer im Backend ein Produkt anlegt, erscheint es im Storefront mit Foto, Beschreibung, Preis, „in den Warenkorb“-Knopf. Backend und Frontend laufen im selben Software-Paket, gepflegt vom selben Anbieter, mit denselben Updates. Beispiele: die meisten klassischen Shop-Systeme im Mittelstand.

Ein Headless-Shop trennt die zwei Welten. Im Hintergrund läuft eine reine Shop-Logik-Maschine — Sortiment, Bestand, Warenkorb, Kunden-Konten, Bestellungen, Bezahlung, Versand. Diese Maschine hat keine sichtbare Optik. Sie spricht über eine Schnittstelle (eine sogenannte API) mit beliebigen Frontend-Anwendungen: einer Web-Storefront, einer Mobil-App, einem Konfigurator, einer Touch-Säule im Laden, einem Marktplatz-Datenfeed.

Das Storefront — die Website, die der Käufer sieht — wird separat gebaut, oft auf modernen Frontend-Technologien. Es zieht Sortiment, Preise und Warenkorb-Stand live aus der Schnittstelle und zeigt sie in einem eigenen Design.

Die Trennung klingt elegant. Sie hat aber Konsequenzen für jeden Klick im Alltag.

Was Headless gut macht

Freiheit im Storefront

Ein klassisches Shop-System gibt das Storefront-Gerüst vor — Themes, Templates, Vorgaben aus dem Standard. Wer ein wirklich individuelles Storefront-Erlebnis bauen will, das nichts von einem Standard-Theme erinnern lässt, kämpft im klassischen System gegen die eingebauten Schablonen. Im Headless-Modell ist das Storefront eine eigene Web-Anwendung — du baust, was du willst.

Für die meisten Shops ist das überdimensioniert. Für eine Marke, deren Storefront-Erlebnis Teil des Produkts ist (Mode-Premium-Linien, Design-Marken, Marken mit ungewöhnlicher Interaktions-Logik), ist es der eigentliche Grund für Headless.

Mehrere Kanäle an derselben Logik

Wer den Shop nicht nur als Website, sondern auch als Mobil-App, als Touch-Säule im Laden, als externen Konfigurator anbieten will, profitiert von Headless. Alle Kanäle ziehen aus derselben Quelle — ein Bestand-Stand, ein Preis-System, ein Konto-System. Wer die Kanäle in einem klassischen Shop nachbauen wollte, hätte oft das Problem, dass Bestand und Preis-Pflege auseinander laufen.

Optik-Updates ohne Shop-Eingriff

Wer das Storefront alle achtzehn Monate gestalterisch erneuert, ohne die Shop-Logik anzufassen, hat im Headless-Modell weniger Konflikte. Optik-Team und Shop-Team arbeiten in getrennten Systemen, mit klarer Schnittstelle dazwischen.

Was Headless schwer macht

Doppelte Architektur

Zwei Systeme heißt zwei Updates, zwei Sicherheits-Routinen, zwei Hosting-Umgebungen, zwei Wartungs-Verträge. Wer im klassischen Shop einen Update-Aufwand hat, hat im Headless-Modell oft den zwei- bis dreifachen. Das macht das Modell nicht falsch — aber es macht den Pflege-Aufwand höher, dauerhaft.

Standard-Funktionen, die plötzlich Bau-Arbeit sind

Klassische Shop-Systeme bringen viele Standard-Funktionen mit: Produkt-Vergleiche, Wunsch-Listen, Rabatt-Codes, Filter, Sortiermöglichkeiten, Bewertungs-Module. Im Headless-Storefront muss vieles davon selbst gebaut werden, weil die Shop-Logik-Maschine nur die Roh-Daten liefert. Das ist nicht unlösbar — aber es ist Bau-Arbeit, die im klassischen Shop schlicht da gewesen wäre.

Updates müssen koordiniert werden

Wenn die Shop-Logik ein Update bekommt, das die Schnittstelle ändert, muss das Storefront mit-aktualisiert werden. Wer das versäumt, bekommt Brüche im Live-Betrieb. In klassischen Shops passiert das Update automatisch im selben System.

Die drei Treiber, die Headless rechtfertigen

Treiber 1: Echter Multi-Channel-Bedarf

Wenn du sicher weißt, dass dein Shop nicht nur als Web-Storefront laufen wird, sondern auch als Mobil-App, als Touch-Säule im Laden, als externer Konfigurator — und alle diese Kanäle dasselbe Sortiment, dieselben Preise, dieselben Konten brauchen — dann ist Headless die saubere Antwort.

Treiber 2: Ungewöhnlich anspruchsvolle Storefront-Anforderungen

Wenn deine Marke ein Storefront braucht, das man in einem Standard-Theme-Korsett nicht bauen kann — etwa eine ungewöhnliche Navigations-Logik, eine besondere Inhalts-Verkettung von Geschichten und Produkten, oder ein Erlebnis, das mehr Editorial-Magazin als Shop ist — dann gibt Headless dir die nötige Freiheit.

Treiber 3: Geplanter Shop-System-Wechsel ohne Storefront-Neubau

Wer weiß, dass er in zwei bis drei Jahren das Shop-System wechseln wird (etwa weil das aktuelle System absehbar nicht mehr trägt), kann mit Headless den Storefront so bauen, dass nur die Schnittstelle umgehängt wird — der Storefront-Code bleibt. Das ist eine eher seltene strategische Wette, aber sie kann den Wechsel später deutlich verkürzen.

Warum klassisch für 80 Prozent die richtige Antwort ist

Für die meisten Mittelständler gilt: Ein klassischer Shop ist schneller live, günstiger im Bau, einfacher in der Pflege, hat mehr Standard-Funktionen out-of-the-box, und das Storefront ist über Themes und Anpassungen weit genug individualisierbar.

Wer keinen der drei Treiber hat — kein Multi-Channel-Bedarf, keine außergewöhnlichen Storefront-Anforderungen, keinen Plan für einen Shop-System-Wechsel — der zahlt für Headless einen Aufpreis ohne entsprechenden Gegenwert. Headless ist dann nicht „moderner“, sondern teurer ohne Substanz-Vorteil.

Die Versuchung, Headless als Premium-Marker zu sehen („wir sind modern, wir machen Headless“), ist verständlich, aber irreführend. Premium im Shop kommt aus Sortiment, Substanz, Service und Vertrauen — nicht aus der Architektur dahinter, die der Käufer ohnehin nicht sieht.

Was Hannes daraus macht

Wir bauen beide Architekturen — klassisch und Headless — auf einer Shop-Logik-Maschine, die beides kann. Welche Variante zum Auftrag passt, klären wir im Audit.

• Wenn keiner der drei Treiber vorliegt, empfehlen wir klassisch. Schneller live, günstiger, einfacher in der Pflege.
• Wenn Multi-Channel-Bedarf vorliegt — etwa Shop plus geplante Mobil-App plus Touch-Säule im Laden — bauen wir Headless mit klar dokumentierter Schnittstelle.
• Wenn das Storefront außergewöhnlich individuell sein muss, bauen wir Headless mit einer modernen Frontend-Architektur, die alle Optik-Freiheiten erlaubt.
• Wenn ein Shop-System-Wechsel absehbar ist, planen wir die Schnittstelle so, dass der Wechsel später ohne Storefront-Neubau möglich ist.

In jedem Fall: kein Headless ohne konkreten Treiber. Wir verkaufen keine Architektur als Premium-Marker, sondern als Antwort auf einen konkreten Bedarf.