Headless Frontend für plentymarkets: Wie die Entkopplung funktioniert

Euer plentyShop LTS wird nicht mehr weiterentwickelt. Das Frontend hat ein Ablaufdatum. Die Frage ist nicht ob ihr wechselt, sondern wie.

Unser Artikel zur plentymarkets-LTS-Abschaltung hat vier Migrationspfade vorgestellt. Einer davon war: Headless Frontend vor plentymarkets setzen. Also das alte Ceres-Frontend austauschen, plentymarkets als Backend behalten und beides über die REST API verbinden.

Dieser Artikel geht genau dort in die Tiefe. Nicht auf Code-Ebene, sondern auf der Ebene, auf der Geschäftsführer und E-Commerce-Leads Entscheidungen treffen: Was passiert bei einer Entkopplung konkret? Was ändert sich im Tagesgeschäft? Was kostet das? Und für wen ist headless commerce die richtige Architekturentscheidung?

Was ist ein Headless Frontend?

Die einfachste Erklärung: Stellt euch ein Restaurant vor.

Die Küche ist euer plentymarkets-Backend. Dort werden Bestellungen verarbeitet, Lagerbestände verwaltet, Rechnungen erstellt, Retouren abgewickelt. Die gesamte operative Logik eures E-Commerce-Geschäfts läuft dort.

Der Gastraum ist euer Frontend. Das, was eure Kunden sehen: Produktseiten, Kategorie-Navigation, Warenkorb, Checkout. Die gesamte Einkaufserfahrung.

In einem klassischen Setup (wie plentyShop LTS) sind Küche und Gastraum fest verbunden. Selbes Gebäude, selbe Wände, selbe Einschränkungen. Wenn die Küche ein Update bekommt, muss der Gastraum mitspielen. Wenn der Gastraum modernisiert werden soll, sind die Möglichkeiten durch die Küche begrenzt.

Headless bedeutet: Ihr trennt beides. Die Küche bleibt, wo sie ist. Der Gastraum wird unabhängig. Und dazwischen steht der Kellner, also die API. Der Kellner nimmt die Bestellung im Gastraum entgegen, trägt sie in die Küche und bringt das fertige Gericht zurück.

In technischer Sprache: Das Frontend kommuniziert über eine Programmierschnittstelle (REST API) mit dem Backend. Beide Systeme sind entkoppelt. Das Frontend kann ausgetauscht, redesignt oder komplett neu gebaut werden, ohne dass in plentymarkets irgendetwas verändert werden muss.

Das klingt nach einer kleinen Architekturänderung. In der Praxis verändert es, wie euer Shop entwickelt, betrieben und weiterentwickelt wird.

Wie die Entkopplung technisch funktioniert

Keine Sorge, das wird kein Entwickler-Tutorial. Aber ihr solltet verstehen, worüber eure Agentur oder euer Dev-Team redet, wenn es um die Anbindung geht.

Die plentymarkets REST API

plentymarkets stellt eine REST API bereit. Das ist die Schnittstelle, über die externe Systeme mit plentymarkets kommunizieren können. Die API folgt dem OpenAPI-2.0-Standard und nutzt OAuth 2.0 für die Authentifizierung. Daten werden im JSON-Format ausgetauscht.

Konkret heißt das: Euer neues Frontend kann über die API auf alles zugreifen, was eure Kunden im Shop brauchen:

Der Datenfluss in der Praxis

So läuft eine typische Kundeninteraktion in einem headless Setup ab:

1. Kunde öffnet Produktseite. Das Frontend fragt die API: "Gib mir alle Daten zu Produkt X." Die API liefert Name, Preis, Verfügbarkeit, Bilder und Varianten.

2. Kunde legt Artikel in den Warenkorb. Das Frontend schickt eine Anfrage an den Basket-Endpunkt. plentymarkets erstellt einen Warenkorb und bestätigt.

3. Kunde geht zum Checkout. Das Frontend ruft Versandoptionen und Zahlungsarten über die API ab. Der Kunde wählt, das Frontend übermittelt die Auswahl.

