What is a headless CMS, and do you need one?

A headless CMS is a content system that stores and manages your content, then delivers it through an API to whatever front end needs it: a website, an app, a kiosk or a partner feed. It separates the "body" (content) from the "head" (the design and code people see). You need one when content must feed more than one channel, or when you want a fast custom front end; most small business sites do not.
Traditional vs headless, in plain English
In a traditional CMS like WordPress, the system that stores content also builds the pages. You write a post, pick a theme, and WordPress turns both into HTML when someone visits.
In a headless CMS, the system only stores structured content. A separate application, often built with React and Next.js, asks for that content and decides how to display it. The CMS has no opinion about layout, fonts or templates.
A useful way to think about it: a traditional CMS is a restaurant that cooks and serves. A headless CMS is a commercial kitchen that supplies several restaurants, a catering truck and a grocery shelf, each presenting the food their own way.
| Traditional CMS | Headless CMS | |
|---|---|---|
| Examples | WordPress (standard), Squarespace, Wix | Contentful, Sanity, Strapi, headless WordPress |
| Who builds the pages | The CMS, using a theme | A separate front end (Next.js, an app, etc.) |
| Content structure | Mostly pages and posts with a body field | Structured fields you define (title, image, price, FAQ) |
| Channels | Mostly one website | Website, apps, email, screens, partners |
| Preview and editing | Built in, WYSIWYG | Needs to be set up; varies by platform |
| Developer involvement | Low to moderate | Moderate to high |
| Hosting | One system | CMS (usually SaaS) plus front-end hosting |
How a headless setup works
A typical headless build has three parts:
- The content hub. Editors work in the CMS. Instead of one big text box, they fill in structured fields: a product name, a short summary, a hero image, a list of features.
- The API. The CMS exposes content through REST or GraphQL APIs. The front end requests exactly what it needs.
- The front end. A framework such as Next.js fetches the content and renders pages. It can pre-build pages ahead of time (static generation), build them on request, or mix both, then serve them from a CDN close to visitors.
When an editor publishes, a webhook tells the front end to rebuild or refresh the affected pages. Done well, updates appear within seconds and pages load very quickly.
Why teams go headless
One source of truth for many channels
If the same product details, locations or FAQs appear on a website, a mobile app and in-store screens, a headless CMS lets you edit once and publish everywhere. This is the strongest reason to go headless.
Speed and front-end freedom
Developers are not bound to a theme system. They can build exactly the experience the brand needs, and frameworks like Next.js make it straightforward to ship fast pages that do well on Core Web Vitals.
Cleaner, more reusable content
Structured content forces good habits. A "location" has an address, hours and a phone number as separate fields, so it can be reused, filtered and marked up with schema without copy-and-paste.
Security and scaling
The public site is often pre-built files on a CDN, with the CMS behind its own login on a separate service. That reduces the attack surface compared with a public-facing admin on the same server, though it does not remove the need for good security practices like those in our website security checklist.
The costs people underestimate
Headless is not free flexibility. Before you choose it, plan for:
- Two systems instead of one. You maintain the CMS subscription and the front-end hosting and code.
- Developer dependency. New page types, new components and many layout changes need a developer. Editors gain structure but can lose some freedom.
- Preview. Seeing a draft exactly as it will appear takes setup. Most platforms support it, but it is not automatic.
- Plugins you no longer have. In WordPress, SEO, forms and redirects are a plugin away. In a headless build, someone has to build or integrate each of those.
- Higher upfront cost. Content modeling, front-end development and integration take more time than installing a theme. Our website cost guide explains how that affects budgets.
The main options
- Contentful. A mature SaaS platform with strong content modeling, localization, environments and roles. A common choice for mid-size and enterprise teams.
- Sanity. Highly flexible, with a customizable editing studio and real-time collaboration. Developers like how much they can tailor the editor.
- Headless WordPress. Keep the WordPress admin editors already know, and use the REST API or WPGraphQL to feed a Next.js front end. A good bridge for teams with existing WordPress content.
- Strapi and other open-source options. Self-hosted, with full control and more maintenance.
Pricing models differ (seats, records, API usage, environments) and change often, so compare current plans against your expected content volume and team size.
When you should go headless
Headless is a strong fit when:
- Content needs to reach a website plus an app, a portal or other channels.
- You need a custom, high-performance front end in Next.js.
- You run multiple brands, regions or languages from one content source.
- Your marketing team wants to assemble pages from approved, reusable components while developers control the design system.
- The site has real application features (logins, calculators, dashboards) alongside marketing content.
When a traditional CMS is better
Stay traditional when:
- The site is mostly a blog or a content library. We explain why in why we still choose WordPress for blogs and content sites.
- Your team wants visual, on-page design control. For design-led marketing sites, we often reach for Webflow; see when Webflow is the right call.
- Budget and timeline are tight, and one channel (the website) is all you need.
- Nobody will own a front-end codebase after launch.
A middle path
You do not have to pick an extreme. Common hybrids we build:
- WordPress as a headless backend with a Next.js front end, so editors keep a familiar admin.
- A traditional site plus a headless CMS for one area, such as a locations directory or product catalog that also feeds an app.
- Headless commerce, where Shopify or BigCommerce runs the cart and a CMS handles editorial content. Our ecommerce platform comparison covers which commerce engines support this well.
How we'd decide
Ask two questions. Does your content need to go to more than one place? Do you need a custom front end for speed or functionality? If both answers are no, a traditional CMS will serve you well and cost less. If either answer is yes, headless is worth scoping, and the content model becomes the most important part of the project.
Curious whether headless fits your site? See our headless CMS services or talk to us.
Questions people ask
What is a headless CMS in simple terms?
Is a headless CMS better for SEO?
Is WordPress a headless CMS?
Does a small business need a headless CMS?
Planning a website?
Get a platform recommendation and a fixed quote within one business day.



