What Is a Headless CMS? A Plain Explanation for Developers

A headless CMS is a content management system with no front end of its own. Editors write and organise content in an admin panel, and the CMS delivers that content through an API, usually REST or GraphQL, to whatever front end you build: a Next.js site, a mobile app, or anything else that can make an HTTP request. The "head" is the presentation layer, and a headless CMS leaves it out on purpose.

The rest of this article explains how it differs from a traditional CMS like WordPress, when it is worth the extra work, how it plugs into Next.js, and which options developers usually look at.

Headless CMS definition

Contentful's comparison of headless and traditional CMSs (accessed 2026-11-13) defines a headless CMS as a back-end-only system that stores content and delivers it through an API to any front end or platform. Content is stored as structured data, not as finished HTML pages.

Two more terms you will run into:

• Traditional (coupled) CMS. WordPress, Drupal and Joomla bundle the back end and the front end in one system. Content is organised around pages, and the same system that stores the content also renders the HTML.
• Decoupled CMS. A broader category. The back end and front end are separated, but the CMS may still ship a front end you can use. A headless CMS is the API-only variant.

Headless vs traditional CMS

The table misses the difference developers feel most. In a page-based CMS, content and layout tend to live together, so a post can end up full of formatting meant for one specific theme. In a headless CMS you model content as fields (title, summary, author reference, body, SEO description), and the front end decides how to show them. That is what makes the same content reusable on a website and in an app.

Pros and cons of a headless CMS

What you gain:

• Front-end freedom. You pick the framework: Next.js, Astro, a mobile app, or several at once.
• One content source for many channels. A site and an app can read the same API.
• Room for performance work. The front end is yours, so you can render pages statically and serve them from a CDN.

What it costs:

• More developer work. There is no theme to install, so someone builds the front end, routing and rendering.
• Preview is your job. Editors want to see a draft before they publish, and in a headless setup developers build and maintain that.
• Two systems instead of one. The CMS and the front end are deployed and kept in sync separately.

When a headless CMS is the right choice

A headless CMS makes sense when at least one of these is true:

• You already build the front end in a modern framework (React, Next.js, Vue) and do not want a PHP theme layer next to it.
• The same content goes to more than one place, for example a website and a mobile app.
• Content has real structure: products, courses, documentation, recipes, anything with repeating fields and relations.
• Developers are on the team for the long term. Headless is not a "set up once and forget" option.

It is probably the wrong choice when:

• You need a simple marketing site or blog fast and nobody on the team writes front-end code.
• Editors expect drag-and-drop page building and full visual control without developer involvement.
• The budget does not cover building and maintaining a custom front end.

For a small brochure site I would pick the simpler tool. Headless starts paying for itself when both the content and the front end keep growing.

How a headless CMS fits with Next.js

Next.js and a headless CMS split the work cleanly. The CMS stores and serves content. Next.js fetches it, renders pages and handles caching.

The usual flow looks like this:

1. Editors create content types and entries in the CMS admin panel.
2. Your Next.js app fetches content from the CMS API in server components or at build time.
3. Pages are pre-rendered or cached, so visitors get fast responses.
4. When content changes, you revalidate the affected pages.

A minimal fetch in the App Router is plain fetch:

Previewing drafts with Draft Mode

The preview problem has an official answer in Next.js. Draft Mode lets editors see how draft content will render without waiting for revalidation. While an editor is in Draft Mode, Next.js skips cached and pre-rendered content and fetches from the CMS directly. Other visitors still get the cached version.

The Next.js guide assumes the CMS supports configurable preview URLs and describes the contract: the CMS opens a URL like /api/draft?secret=...&slug=/posts/foo, your Route Handler checks the secret, calls draftMode().enable() and redirects to the page. The secret is shared only between your app and the CMS.

CMSs that live inside the Next.js app

Most headless CMSs run as a separate service. Payload is an exception worth knowing about. Its installation docs (accessed 2026-11-13) say Payload "installs directly in your Next.js /app folder", next to your own front-end routes, and you wrap your config with withPayload in next.config.js. The admin panel and APIs then deploy as part of the same app.

Main headless CMS options

There are dozens of headless CMSs. These five come up most often for JavaScript and Next.js projects:

• Payload. Describes itself as "the Next.js fullstack framework". You define content in a TypeScript config and get an admin panel, a database with migrations, REST and GraphQL APIs, auth and access control. Works with MongoDB or Postgres.
• Strapi. An open-source headless CMS with an admin panel built around a Content Manager and a Content-type Builder. You query content with REST or GraphQL. Some features are only in paid Growth and Enterprise plans.
• Sanity. Stores content as structured data in its Content Lake, queried with its own language, GROQ. Sanity Studio, the editing app, is open source and configured with JavaScript or TypeScript.
• Contentful. A SaaS platform. Content is delivered through APIs, including a Content Delivery API and a Content Preview API, according to its official JavaScript SDK.
• Directus. Connects to your SQL database and gives you REST and GraphQL APIs, an SDK, auth, files and a web app for managing content. Available as Directus Cloud or self-hosted with Docker.

They differ in hosting model, licence, how you model content and what editors see. For a side-by-side comparison with recommendations for Next.js projects, read our guide to the best headless CMS for Next.js.

FAQ

Is WordPress a headless CMS?

Not in its standard setup. Contentful's comparison lists WordPress as a traditional CMS, where the same system stores content and renders the front end.

What is the difference between headless and decoupled CMS?

Both separate content from presentation. A decoupled CMS may still ship a front end you can use. A headless CMS is API-only and has no front end at all.

Do I need a headless CMS for a Next.js site?

No. You can keep content in Markdown or MDX files in the repo, which works well when developers write the content. A headless CMS becomes useful when non-developers need to edit content without touching code.

Is a headless CMS good for SEO?

The CMS itself does not decide SEO. What matters is how the front end renders pages. With Next.js you can pre-render or server-render pages, so search engines get full HTML. You do have to model SEO fields (title, description) in the CMS yourself.

Which headless CMS is best for beginners?

If you already know TypeScript and Next.js, a code-first option where content types live in your repo is easy to reason about. If you want a hosted service with no server to run, a SaaS option is simpler to start. The comparison guide goes into detail.

Learn the parts underneath

Every headless CMS is an API, and every Next.js page that reads from one is an HTTP client. If those parts feel shaky, ShortLesson has short practical courses on them: HTTP and REST APIs, Node.js: the basics, GraphQL: the basics and React: the basics.