4. Bestellung wird ausgelöst. Das Frontend schickt die finale Bestellung an die Orders-API. Ab hier übernimmt plentymarkets: Zahlungsabwicklung, Lagerbuchung, Fulfillment, Marktplatz-Synchronisierung.

Der entscheidende Punkt: plentymarkets bleibt euer ERP und eure Warenwirtschaft. Alles, was hinter dem "Kaufen"-Button passiert, läuft weiterhin dort. Das Frontend ist nur die Oberfläche.

Wo die API an Grenzen stößt

Die plentymarkets REST API ist funktional, aber sie wurde nicht für High-Performance-Headless-Szenarien gebaut. Es gibt reale Einschränkungen, die ihr kennen solltet:

Ratenlimits. Die API begrenzt die Anzahl der Anfragen pro Zeiteinheit. Bei einem Shop mit hohem Traffic oder vielen gleichzeitigen Nutzern kann das zu Engpässen führen.

Latenz. Jede Seite im Frontend braucht mehrere API-Aufrufe (Produktdaten, Preise, Verfügbarkeit, Warenkorb-Status). Wenn jeder Aufruf 200-400ms dauert, summiert sich das. Ohne Caching-Strategie spüren eure Kunden das.

Fehlende Endpunkte. Nicht jede Funktion, die im alten plentyShop LTS nativ verfügbar war, hat ein entsprechendes API-Pendant. Manche Features müssen über Workarounds oder zusätzliche Middleware abgebildet werden.

Das sind keine Showstopper. Aber es sind Faktoren, die den Implementierungsaufwand beeinflussen. Eine erfahrene Agentur plant dafür von Anfang an.

Was sich operativ ändert (und was nicht)

Die größte Unsicherheit bei einem Headless-Umbau ist nicht die Technik. Es ist die Frage: Was bedeutet das für unser Tagesgeschäft? Was müssen wir anders machen?

Was sich ändert

Content-Pflege wird flexibler, aber anders. Im alten plentyShop LTS habt ihr Inhalte direkt in plentymarkets gepflegt. In einem headless Setup liegt der Content oft im Frontend-System oder in einem separaten Headless CMS. Das heißt: Landingpages, Banner, Aktionsseiten werden nicht mehr in plentymarkets bearbeitet, sondern in einem eigenen Tool. Mehr Gestaltungsfreiheit, aber ein zusätzliches System im Stack.

Deployment-Prozesse ändern sich. Änderungen am Frontend (neue Landingpage, Design-Anpassung, A/B-Test) werden unabhängig vom Backend deployed. Das ist ein Vorteil: Ihr könnt schneller iterieren, ohne Risiko für eure Warenwirtschaft. Aber es erfordert einen Deployment-Prozess, den viele plentymarkets-Händler bisher nicht hatten.

Team-Anforderungen verschieben sich. Das alte Ceres-Template konnte mit Plugin-Installationen und etwas Template-Anpassung verwaltet werden. Ein headless Frontend braucht Frontend-Entwickler oder eine Agentur, die das System wartet und weiterentwickelt. Das ist ein laufender Posten, kein einmaliges Projekt.

Monitoring wird wichtiger. Wenn zwei Systeme über eine API kommunizieren, müsst ihr überwachen, ob die Kommunikation funktioniert. API-Fehler, Timeout-Probleme oder Synchronisierungslücken fallen nicht von allein auf. Ihr braucht ein Monitoring, das euch warnt, bevor eure Kunden es merken. Was nach dem Go-live alles schiefgehen kann und wie ihr euch darauf vorbereitet, zeigt unser Artikel Warum E-Commerce-Projekte nach dem Go-live scheitern.

Was gleich bleibt

Bestellabwicklung. Orders kommen weiterhin in plentymarkets an. Eure Prozesse für Fulfillment, Versand, Retouren und Rechnungsstellung bleiben identisch.

Lagerverwaltung. Bestände werden weiterhin in plentymarkets gepflegt. Das Frontend liest die aktuellen Bestände über die API, aber die Quelle bleibt plentymarkets.

