Für eine Käuferin ist ein Shop keine Produktdatenbank und kein Verwaltungspanel. Er ist die Storefront - der Bildschirm, auf dem sie in wenigen Sekunden entscheidet, ob sie bleibt oder geht. Deshalb ist Headless Commerce, also die Trennung der Präsentationsschicht von der Verkaufs-Engine, kein Trend mehr, sondern der Weg, das Frontend schnell, flexibel und frei von den Grenzen eines Monolithen zu halten. Für E-Commerce-Leitung und CTO im Onlinehandel folgt daraus Einfaches: Über die Konversion entscheidet zunehmend eine Schicht, die Sie eigenständig entwickeln können.
Aus unserer Erfahrung liegt das Schwierige nicht in der Wahl einer Technologie, sondern darin, die Storefront im Griff zu behalten - schnell, zugänglich und stimmig - während Katalog, Traffic und Zahl der Kampagnen weiter wachsen. Deshalb behandeln wir die Entwicklung einer Online-Storefront als Produkt, das über Jahre gepflegt wird, und nicht als einmalige Einführung, und besetzen sie mit einem Team, das Frontend und die Realität des Handels kennt.
Was entscheidet in einem Onlineshop wirklich über die Konversion?
Über die Konversion entscheidet selten ein einzelnes „magisches” Element. Sie ist die Summe vieler kleiner technischer und produktbezogener Entscheidungen, die die Käuferin entweder zum Checkout führen oder unterwegs verlieren. In der Praxis wiegen am schwersten:
- die Zeit bis zur ersten Interaktion - je schneller die Seite reagiert, desto weniger Abbrüche,
- die Relevanz von Suche und Kategorien - die Kundin muss das Produkt finden, bevor sie aufgibt,
- ein reibungsloser Weg zu Warenkorb und Checkout - jeder zusätzliche Schritt ist verlorener Umsatz,
- Stimmigkeit auf dem Mobilgerät - wo heute der meiste Verkehr stattfindet.
Wir fügen das zu einem Ganzen zusammen, denn ein poliertes Erscheinungsbild hilft nicht, wenn das Frontend langsam lädt und die Suche zufällige Ergebnisse liefert.
Was heißt eine Headless-Storefront (SSR/SSG, Commerce-APIs) konkret?
In einem Headless-Aufbau ist die Storefront eine eigene Webanwendung, die über APIs mit der Commerce-Engine spricht, statt in einen Monolithen eingeklebt zu sein. Das erlaubt es, die Präsentationsschicht unabhängig vom Verkaufs-Backend zu ändern, zu beschleunigen und zu testen.
In dieser Schicht bauen wir meist:
- Server-side Rendering (SSR) dort, wo Datenaktualität und SEO zählen,
- statische und inkrementelle Generierung (SSG) für Seiten, die sich nicht bei jedem Besuch ändern,
- Integrationen über Commerce-APIs mit Shop-Engine, Zahlungen und den Systemen des Kunden,
- eine Caching- und CDN-Schicht, um das Backend zu entlasten und Antwortzeiten zu senken.
Dieses Fundament erlaubt es, Funktionen zu ergänzen, ohne alles neu zu schreiben, und die Verkaufs-Engine ohne Revolution im Frontend zu tauschen.
Wie bauen Sie Suche und Merchandising, die verkaufen?
Die Suche ist eine der ertragreichsten Stellen eines Shops - und eine der am meisten vernachlässigten. Wer eine Suchanfrage eintippt, hat klare Kaufabsicht, deshalb ist ein schwaches Ergebnis echter Umsatzverlust. Wir sorgen dafür, dass die Suche Tippfehler, Synonyme und Beugungsformen verträgt und Vorschläge liefert, die in wenigen Anschlägen zum Produkt führen.
Merchandising wiederum macht aus Ergebnissen und Listen ein Verkaufswerkzeug: Es erlaubt, Produkte nach Marge, Verfügbarkeit oder Aktion zu ordnen, das nach oben zu schieben, was Sie verkaufen wollen, und die Sichtbarkeit auf das Kundenverhalten zu personalisieren. Diese Logik stützen wir oft auf spezialisierte Such- und Personalisierungsplattformen (zum Beispiel Synerise), und unsere Engineers verdrahten sie so mit der Storefront, dass Relevanz und Tempo Hand in Hand gehen.
Welche Werkzeuge für Kategorie- und Landingpages braucht das Marketing?
Eine Storefront, in der jede Änderung eine Entwicklerin braucht, bremst den Verkauf. Deshalb sorgen wir dafür, dass Marketing und Merchandising Kategorie- und Landingpages selbst zusammenbauen können, ohne Deployment. In der Praxis geben wir ihnen:
- editierbare Blöcke und Abschnitte, um eine Seite wie mit Bausteinen zu bauen,
- Banner, Kampagnen und Inhalte, angebunden an ein Content-Management-System,
- Sortier- und Filterregeln für Kategorien, ohne Code änderbar,
- Vorschau und Veröffentlichung ohne Beteiligung des technischen Teams.
So geht eine Kampagne live, wenn sie soll, und nicht im nächsten Deployment-Fenster.
Wie gehen Sie mit Mobile und einer möglichen App um?
Der meiste Verkehr findet heute mobil statt, und dort zeigen sich die Kosten eines langsamen Frontends zuerst. Wir entwerfen die Storefront mobile first und achten darauf, dass Produktseite und Checkout auf einem durchschnittlichen Telefon und bei schwacher Verbindung flüssig laufen, nicht nur auf Testgeräten. Das genügt meist, um den größten Teil des Verkaufs zu sichern.
Eine native App ist eine eigene Frage. Sie ergibt dort Sinn, wo Loyalität, Wiederbesuche und Push-Nachrichten zählen, und nicht jeder Shop braucht eine. Deshalb helfen wir zuerst zu entscheiden, ob sich die Investition in eine App rechnet, bevor wir mit dem Bau beginnen - und wenn ja, setzen wir sie auf dieselbe API-Schicht wie die Storefront, um nicht zwei getrennte Welten pflegen zu müssen.
Wie behalten Sie Performance und Core Web Vitals im Griff?
Tempo ist keine Kosmetik, es ist ein direkter Treiber von Konversion und Suchranking. Wir behandeln Core Web Vitals als hartes Qualitätskriterium und beobachten sie über den gesamten Lebenszyklus des Shops, nicht nur beim Start. In der Praxis konzentrieren wir uns auf:
- LCP - die Ladezeit des Hauptinhalts, besonders in Listen und auf der Produktseite,
- INP - wie flink die Seite auf Klicks und Interaktionen reagiert,
- CLS - die Stabilität des Layouts, damit nichts unter dem Finger „springt”,
- ein Performance-Budget, das bei jeder Änderung automatisch durchgesetzt wird.
Wir automatisieren die Messung in der Pipeline, sodass eine Performance-Regression auffällt, bevor sie die Produktion erreicht, und nicht erst später in einem Umsatzrückgang.
Warum ist Barrierefreiheit der Storefront mehr als ein Häkchen bei der Konformität?
Barrierefreiheit (WCAG) wird oft als rechtliche Pflicht behandelt, ist aber vor allem eine größere Kundenbasis und bessere Nutzbarkeit für alle. Ein Shop, der mit Tastatur, Screenreader und schwachem Sehvermögen funktioniert, ist schlicht verständlicher - auch für jemanden, der es auf dem Telefon eilig hat. Wir bauen die Storefront von Anfang an mit korrekter Semantik, Kontrast und Tastaturunterstützung, denn Barrierefreiheit am Ende anzuschrauben kostet ein Vielfaches. Zudem wird sie im Onlinehandel zunehmend formale Anforderung, es lohnt sich also, sie zu klären, bevor sie dringend wird.
Welche Kompetenzen stellen wir für ein Storefront-Projekt bereit?
Wir stellen das Team passend zur konkreten Arbeit zusammen, nicht „auf Vorrat”. In Storefront-Projekten besetzen wir meist:
- Frontend-Entwickler (React/Next.js), die Präsentationsschicht und Performance bauen,
- Integrations- und Backend-Engineers, die Commerce-APIs, Zahlungen und die Systeme des Kunden verdrahten,
- Spezialisten für Suche und Merchandising, auch auf Plattformen wie Synerise,
- DevOps, die CDN, Caching, Pipeline und Monitoring verantworten.
Auch wenn wir genau Ihr Shop-Modell nicht gebaut haben, stellen wir Menschen, die das täglich tun - als Team-Verstärkung oder dediziertes Team, unter Ihrer Führung oder mit unserem Tech Lead.
Wie machen wir das bei RITS?
Wir machen das als Nearshore-Partner aus Polen, mit Erfahrung in der Entwicklung von Webanwendungen und in Produktprojekten:
- wir entwerfen die Storefront als eigene, schnelle Headless-Schicht, unabhängig von der Verkaufs-Engine,
- wir verbinden Suche, Merchandising und Inhalte, sodass das Marketing ohne Deployment-Warteschlange arbeitet,
- wir sichern Performance und Barrierefreiheit automatisch in der Pipeline und nicht erst nach einem Vorfall,
- wir prüfen die Kompetenzen vor dem Start, und als Partner aus Polen arbeiten wir in einer nahen Zeitzone, sodass das Team ohne lange Anlaufzeit in Ihren Rhythmus kommt.
Meist machen wir das als Individualsoftware, gebaut von unserem Team, und dort, wo Frontend-Kompetenzen schnell aufgestockt werden müssen, als Team-Verstärkung.
Womit fangen Sie bei einer Headless-Storefront an?
Starten Sie mit dem wichtigsten Kaufweg (zum Beispiel von der Suche über die Produktseite bis zum Checkout) und messen Sie, wo Sie heute Warenkörbe verlieren. Das zeigt, ob das Problem Tempo, Suchrelevanz oder der Checkout-Weg selbst ist - und es bestimmt den Umfang der ersten Phase. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen oder beschleunigen eine Headless-Storefront? Sprechen wir darüber - wir stellen Team und Architektur passend zu Ihrem Shop zusammen.