Headless CMS

What a headless CMS actually changes

A traditional CMS bundles two jobs into one system: it stores content and decides how that content looks on a page. A headless CMS splits those jobs apart. Content sits in a structured store (a product description, an article body, a set of image references) and gets delivered through an API to whatever needs it: a Next.js website, an iOS app, a kiosk in a retail store, a partner's booking widget. The front end owns the rendering; the CMS owns the content.

That split matters most once a business publishes to more than one channel from the same source. A retailer pushing product copy to a website, an app and a marketplace feed used to maintain three versions or accept drift between them. With structured content delivery feeding all three from one model, an editor updates a price or a description once and every channel picks it up on its next fetch.

The cost lands on marketing: a headless CMS usually removes the visual, drag-and-drop page builder that marketing teams are used to. Content editors work in structured fields, which asks for different authoring habits than a WYSIWYG canvas, and someone has to build the preview tooling that shows what a change will look like before it goes live. Teams that skip this step tend to find publishing confidence drops in the first few months, even though the technical migration went smoothly.

Headless CMS vs WordPress, AEM and traditional platforms

WordPress can run headless: its REST API will serve JSON to a React front end without much trouble, but doing so gives up the theme layer and a large share of the plugin ecosystem WordPress built its reputation on. Teams considering this route are often better served by a purpose-built headless platform (Contentful, Sanity and Strapi all fit the brief) unless there's a specific reason to keep WordPress's authoring interface. The WordPress migration to headless path is well trodden, but the content model rework usually takes longer than the API swap.

Adobe Experience Manager occupies different territory. AEM can be deployed headless, exposing content through its Content Fragment API, and for organisations already running AEM for personalisation, DAM and multi-brand workflow, that's a sound way to extend an existing investment. For a business that doesn't already run AEM, adopting it purely as a headless content API means taking on a full digital experience platform, so it is worth comparing against a purpose-built headless CMS such as Contentful or Sanity on cost, footprint and implementation effort for that specific case. If the organisation already relies on other parts of the AEM stack, that existing investment is usually the deciding factor.

Shopify sits in a narrower lane: its Storefront API supports headless commerce front ends, which suits retailers wanting a custom checkout or app experience without leaving Shopify's back end. It isn't a general-purpose content platform, so teams publishing a lot of editorial content alongside product data usually pair it with a dedicated headless CMS.

Choosing a headless CMS platform for React and Next.js

Most headless CMS platforms (Contentful, Sanity, Strapi, Storyblok, Craft CMS in headless mode) serve content to a React or Next.js front end without friction; the API layer is rarely the differentiator. What separates them in practice is editorial experience (whether a non-technical marketer gets a usable preview and a sane approval flow), content modelling flexibility, and how the platform handles localisation and role-based access as the team grows. A business publishing to one market with a small content team can move fast on almost any of them. One publishing across states, brands or languages should weight the evaluation toward editorial approval automation and permissioning before comparing API response times.

Personalisation is the other place platforms genuinely diverge. Some headless CMS products ship native audience segmentation and staged content delivery; others expect that logic to live in the front end or a separate service. Teams planning content personalisation work should confirm which side of that line their shortlisted platform sits on before committing, because retrofitting personalisation into a content model that wasn't built for it is a slower job than building it in from the start.

When a headless CMS is the wrong call

A single-site brochure business with one content editor and no plan to add a second channel rarely needs the added engineering overhead of a headless architecture; a well-run WordPress site or a hosted builder does that job for less. The decision to go headless earns its cost when there's a genuine second or third consumer of the same content: an app, a partner feed, a franchise network, a set of regional microsites. A migration from WordPress to a headless CMS shows the pattern clearly: the trigger wasn't a desire for modern architecture, it was multiple properties needing to draw from consistent, centrally managed content.

The most underestimated part of any headless CMS project is the content model design and the migration of legacy content into it. API integration is usually straightforward by comparison. Free-text WordPress pages don't map cleanly to structured fields, and teams that rush this step end up with a content model that looks tidy in a diagram but doesn't match how editors actually work day to day.