Marktplatz-Anbindungen. Eure Listings auf Amazon, eBay, Otto oder Kaufland laufen weiterhin über plentymarkets. Der Frontend-Wechsel betrifft nur euren eigenen Shop.

Buchhaltung und Reporting. Finanzströme, DATEV-Export, Statistiken: alles bleibt in plentymarkets. Das Frontend erzeugt keine eigenen Finanzdaten.

ERP-Logik. Preisregeln, Kundengruppen, Staffelpreise, Rabattaktionen: all das wird weiterhin in plentymarkets konfiguriert und über die API ans Frontend ausgespielt.

Kurz: Alles, was eure Kunden nicht sehen, bleibt wie es ist. Alles, was eure Kunden sehen, wird neu.

Die Frontend-Optionen im Überblick

Wenn ihr euch für den headless Weg entschieden habt, stellt sich die nächste Frage: Welches Frontend-System? Hier sind die vier relevanten Optionen für plentymarkets-Händler.

plentyShop PWA (Nuxt 4 + Alokai)

Der offizielle Nachfolger von plentyShop LTS. Eine Progressive Web App basierend auf Nuxt 4 und dem Alokai-Framework (ehemals Vue Storefront). Dieses Frontend wird von plentysystems aktiv entwickelt und ist die empfohlene Migrationsoption für Händler, die im plentymarkets-Ökosystem bleiben wollen.

Vorteil: Tiefste Integration mit plentymarkets, offizielle Connectors, Support durch plentysystems. Nachteil: Abhängigkeit vom plentymarkets-Ökosystem, das insgesamt an Dynamik verliert. Eingeschränkte Flexibilität im Vergleich zu unabhängigen Lösungen.

Alokai / Vue Storefront (unabhängig)

Alokai (das Framework hinter plentyShop PWA) kann auch unabhängig von plentysystems eingesetzt werden. Das gibt euch mehr Freiheit bei der Anpassung und weniger Abhängigkeit von der offiziellen plentymarkets-Roadmap.

Vorteil: Bewährtes Framework, große Community, flexibler als die offizielle plentyShop-Variante. Nachteil: Kein offizieller plentysystems-Support, Connector muss selbst gewartet werden.

Next.js / React (Custom Build)

Der maximale Freiheitsgrad. Ihr baut euer Frontend komplett selbst mit React und Next.js. Es gibt keinen offiziellen plentymarkets-Connector, also wird die Integration komplett custom entwickelt.

Vorteil: Totale Freiheit bei Design, Performance-Optimierung und Feature-Entwicklung. Riesiges Entwickler-Ökosystem. Nachteil: Höchster Initialaufwand, kein vorgefertigter Connector, alles muss selbst gebaut und gewartet werden.

Laioutr (Managed Frontend)

Laioutr ist ein managed Frontend-as-a-Service mit visuellem Page Builder. Es arbeitet über eine eigene Orchestr-Schicht, die als Middleware zwischen Frontend und Backend fungiert. Das macht es backend-agnostisch: plentymarkets, Shopware, Shopify oder ein anderes System kann als Datenquelle angebunden werden.

Vorteil: Visueller Page Builder reduziert die Abhängigkeit von Entwicklern massiv. Managed Hosting und Wartung inklusive. Schnellster Time-to-Market unter den Headless-Optionen. Nachteil: Weniger Kontrolle als bei einem Custom Build. Abhängigkeit von einem weiteren Anbieter.

Mehr zu den einzelnen Optionen und wann welche passt, findet ihr in unserem Vergleich der vier Migrationspfade.

Performance: Zahlen statt Versprechen

"Headless ist schneller" sagt jede Agentur. Aber wie viel schneller? Und woran messen wir das?

Die Core Web Vitals sind Googles Standard für Ladeperformance und Nutzererfahrung. Sie beeinflussen direkt euer Google-Ranking und eure Conversion Rate. Hier die realistischen Verbesserungen, die ein headless Frontend gegenüber einem klassischen Ceres-Template bringen kann:

