What is a Headless CMS?

A headless CMS separates the back end, where content is created and stored, from the front end that displays it. The CMS itself doesn’t render anything. A separate front end, such as a website or mobile app, fetches the content through an API (application programming interface) and displays it.

With a traditional content management system (CMS) like WordPress, the two halves are coupled: one system stores your content and renders it as web pages, so you edit everything in one place. A headless CMS decouples the front end from the back end.

How a headless CMS works

Your content lives in the CMS’s content repository: a cloud database on hosted platforms, or your own server with open-source options like Strapi. Any front end can request that content over a REST or GraphQL API. The API doesn’t render anything; it delivers raw, structured content, typically as JSON, and the front end that requested it decides how everything looks.

Say you store a product description once. Your website, built with a framework like Next.js, fetches it and renders a product page. Your mobile app requests the same entry for its product screen, and an in-store kiosk pulls it too. Update the description in the CMS and every channel changes, because all of them read from one source.

Benefits and trade-offs

The benefits follow from the split. Content is stored once and reused across every channel. Teams work in parallel: editors manage content without touching code, while developers build the front end in whatever framework fits.

The costs follow from the same split. A headless CMS ships no themes and no ready-made front end, so a developer has to build and maintain the presentation layer a traditional CMS includes out of the box. You run two systems instead of one (the CMS and the front end), and previewing a draft is harder, because the CMS doesn’t know how your front end will render it.

When to go headless

Neither model wins across the board; match the tool to the project.

• Go headless when content must reach more than one channel: a website plus a mobile app, kiosk, or smart device.
• Go headless when your front end is already a JavaScript framework, or when separate teams own content and presentation.
• Stay traditional when you run one website and want themes, plugins, and built-in previews.
• Stay traditional when there’s no developer on the team. A headless front end needs one to build it and keep it running.

If you’re unsure, start traditional. WordPress can go headless later without switching platforms.

Examples of headless CMS platforms

Strapi is open-source, MIT-licensed software: run it on your own servers for full control, or deploy to its hosted Strapi Cloud, and it turns your content model into REST and GraphQL APIs. Sanity is a hosted platform with a free plan to start; your content lives in its cloud back end. Other widely used platforms include Contentful, Hygraph, and Storyblok.

Using WordPress as a headless CMS

WordPress can run headless. The REST API has shipped in WordPress core since version 4.7 in December 2016, with endpoints for posts, comments, terms, users, and settings. Editors keep the familiar wp-admin dashboard; a separate front end fetches content from those endpoints as JSON (or through a GraphQL plugin) and renders it.

Plan for two deployments: hosting for the WordPress install that stores the content, and hosting for the front end that displays it. Since the endpoints are already there, a developer can prototype a new front end against your existing site’s real content before you commit to anything.