Headless Shopify: Was im Shopsystem bleibt und was eigen wird
Headless Commerce wird meist als Geschwindigkeitsentscheidung verkauft. Das ist sie nicht. Sie ist eine Grenzentscheidung: Ein Teil des Shops bleibt im Shopsystem, ein anderer wandert in eine eigene Storefront, und die Qualität des Ergebnisses hängt fast vollständig davon ab, wo diese Grenze verläuft. Wer sie falsch zieht, baut Dinge nach, die es fertig gibt, und verliert gleichzeitig die Kontrolle über das, worauf es ankommt. Dieser Beitrag beschreibt, welche Bereiche bei Shopify gut aufgehoben sind, welche in eine eigene Storefront gehören, was man dabei aufgibt und woran man vorher merkt, dass sich der Aufwand nicht lohnt.
Kernpunkte
- Checkout, Zahlarten, Steuerlogik und Bestände bleiben im Shopsystem. Ein Nachbau ist teuer und macht nichts besser.
- In die eigene Storefront gehört, was darüber entscheidet, ob jemand das passende Produkt findet: URLs, Inhalte, Filterlogik und Rendering.
- Headless ist kein Performance-Versprechen. Eine schlecht gebaute Storefront ist langsamer als ein gepflegtes Standard-Theme.
- Der visuelle Theme-Editor entfällt. Frontend-Änderungen werden zur Entwicklungsaufgabe und brauchen einen festen Ablauf.
- Viele Shop-Apps setzen auf das Standard-Theme auf und funktionieren headless nicht ohne Ersatz. Diese Liste gehört vor den Projektstart, nicht danach.
Die Entscheidung ist eine Grenzziehung, keine Geschwindigkeitsfrage
In fast jedem Erstgespräch fällt der Satz, headless sei schneller. Pauschal stimmt das nicht. Eine Storefront ohne saubere serverseitige Auslieferung, ohne Bildstrategie und ohne Zwischenspeicher ist langsamer als ein gut gewartetes Standard-Theme, das seit Jahren auf genau diesen Fall optimiert wird. Geschwindigkeit ist ein Ergebnis sorgfältiger Umsetzung, nicht der Architektur.
Was headless tatsächlich verändert, ist die Zuständigkeit. Ein Shopsystem liefert im Standardfall beides: die kaufmännische Maschine und die Oberfläche. Bei einer Headless-Architektur bleibt die Maschine, die Oberfläche wird ersetzt. Damit verschiebt sich, wer über Seitenstruktur, Inhalte, Filter und Auslieferung entscheidet — vom Theme zum eigenen Team.
Die nützliche Frage lautet deshalb nicht „headless oder nicht“, sondern: Welche Teile unseres Shops sind Standard und sollten Standard bleiben, und welche sind der Grund, warum Kunden bei uns kaufen und nicht woanders? Der zweite Teil rechtfertigt eigenen Code. Der erste nie.
Was im Shopsystem bleiben sollte
Der Checkout ist der klarste Fall. Er hängt an Zahlarten, an Betrugserkennung, an steuerlichen Regeln, an Sicherheitsanforderungen für Kartendaten und an jahrelanger Optimierung auf Abschlussraten. Er wird laufend weiterentwickelt, ohne dass jemand im Projekt etwas dafür tun muss. Ein Eigenbau bindet Budget, erzeugt dauerhafte Wartung und verbessert die Abschlussrate im Regelfall nicht.
Dasselbe gilt für Bestände, Bestellungen, Rückgaben und Kundenkonten. Das sind gelöste Probleme mit hohem Folgeaufwand. Wer sie in die eigene Anwendung zieht, übernimmt Verantwortung für Datenkonsistenz, für Schnittstellen zur Warenwirtschaft und für jede spätere Änderung an Steuersätzen oder Zahlungsanbietern.
Auch die Versandlogik gehört in den Bereich, in dem Regeln konfiguriert und nicht programmiert werden sollten. Gewichtsklassen, Zonen, Schwellen für kostenfreien Versand: All das ändert sich betriebswirtschaftlich, nicht technisch. Wenn eine Änderung an der Versandschwelle einen Entwickler braucht, ist die Grenze falsch gezogen.
Was in die eigene Storefront gehört
Alles, was darüber entscheidet, ob jemand das richtige Produkt findet. Das beginnt bei den Adressen: Welche Seiten existieren, wie sie heißen, welche Filterkombination eine eigene, verlinkbare URL bekommt und welche nur ein Anzeigezustand ist. Standard-Themes beantworten diese Frage generisch, weil sie für jedes Sortiment funktionieren müssen. Ein spezialisiertes Sortiment braucht spezifischere Antworten.
Beim Relaunch von Schockmann Schuhe, den wir als Case Study dokumentiert haben, war das der eigentliche Hebel. Ein Komfortschuh-Sortiment lebt von Merkmalen, die im Standard nirgends als Filter vorgesehen sind: Halbgrößen über einen ungewöhnlich breiten Bereich, Weiten, und die Frage, ob ein Modell für eigene Einlagen geeignet ist. Steht diese Information nur im Beschreibungstext, ist sie für die Suche im Shop praktisch nicht vorhanden. Als echter Filter verändert sie den Weg zum Produkt.
Der zweite Bereich sind Inhalte, die vor dem Produkt kommen. Wer nach einem Beschwerdebild sucht, sucht keinen Artikelnamen. Solche Einstiege brauchen eigene Seiten mit eigener Adresse und eigenem Canonical, damit sie in der Suche bestehen und intern auf die passende Auswahl führen können. Im Standard-Theme enden sie meist als Blogbeitrag ohne Verbindung zum Sortiment.
Der dritte Bereich ist die Auslieferung selbst. Wer entscheidet, welche Seiten vorgerendert ausgeliefert werden, entscheidet auch darüber, was Suchmaschinen und automatisierte Abrufe ohne JavaScript lesen können. Das ist bei einer eigenen Storefront eine bewusste Einstellung statt einer Eigenschaft des Themes.
Was man dabei aufgibt
Der visuelle Theme-Editor entfällt. Wer bisher Abschnitte per Oberfläche verschoben, Banner getauscht und Startseiten umsortiert hat, kann das nicht mehr selbst. Jede Frontend-Änderung wird zu einer Aufgabe mit Entwicklungs- und Freigabeschritt. Das ist kein technisches, sondern ein organisatorisches Problem: Wenn das Marketing gewohnt ist, wöchentlich selbst umzubauen, muss vorher geklärt sein, wie das künftig läuft.
Ein großer Teil der verfügbaren Apps setzt auf dem Standard-Theme auf und bindet sich dort automatisch ein. Headless fällt dieser Mechanismus weg. Manche Anbieter stellen Schnittstellen bereit, manche nicht. Die Liste der eingesetzten Apps gehört deshalb vor den Projektstart auf den Tisch, zusammen mit der Entscheidung, was ersetzt, nachgebaut oder gestrichen wird.
Und die Verantwortung verschiebt sich dauerhaft. Ein Standard-Theme wird vom Anbieter gepflegt. Eine eigene Storefront wird von dem gepflegt, der sie gebaut hat. Das ist nicht schlimm, aber es ist ein Betriebskostenposten, der in der ersten Kalkulation gerne fehlt.
Wann sich der Aufwand nicht lohnt
Bei einem übersichtlichen Sortiment ohne besondere Auswahllogik gibt es wenig zu gewinnen. Wenn Kunden über den Markennamen kommen und wissen, was sie wollen, entscheidet nicht die Filterlogik über den Umsatz, sondern Verfügbarkeit und Versand. Ein sauber eingerichtetes Standard-Theme ist dann die wirtschaftlichere Antwort.
Auch wenn niemand im Unternehmen die laufende Pflege übernehmen kann oder will, ist Headless die falsche Wahl. Eine eigene Storefront ohne feste Zuständigkeit veraltet schneller als ein Theme, weil niemand sie automatisch aktualisiert.
Ein drittes Ausschlusskriterium ist ein reiner Geschwindigkeitswunsch. Wenn die Ladezeit das Problem ist, lohnt zuerst die Messung: In vielen Fällen liegt die Ursache bei Bildern, bei Drittanbieter-Skripten und bei zu vielen Apps — und lässt sich ohne Architekturwechsel beheben.
Die Fragen, an denen sich die Entscheidung entscheidet
Gibt es Produktmerkmale, nach denen Kunden auswählen, die sich im Standard nicht filtern lassen? Wenn ja, ist das das stärkste Argument für eine eigene Storefront — stärker als jedes Performance-Argument.
Braucht das Sortiment Einstiege, die weder Produkt noch Kategorie sind — Beratung, Anwendungsfall, Beschwerdebild? Diese Seiten sind oft der Grund, warum Menschen überhaupt auf den Shop stoßen.
Wer ändert künftig Inhalte, und wie schnell muss das gehen? Aus dieser Antwort folgt, wie viel Redaktionsfähigkeit die Storefront mitbringen muss — und ob eine Freigabestrecke nötig ist.
Und schließlich: Welche Apps sind heute im Einsatz, und was passiert mit jeder einzelnen? Diese Liste entscheidet oft über den tatsächlichen Projektumfang. Sie wird regelmäßig zu spät erstellt.
Quellen & weiterführende Links
Grenzen klären, bevor gebaut wird
Wir gehen Sortiment, Auswahllogik, Inhalte und die eingesetzten Apps durch und halten fest, was im Shopsystem bleibt, was eigen wird und was das im Betrieb kostet.
Digitalagentur Hamburg ansehen
Weiterführend: Case Study: Schockmann Schuhe.