Diese Zahlen sind keine Garantien, sondern Erfahrungswerte aus headless Migrationen im E-Commerce. Der konkrete Effekt hängt von eurem Ausgangszustand ab: Wer von einem stark überladenen Ceres-Template mit 15 Plugins kommt, sieht größere Verbesserungen als jemand mit einem schlanken Setup.

Warum headless Frontends schneller sind:

Moderne Frameworks wie Nuxt oder Next.js nutzen Server-Side Rendering (SSR) oder Static Site Generation (SSG). Das bedeutet: Die Seiten werden auf dem Server vorgerendert und als fertiges HTML ausgeliefert. Der Browser eures Kunden muss nicht erst warten, bis JavaScript geladen und ausgeführt wird.

Dazu kommt Edge Deployment: Eure Seiten werden auf Servern weltweit gecacht und von dem Standort ausgeliefert, der eurem Kunden am nächsten ist. Das drückt die TTFB auf ein Minimum.

Das alte Ceres-Template kann das nicht. Es läuft auf den plentymarkets-Servern, wird bei jedem Aufruf dynamisch gerendert und hat keine Edge-Infrastruktur.

Was kostet ein Headless Frontend wirklich?

Kosten sind der Punkt, an dem viele Headless-Gespräche enden. Zu Recht, denn die Spanne ist groß und hängt von eurer Ausgangslage und eurem Anspruch ab.

Initialkosten

Ein Custom Build mit Next.js liegt typischerweise bei einem 30-60% Premium gegenüber einer klassischen Theme-Anpassung. Das ist der Preis für die Freiheit. Die Frage ist, ob euer Business Case diesen Aufpreis rechtfertigt.

Laufende Kosten

Das vergessen viele beim Kostenvergleich: Ein headless Frontend ist kein einmaliges Projekt. Es verursacht laufende Kosten, die beim alten Ceres-Template nicht angefallen sind.

Hosting. Euer Frontend braucht eigenes Hosting (Vercel, Netlify, AWS oder ein anderer Anbieter). Rechnet mit 50-500 EUR pro Monat, abhängig von eurem Traffic.

Wartung und Updates. Framework-Updates, Sicherheitspatches, Dependency-Management. Entweder habt ihr intern jemanden, der das übernimmt, oder eure Agentur rechnet 5-15 Stunden pro Monat ab.

Weiterentwicklung. Neue Features, Landingpages, A/B-Tests, Design-Iterationen. Der Vorteil von headless ist, dass ihr schneller iterieren könnt. Aber das kostet Entwicklerzeit.

Wann Laioutr die Rechnung verändert

Laioutr ist als managed Lösung interessant, weil es den größten Kostenblock reduziert: die Abhängigkeit von Entwicklern. Der visuelle Page Builder erlaubt eurem Marketing-Team, Landingpages und Content-Änderungen selbst umzusetzen. Das senkt die laufenden Kosten erheblich, besonders für Händler ohne eigenes Dev-Team.

Wann Headless sich NICHT rechnet

Ehrlichkeit ist wichtig: Headless ist nicht für jeden die richtige Wahl. Ein Artikel über technische Schulden hilft euch bei der Einschätzung, ob euer aktuelles Setup wirklich am Limit ist.

Wenn euer Jahresumsatz unter 500.000 EUR liegt, übersteigen die Kosten für ein headless Frontend wahrscheinlich den Nutzen. Die offizielle plentyShop PWA oder ein Plattformwechsel zu Shopware oder Shopify ist in dem Fall wirtschaftlicher.

Wenn eure größte Herausforderung nicht das Frontend ist, sondern fehlende Prozesse, schlechte Datenqualität oder ein unklares Sortiment, löst ein neues Frontend eure Probleme nicht. Es macht sie nur schöner sichtbar.

Wenn ihr kein Team habt, das damit arbeiten kann, und auch keine Agentur langfristig beauftragen wollt, wird ein Custom Headless Frontend zur Baustelle, die nie fertig wird.

Für wen lohnt sich Headless und für wen nicht?

Statt einer Pauschalantwort: Hier sind die Entscheidungskriterien, die wir in unseren Beratungsgesprächen durchgehen.

