LIVE LABS / DEVLOG 001 / 28.10.2026
Ein technischer Werkstattbericht aus der Entwicklung von LEAFerservice.
Warum ich meinen Shopify-Shop nicht einfach durch Headless ersetze
Ich arbeite seit einiger Zeit daran, LEAFerservice technisch neu aufzustellen. Das Ziel ist eine individuell entwickelte Storefront, die mir bei Produktwelten, Hersteller-Landingpages und Konfiguratoren deutlich mehr Freiheit gibt als ein klassisches Theme. Gleichzeitig gibt es eine Anforderung, die für mich über jeder Architekturentscheidung steht: Der bestehende Shop muss weiter verkaufen können.
Genau deshalb habe ich mich gegen einen Big-Bang-Relaunch entschieden. Ich lasse den aktuellen Shopify-Liquid-Shop produktiv laufen und entwickle die neue Headless-Oberfläche parallel. Wenn ich an einem React-Router-Build arbeite oder eine Preview einen Fehler wirft, darf das nicht bedeuten, dass Kunden plötzlich nicht mehr bestellen können.
Mit diesem Beitrag starte ich Live Labs: ein Entwicklungstagebuch, in dem ich ungefähr alle zwei Tage dokumentieren möchte, was ich umgesetzt habe, wo ich technisch festhänge und welche Entscheidungen ich treffe. Keine nachträglich glattgezogene Erfolgsgeschichte, sondern ein nachvollziehbarer Blick in die laufende Entwicklung.
Die Vision: vom Produktkatalog zu konfigurierbaren Lösungen
Ich möchte nicht einfach ein weiteres Shop-Frontend bauen. Die eigentliche Idee ist, Produkte, Beratung und interaktive Werkzeuge enger miteinander zu verbinden. Wer ein Substrat sucht, soll nicht nur eine Liste von Artikeln sehen, sondern passende Mischungen verstehen und perspektivisch selbst konfigurieren können. Bei Pflanzenbeleuchtung möchte ich langfristig stärker in Richtung einer verständlichen Raum- und Lichtplanung gehen. Hersteller-Landingpages sollen die Produkte mit echten technischen Daten, passenden Ergänzungen und klaren Kaufwegen präsentieren.
Das setzt ein konsistentes Designsystem voraus. Kompakte Typografie, hochwertige Bilder, mobil gut bedienbare Elemente und ein ruhiger Aufbau sollen sich durch den gesamten Shop ziehen. Ich möchte nicht, dass einzelne Bereiche wie voneinander getrennte Experimente wirken – auch wenn im Hintergrund zeitweise Liquid und Headless nebeneinander laufen.
Meine Architekturentscheidung: ein Backend, zwei Storefronts
Shopify bleibt bei mir die maßgebliche Commerce-Schicht. Dort liegen Produkte, Varianten, Preise und die Daten, die für den Verkauf entscheidend sind. Auch der Checkout bleibt bei Shopify. Ich habe keinen Grund, für die neue Oberfläche einen zweiten Produktkatalog aufzubauen und damit neue Synchronisationsprobleme zu erzeugen.
SHOPIFY ADMIN
Produktdaten · Varianten · Preise · Checkout
↓ ein gemeinsamer Commerce-Datenbestand ↓
|
LIQUID Aktueller Live-Shop Produktiver Verkauf |
HEADLESS Hydrogen / React Router Vercel-Preview und Tests |
↓ Shopify Checkout ↓
Bestellung und Fulfillment
Die Headless-Seite entwickle ich auf Basis von Hydrogen beziehungsweise React Router. Für Builds und Vorschauen nutze ich eine Vercel-basierte Pipeline. Der Aufbau bleibt modular: Die Storefront ist austauschbar, die bestehenden Produkt-IDs und der Checkout nicht.
Technischer Hintergrund: Was heißt hier eigentlich „Headless“?
Die Präsentationsschicht wird vom Commerce-Backend entkoppelt. Shopify übernimmt weiterhin die Commerce-Funktionen; eine eigenständige Anwendung rendert Seiten und Interaktionen. Das bietet Flexibilität, erhöht aber auch die Verantwortung für Routing, Caching, Fehlerbehandlung, SEO und Deployment.
Ein konkretes Learning: „Aktiv“ ist nicht gleich „kaufbar“
Heute war ein gutes Beispiel dafür, warum ich technische Annahmen lieber gegen die tatsächlichen Shopdaten prüfe. Im Shopify-Admin standen 150 Produkte auf aktiv. Insgesamt waren das 356 Varianten. Bei der Prüfung der Bestandsrichtlinien mussten zehn Romberg-Varianten korrigiert werden. Danach waren bei allen 356 geprüften Varianten die Bestandsverfolgung deaktiviert und die Bestellfortsetzung erlaubt.
Damit war die Arbeit aber nicht erledigt. Eine zweite Prüfung zeigte zunächst nur 122 von 150 aktiven Produkten als veröffentlicht – sowohl im Online-Store-Kanal als auch im Headless-Kanal. Ein weiteres Blumat-Produkt habe ich anschließend in beiden Kanälen ergänzt. Für die übrigen Veröffentlichungen und vollständige Checkout-Tests gab es zu diesem Zeitpunkt noch keine abgeschlossene Bestätigung.
Mein wichtigstes Learning daraus: Produktstatus, Bestandsrichtlinie, Kanalveröffentlichung und tatsächliche Kaufbarkeit sind vier verschiedene Dinge. Ein grünes „Aktiv“ im Admin ersetzt keinen Test über Produktseite, Variante, Warenkorb und Checkout.
Warum prüfe ich die Vertriebskanäle separat?
Ein aktives Shopify-Produkt kann für einen bestimmten Vertriebskanal unveröffentlicht sein. Das gilt auch dann, wenn seine Varianten grundsätzlich weiterverkauft werden dürfen. Für Liquid und Headless muss ich deshalb die Veröffentlichung gezielt abgleichen.
Originaldaten statt schöner Demo-Inhalte
Bei den Herstellerseiten ist mir wichtig, dass die Oberfläche nicht auf Platzhaltern aufbaut. Ich möchte Originalbilder, echte Varianten, nachvollziehbare Preise, technische Merkmale und korrekte Lieferinformationen verwenden. Dazu gehören auch die jeweiligen Händlerkonditionen und die Klärung, welches Bild- und Textmaterial ich tatsächlich verwenden darf.
Das ist nicht nur eine redaktionelle Frage. Datenqualität beeinflusst Variantenwahl, Suchmaschinen-Snippets, interne Verlinkung und letztlich die Conversion. Eine noch so hochwertige Landingpage bringt wenig, wenn das passende Produkt am Ende nicht bestellbar ist.
Was bei der Deployment-Pipeline noch offen ist
Die Headless-Vorschau hat bereits Teile des Kaufablaufs gezeigt. Gleichzeitig gab es fehlgeschlagene Builds und einen Laufzeitfehler. Ein Deployment kann auf Plattformebene als bereit gelten und trotzdem auf einer wichtigen Route scheitern. Deshalb trenne ich künftig konsequent zwischen CI erfolgreich, Build erfolgreich, Route erreichbar, Produktdaten korrekt und Checkout tatsächlich nutzbar.
Ich werde den Live-Shop nicht auf eine neue Architektur umstellen, solange diese Kette nicht zuverlässig funktioniert. Die Headless-Storefront ist zum Stand dieses Artikels noch nicht als produktionsreif bestätigt.
Warum reicht ein erfolgreicher Vercel-Build nicht aus?
Ein Build bestätigt zunächst, dass das Projekt gebaut werden konnte. Fehler können erst bei einer Serveranfrage, beim Laden von Produktdaten oder beim Checkout-Übergang auftreten. Deshalb brauche ich zusätzlich Laufzeit- und Ende-zu-Ende-Tests.
SEO gehört für mich in die Architektur
Beim Wechsel von Shopify Liquid zu Headless Commerce geht es nicht nur um Komponenten und API-Abfragen. Ich möchte bestehende Produkt-Handles, relevante URLs und gewachsene Suchmaschinensignale möglichst erhalten. Dazu gehören Canonical-Tags, strukturierte Produktdaten, serverseitig erreichbare Inhalte, interne Verlinkung und gegebenenfalls saubere 301-Weiterleitungen.
Gerade bei spezialisierten Themen wie Substrat-Konfigurator, Pflanzenbeleuchtung und Hersteller-Landingpages ist organische Auffindbarkeit ein wichtiger Bestandteil des Konzepts. Deshalb prüfe ich die SEO-Auswirkungen nicht erst am Tag des Relaunches.
Mein Plan für den kontrollierten Switch
- Liquid absichern: Bestehende Produktseiten und Kaufprozesse bleiben verfügbar.
- Produktdaten vervollständigen: Freigegebene aktive Artikel, Varianten, Bilder und Vertriebskanäle prüfen.
- Design vereinheitlichen: Hersteller-Landingpages und Produktwelten nach denselben Qualitätsstandards aufbauen.
- Headless stabilisieren: Build- und Laufzeitfehler beheben, Vorschau verlässlich machen.
- Ende zu Ende testen: Mobile Darstellung, Warenkorb, Checkout, SEO und Weiterleitungen abnehmen.
- Kontrolliert umschalten: Erst nach erfolgreicher Prüfung die produktive Storefront wechseln – mit Rückfallmöglichkeit.
Was passiert mit dem Liquid-Shop während der Migration?
Er bleibt der produktive Verkaufskanal und wird weiter gepflegt. Neue freigegebene Produkte müssen nicht auf den Headless-Relaunch warten. Ein Wechsel erfolgt erst nach abgeschlossener technischer Abnahme.
Was ich als Nächstes dokumentiere
Im nächsten Live-Labs-Eintrag möchte ich tiefer in die Produktveröffentlichung einsteigen: Wie hängen Shopify-Produktstatus, Inventory Policy und Sales Channels zusammen? Wie prüfe ich, ob ein Produkt wirklich kaufbar ist? Und wie stelle ich sicher, dass Liquid und Headless dieselben Varianten anzeigen?
Danach geht es um die Headless-Pipeline, Hersteller-Landingpages und die Frage, wie sich ein anspruchsvolles Shop-Frontend weiterentwickeln lässt, ohne den laufenden Betrieb zu gefährden.
Mein Maßstab bleibt einfach: Neue Technik ist erst dann ein Fortschritt, wenn sie den Shop für Kunden besser macht – und der Verkauf währenddessen funktioniert.
Live Labs erscheint nach Möglichkeit etwa alle zwei Tage. Die Beiträge dokumentieren den jeweiligen Entwicklungsstand; offene Punkte bleiben ausdrücklich als offen gekennzeichnet.