Does commercetools Need a CMS? The Content Layer Explained

No, commercetools does not include a native CMS or a built-in experience layer. commercetools is a headless commerce backend for catalog, cart, checkout, and order management, API-first, with no frontend shipped by default. What is missing you have to add yourself: either a headless CMS such as Storyblok or Contentful for marketing content, or a dedicated frontend/experience layer that brings content, products, and presentation together. Both paths solve different problems, and most teams underestimate how much gap sits between them.

What "CMS" actually means in this context

In composable-commerce conversations, "CMS" gets used as a catch-all far too often. It helps to separate three distinct layers:

• Product content lives inside the commerce backend itself: SKUs, prices, variants, categories, inventory. commercetools manages this through its API and the Merchant Center.
• Marketing content is editorial: campaign pages, blog articles, landing pages, editorial blocks, multi-language translations. commercetools is not built for this, and it does not claim to be.
• Presentation and composition is the layer where product content and marketing content come together and get shipped as a page: layout, components, personalization, performance.

commercetools reliably covers the first layer. For the second and third, you need additional software, and that is exactly where the confusion starts, because two very different categories of tools present themselves as the answer.

What commercetools ships out of the box, and what it does not

commercetools is deliberately fully headless: no default frontend, no built-in page builder for marketing content, no editorial workflows for editorial material. What it does ship is a clean GraphQL and REST API over product data, orders, and customers, plus the Merchant Center as an admin surface for commerce operations.

For teams that do not want to build their own frontend stack, commercetools also offers commercetools Frontend (formerly Frontastic, part of the suite since the 2021 acquisition). This matters for the framing: commercetools Frontend is not a CMS, it is a Frontend-as-a-Service product with a business-user layer (Frontend Studio) for page composition and a developer code layer built on Next.js. It solves the presentation layer, tightly coupled to commercetools as the backend. It does not bring a separate content repository for editorial material.

Option 1: A headless CMS like Storyblok or Contentful

A headless CMS is the right call when your content needs go beyond product descriptions: magazine-style pages, campaigns with many locale variants, editorial approval workflows, reusable content blocks across multiple channels. Storyblok brings a mature content API and a visual editor for content blocks; Contentful brings an established enterprise content layer with granular roles. Both are CMS-only: they deliver structured content through an API, but no frontend runtime. You still need a frontend that fetches that content, merges it with commercetools product data, and ships it as a performant page.

The result if you take this path: commercetools for commerce data, a headless CMS for marketing content, and a custom-built or purchased frontend that consumes both APIs. Three systems, three integrations, and custom glue code your team maintains indefinitely.

Option 2: A frontend/experience layer instead of a CMS

The second option skips a separate CMS and instead places a Frontend Management Platform (FMP) directly on top of commercetools. An FMP such as Laioutr takes over the presentation layer: product data comes through GraphQL from commercetools, and marketing content and page composition happen in a Studio editor, directly in the live storefront. For many marketing teams this is enough, because the actual need is not "another content repository" but the ability to build landing pages, campaign pages, and product worlds themselves, without opening an engineering ticket every time.

This is an important distinction from commercetools Frontend: an FMP like Laioutr is built backend-agnostic. If your stack is commercetools today and something else in three years, the frontend layer stays, because it is not structurally bound to a single backend.

Where content, presentation, and composition actually live

If you are trying to figure out which path your team needs, the concrete question is: where should your marketing team actually work?

• If the answer is "in a content editor, with approval workflows, across many channels at once," you need a headless CMS in addition to a frontend.
• If the answer is "directly on the storefront, composing pages and campaigns themselves," an FMP as the presentation layer is often enough on its own, with no separate CMS.
• If both are true, for example a magazine section with an editorial workflow plus fast commerce landing pages, combining a headless CMS with an FMP is the pragmatic route: Storyblok or Contentful for editorial content, the FMP as the frontend that merges both CMS content and commercetools product data into the same page.

This combination is not a workaround, it is an established pattern: the CMS stays the content backend, the FMP owns composition, performance, and multi-backend connectivity.

Where Laioutr fits

Laioutr does not replace a headless CMS, and it is not trying to. If you already run Storyblok or Contentful, Laioutr couples as a frontend layer to both sources, the CMS content API and the commercetools GraphQL API, and ships a single, performant storefront from them. If you do not need a separate CMS at all, because your content needs are mostly campaign pages, product worlds, and landing pages, Laioutr's Studio editor covers the presentation layer directly, without a third system to operate.

The practical difference from commercetools Frontend: Laioutr is not tied to commercetools as the backend. If you switch backends later, say to Shopware, Shopify, or Adobe Commerce, the frontend layer stays. For us, the composable-commerce promise means that choice stays reversible on the frontend side too.

A decision framework for your team

Before you commit to a CMS, an FMP, or both, a short inventory helps:

1. How much editorial content gets produced per week, and who writes it?
2. Do you need approval workflows across multiple roles and languages?
3. How often does marketing change landing pages or campaign pages, and how long does that take today?
4. Is your commercetools setup a long-term commitment, or do you want the backend choice to stay open?

The answers usually make it clear whether you need a headless CMS, a frontend layer, or both. There is no wrong answer here, only the one that fits your content needs.

If commercetools is your backend and you have not yet decided how marketing should build pages independently, this is a good moment to take a closer look at the Composable Headless Frontend. For the commercetools-specific connection, check our headless frontend landing page for commercetools, and for the content-management capabilities inside Studio, the Content Management product page.

For more on how the FaaS model and a headless CMS play together, see our article FaaS vs. Headless CMS: Why a CMS Alone Still Isn't a Frontend, and our take on commercetools' standalone modules and what they mean for your frontend decision.