Braucht commercetools ein CMS? Content-Layer erklärt
- 1.Was "CMS" in diesem Kontext eigentlich bedeutet
- 2.Was commercetools von Haus aus liefert, und was nicht
- 3.Option 1: Headless CMS wie Storyblok oder Contentful
- 4.Option 2: Frontend-/Experience-Layer statt CMS
- 5.Wo Content, Präsentation und Komposition wirklich leben
- 6.Wo Laioutr passt
- 7.Entscheidungs-Framework für dein Team
Nein, commercetools hat kein natives CMS und keinen eigenen Experience-Layer eingebaut. commercetools ist ein Headless-Commerce-Backend für Katalog, Warenkorb, Checkout und Order-Management, API-first, ohne ausgeliefertes Frontend. Was fehlt, musst du dazuholen: entweder ein Headless-CMS wie Storyblok oder Contentful für Marketing-Content, oder einen eigenständigen Frontend-/Experience-Layer, der Content, Produkte und Präsentation zusammenführt. Beide Wege lösen unterschiedliche Probleme, und die meisten Teams unterschätzen, wie viel Lücke dazwischen liegt.
Was "CMS" in diesem Kontext eigentlich bedeutet
Der Begriff CMS wird in Composable-Commerce-Gesprächen zu oft als Sammelbegriff benutzt. Es lohnt sich, drei Ebenen sauber zu trennen:
- Produkt-Content lebt im Commerce-Backend selbst: SKUs, Preise, Varianten, Kategorien, Lagerbestand. commercetools verwaltet das über seine API und das Merchant Center.
- Marketing-Content ist redaktionell: Kampagnenseiten, Blog-Artikel, Landingpages, Editorial-Blöcke, mehrsprachige Übersetzungen. Dafür ist commercetools nicht gebaut, und es beansprucht das auch nicht.
- Präsentation und Komposition ist die Ebene, auf der Produkt-Content und Marketing-Content zusammenlaufen und als Seite ausgeliefert werden: Layout, Komponenten, Personalisierung, Performance.
commercetools deckt zuverlässig die erste Ebene ab. Für die zweite und dritte Ebene brauchst du zusätzliche Software, und genau da beginnt die Verwirrung, weil zwei sehr unterschiedliche Kategorien von Tools als Lösung infrage kommen.
Was commercetools von Haus aus liefert, und was nicht
commercetools ist bewusst komplett headless: kein Default-Frontend, kein eingebauter Page-Builder für Marketing-Content, keine Editorial-Workflows für redaktionelle Inhalte. Was es liefert, ist eine saubere GraphQL- und REST-API über Produktdaten, Bestellungen und Kunden, plus das Merchant Center als Admin-Oberfläche für Commerce-Operationen.
Für Teams, die keinen eigenen Frontend-Stack bauen wollen, bietet commercetools zusätzlich commercetools Frontend (vormals Frontastic, seit 2021 zur Suite gehörig) an. Das ist wichtig für die Einordnung: commercetools Frontend ist kein CMS, sondern ein Frontend-as-a-Service-Produkt mit einem Business-User-Layer (Frontend Studio) für Page-Komposition und einem Code-Layer für Developer auf Next.js-Basis. Es löst die Präsentations-Ebene, eng an commercetools als Backend gebunden. Ein separates Content-Repository für redaktionelle Inhalte bringt es nicht mit.
Option 1: Headless CMS wie Storyblok oder Contentful
Ein Headless-CMS ist die richtige Wahl, wenn dein Content-Bedarf über Produktbeschreibungen hinausgeht: Magazin-artige Seiten, Kampagnen mit vielen Sprachvarianten, redaktionelle Freigabe-Workflows, wiederverwendbare Content-Blöcke über mehrere Kanäle hinweg. Storyblok bringt dafür eine ausgereifte Content-API und einen visuellen Editor für Content-Blöcke mit, Contentful einen etablierten Enterprise-Content-Layer mit granularen Rollen. Beide sind ausschließlich CMS: Sie liefern strukturierten Content über eine API aus, aber keine Frontend-Runtime. Du brauchst zusätzlich ein Frontend, das diesen Content abholt, mit den commercetools-Produktdaten zusammenführt und als performante Seite ausliefert.
Das Ergebnis, wenn du diesen Weg gehst: commercetools für Commerce-Daten, ein Headless-CMS für Marketing-Content, und ein selbst gebautes oder eingekauftes Frontend, das beide APIs konsumiert. Drei Systeme, drei Integrationen, ein Custom-Glue-Aufwand, den dein Team dauerhaft pflegt.
Option 2: Frontend-/Experience-Layer statt CMS
Die zweite Option verzichtet auf ein separates CMS und legt stattdessen einen Frontend Management Platform-Layer (FMP) direkt über commercetools. Ein FMP wie Laioutr übernimmt die Präsentations-Ebene: Produktdaten kommen über GraphQL aus commercetools, Marketing-Content und Seiten-Komposition passieren im Studio-Editor, direkt in der Live-Storefront. Für viele Marketing-Teams reicht das, weil der eigentliche Bedarf nicht "ein weiteres Content-Repository" ist, sondern die Fähigkeit, Landingpages, Kampagnenseiten und Produktwelten selbst zu bauen, ohne jedes Mal ein Engineering-Ticket zu öffnen.
Das ist ein wichtiger Unterschied zu commercetools Frontend: Ein FMP wie Laioutr ist backend-agnostisch gebaut. Wenn dein Stack heute commercetools ist und in drei Jahren nicht mehr, bleibt der Frontend-Layer bestehen, weil er nicht strukturell an ein einzelnes Backend gebunden ist.
Wo Content, Präsentation und Komposition wirklich leben
Wenn du dich fragst, welchen Weg dein Team braucht, hilft die konkrete Frage: Wo soll dein Marketing-Team tatsächlich arbeiten?
- Wenn die Antwort "in einem Content-Editor, mit Freigabe-Workflows, für viele Kanäle gleichzeitig" lautet, brauchst du ein Headless-CMS zusätzlich zum Frontend.
- Wenn die Antwort "direkt auf der Storefront, um Seiten und Kampagnen selbst zu komponieren" lautet, reicht ein FMP als Presentation-Layer oft aus, ganz ohne separates CMS.
- Wenn beides zutrifft, zum Beispiel ein Magazin-Bereich mit redaktionellem Workflow plus schnelle Commerce-Landingpages, ist die Kombination aus Headless-CMS und FMP der pragmatischste Weg: Storyblok oder Contentful für den redaktionellen Content, das FMP als Frontend, das sowohl CMS-Content als auch commercetools-Produktdaten in derselben Seite zusammenführt.
Diese Kombination ist keine Notlösung, sondern ein etabliertes Muster: Das CMS bleibt Content-Backend, das FMP übernimmt Composition, Performance und Multi-Backend-Anbindung.
Wo Laioutr passt
Laioutr ersetzt kein Headless-CMS und will das auch nicht. Wenn du bereits Storyblok oder Contentful im Einsatz hast, koppelt sich Laioutr als Frontend-Layer an beide Quellen: die CMS-Content-API und die commercetools-GraphQL-API, und liefert daraus eine gemeinsame, performante Storefront. Wenn du gar kein separates CMS brauchst, weil dein Content-Bedarf im Wesentlichen aus Kampagnenseiten, Produktwelten und Landingpages besteht, deckt der Studio-Editor von Laioutr die Presentation-Ebene direkt ab, ohne dass du ein drittes System betreiben musst.
Der praktische Unterschied zu commercetools Frontend: Laioutr ist nicht an commercetools als Backend gebunden. Solltest du dein Backend später wechseln, etwa zu Shopware, Shopify oder Adobe Commerce, bleibt der Frontend-Layer bestehen. Composable-Commerce-Versprechen bedeutet für uns, dass diese Wahl reversibel bleibt, auch auf der Frontend-Seite.
Entscheidungs-Framework für dein Team
Bevor du dich für CMS, FMP oder beides entscheidest, lohnt sich eine kurze Bestandsaufnahme:
- Wie viel redaktioneller Content entsteht pro Woche, und wer schreibt ihn?
- Braucht ihr Freigabe-Workflows über mehrere Rollen und Sprachen?
- Wie oft ändert Marketing Landingpages oder Kampagnenseiten, und wie lange dauert das aktuell?
- Ist euer commercetools-Setup langfristig gesetzt, oder soll die Backend-Wahl offen bleiben?
Die Antworten zeigen meistens klar, ob ihr ein Headless-CMS, einen Frontend-Layer, oder beides braucht. Es gibt hier keine falsche Antwort, nur die passende für euren Content-Bedarf.
Wenn ihr commercetools im Backend habt und noch nicht entschieden habt, wie Marketing selbstständig Seiten bauen soll, ist das der richtige Zeitpunkt, den Composable Headless Frontend genauer anzusehen. Für die commercetools-spezifische Anbindung lohnt sich ein Blick auf unsere Headless-Frontend-Landingpage für commercetools, für die Content-Management-Fähigkeiten im Studio auf die Content-Management-Produktseite. Wenn Storyblok bereits Teil eures Stacks ist, zeigt die Page-Builder-Seite für Storyblok, wie Laioutr als Frontend darüber sitzt, ohne Storyblok zu ersetzen.
Mehr zum Zusammenspiel von FaaS-Modell und Headless-CMS findest du in unserem Artikel FaaS vs. Headless CMS: Warum ein CMS allein noch kein Frontend ist, sowie in unserer Analyse zu commercetools' Standalone-Modulen und was das für eure Frontend-Entscheidung bedeutet.