Die ehrliche Zusammenfassung: Headless commerce lohnt sich für Händler, deren eigener Shop ein strategischer Kanal ist und die bereit sind, in dessen Weiterentwicklung zu investieren. Für alle anderen gibt es einfachere, günstigere Wege, das LTS-Problem zu lösen.

FAQ: Häufige Fragen zum Headless Frontend

Was ist ein Headless Frontend und wie funktioniert es?

Ein headless Frontend ist eine Shop-Oberfläche, die komplett vom Backend (in diesem Fall plentymarkets) getrennt ist. Die Kommunikation läuft über eine REST API. Das Frontend zeigt Produkte, nimmt Bestellungen entgegen und leitet sie an plentymarkets weiter. Alle Backend-Prozesse (Lagerverwaltung, Fulfillment, Buchhaltung) laufen unverändert in plentymarkets.

Welche Vorteile bringt Headless Commerce?

Die drei wichtigsten: Performance (schnellere Ladezeiten durch SSR und Edge Deployment), Flexibilität (Frontend kann unabhängig vom Backend weiterentwickelt werden) und Zukunftssicherheit (ihr seid nicht mehr an die Frontend-Roadmap von plentymarkets gebunden). Dazu kommt die Möglichkeit, mehrere Frontends parallel zu betreiben (Web, App, POS) mit einem einzigen Backend.

Was passiert mit plentyShop LTS?

plentysystems hat die Weiterentwicklung von plentyShop LTS (Ceres) eingestellt. Es gibt keine Feature-Updates, keine Sicherheitspatches und keine Kompatibilitätsgarantie mehr. Es gibt kein hartes Abschaltdatum, aber das System veraltet schrittweise. Mehr dazu in der offiziellen FAQ von plentysystems.

Was kostet die Umstellung auf ein Headless Frontend?

Die Spanne reicht von 5.000 EUR (managed Lösung wie Laioutr) bis 80.000 EUR (Custom Build mit Next.js). Der offizielle Migrationspfad über plentyShop PWA liegt bei 10.000-25.000 EUR. Dazu kommen laufende Kosten für Hosting (50-500 EUR/Monat) und Wartung (5-15 Entwicklerstunden/Monat).

Wie lange dauert die Implementierung?

Abhängig von der gewählten Lösung: 2-4 Wochen für eine managed Lösung, 4-8 Wochen für die offizielle plentyShop PWA, 8-16 Wochen für einen Custom Build. Bei einer spezialisierten E-Commerce-Agentur liegt die typische Timeline für ein mittleres Projekt bei etwa 3 Monaten.

Verbessert Headless meine Core Web Vitals?

Ja, deutlich. Moderne headless Frontends erreichen typischerweise Lighthouse Scores von 90+, verglichen mit 60-75 beim alten Ceres-Template. LCP verbessert sich um 0,6-1,2 Sekunden, TTFB um 65-85%. Das hat direkte Auswirkungen auf euer Google-Ranking und eure Conversion Rate.

Brauche ich ein eigenes Entwicklerteam?

Nicht zwingend. Managed Lösungen wie Laioutr reduzieren die Entwicklerabhängigkeit erheblich. Für Custom Builds braucht ihr entweder ein internes Team oder eine Agentur, die das Frontend langfristig betreut. Die offizielle plentyShop PWA liegt dazwischen: weniger Individualisierung, aber auch weniger laufender Entwickleraufwand.

Nächster Schritt

Ihr wisst jetzt, wie headless commerce funktioniert, was es kostet und für wen es sich lohnt. Die Frage, die bleibt: Welcher Weg passt zu eurem konkreten Setup?

Das lässt sich nicht pauschal beantworten, denn es hängt von eurem Umsatz, eurem Team, eurer Sortimentsstruktur und euren Wachstumsplänen ab. Was wir tun können: In einem kurzen Gespräch eure Situation einordnen und euch eine ehrliche Einschätzung geben, ob headless für euch der richtige Weg ist oder ob eine einfachere Lösung ausreicht.

Sprecht uns an. Keine Verkaufspräsentation, sondern ein Gespräch auf Augenhöhe.