Headless ist kein Trend, sondern eine Architekturentscheidung. Und die lohnt sich nur in klar abgegrenzten Szenarien.

1. Komplexe User Journeys
Wenn die Customer Journey mehr Logik braucht, als ein klassisches Theme sauber abbilden kann:
Produkt-Konfiguratoren
B2B-Portale mit kundenspezifischen Preisen
Abo-Modelle
geführte Beratungsstrecken
dynamische Formulare oder Entscheidungsbäume
Sobald du anfängst, gegen die Plattform zu kämpfen, statt mit ihr zu arbeiten, ist Headless oft die stabilere Lösung.

2. Internationale Setups
Mehrere Märkte, Sprachen, Währungen, unterschiedliche Sortimente oder Inhalte pro Region.
Ein entkoppeltes Frontend kann:
über mehreren Stores liegen
trotzdem ein konsistentes Markenerlebnis liefern
regionale Logiken sauber trennen und ohne Limitierungen skalieren

3. Content & Commerce verschmelzen
Wenn Inhalte aus verschiedenen Systemen in einer Experience zusammenlaufen sollen:
redaktionelle Inhalte aus einem CMS
Produktdaten aus dem Shop
Kundendaten aus CRM / ERP
Storytelling + Kaufoption
Magazin- oder Markenwelten

Dann ist ein entkoppeltes Frontend die natürliche Architektur.

Drei Fragen, die du vorher beantworten musst
Gibt es eine konkrete Anforderung, die das bestehende Shopsystem nachweislich nicht kann?
Nicht „schwierig“, nicht „unschön“ — sondern unmöglich.

Hast du die Kapazität, ein eigenes Frontend dauerhaft zu betreiben?
Intern oder über einen Partner.
Headless ist Softwarebetrieb, nicht Theme-Pflege.

Steht der Mehraufwand in einem messbaren Verhältnis zum Umsatz?
Nicht zum Ego, nicht zum „besseren Gefühl“.

Wann du Headless NICHT machen solltest
„weil es modern ist“
„weil der Wettbewerber das macht“
„weil die Agentur das spannend findet“
Das sind Motive, keine Anforderungen.
Und ja:
Manchmal hat man einfach das falsche Shopsystem gewählt — oft, weil „der Wettbewerber das auch nutzt“. -> Wechsel auf ein richtiges System?

Headless ist ein Werkzeug, kein Statussymbol
Wer Headless aus Prestigegründen kauft, zahlt jeden Monat die Rate dafür.

Was Headless kostet
1. Der Initiale Build ist teurer: Du baust ein Frontend von Grund auf. Alles, was ein Theme mitbringt, musst du: nachbauen, ersetzen oder bewusst weglassen.
2. Das Ökosystem schrumpft: Plugins werden zu Entwicklungsprojekten. Jede Integration ist Arbeit.
3. Du betreibst jetzt Software: Das heißt Hosting, Deployments, Dependency-Updates, Monitoring, Security, Performance-Optimierung. Ein Headless-System wartest du.
4. Jede Änderung braucht Entwickler
Der Marketing-Kollege, der „mal schnell“ eine Sektion umbaut?
Nur möglich, wenn du diese Flexibilität explizit gebaut hast.

Headless = automatisch schnell? Nein!

Ein schlecht gebautes Headless-Frontend ist langsamer als ein sauberes Theme eines klassischen Systems.
Und es gibt ein ganzen Haufen schlecht gebaute Headless-Systeme.
Performance ist:
Architektur
Rendering-Strategie
Caching
API-Design
Build-Pipeline
Infrastruktur
Nicht „Headless“.