Refract Group2026
Glossary
Headless CMS
A headless CMS stores and manages a website’s content and delivers it through an API, with no pages or templates of its own. Developers build the site separately, in a framework such as Next.js or Nuxt, and fetch the content from it.
components/Post.tsx
const CMS = 'https://cms.example.com'
export default async function Post({ slug }) {
const res = await fetch(
`${CMS}/wp-json/wp/v2/posts?slug=${slug}`
)
const [post] = await res.json()
return <h1>{post.title.rendered}</h1>
Headless CMS in detail
- Also called
- Headless content management system, API-first CMS, Decoupled CMS
- Topic
- Website
- Updated
What it is
A traditional CMS such as WordPress does two jobs: it holds the content, and it renders the pages visitors see through its themes. A headless CMS keeps the first job and drops the second. Content is modelled and edited in the CMS, then sent as JSON to whatever asks for it: a website, an app, a second brand’s site.
Some products are built headless from the start, and others can be run that way. WordPress has a REST API that sends and receives content as JSON, so a coded front end can read from it while editors carry on in wp-admin. Shopify does the same for commerce: you build the storefront, and its APIs handle products, cart and checkout. On the front end, Next.js has a Draft Mode so editors can preview unpublished content from a headless CMS before it goes live.
Why it matters
Going headless gives developers full control of the front end: the URLs, the markup, the speed and any parts shared with the product. The cost is a second system. The CMS brings its own bill, roles and limits, and the coded site needs a developer for anything other than content. Things a traditional CMS gives editors without asking, such as previewing a page before it is published, have to be built and then maintained. For a small marketing team that is often more machinery than the site needs.
How we do it
Our comparison pages set out when headless is worth it. On a site built in Next.js or Nuxt, editors get a CMS only if developers connect one, so before the work is priced we list what your team must change without a developer. If editors publish daily in WordPress and won’t move, and the public site has to share parts with a product, we’d consider keeping WordPress as the CMS behind a coded site, knowing it means running two things. A custom store usually keeps Shopify’s engine underneath, headless.
This website went the other way. It is Nuxt on Vercel with its content in the code and no CMS at all, because the people who publish it are developers.
An example
Say a fintech company’s marketing team has written in WordPress for five years, and the website now has to share sign-in and pricing components with the company’s app. A rebuild in Next.js gives engineering those shared parts. Keeping WordPress headless means editors keep wp-admin, their roles and their scheduled posts, while the new site fetches each post through the REST API. The company now hosts and patches two systems, and accepts that because neither team has to change how it works.
Common mistakes
- Going headless for page speed alone. A traditional CMS on good hosting with a lean theme can be fast too, and a second system to run is a high price for speed.
- Forgetting the editors’ preview. Without a preview route built into the front end, editors publish blind and check the live page afterwards.
- Modelling content as whole pages. Content saved as page-shaped blocks of rich text ties it to one site’s layout, which undoes the reason for separating the two.
- Leaving search basics out of scope. On a coded front end the sitemap, metadata and redirects are written in code, so whatever an SEO plugin once produced has to be rebuilt.
Headless CMS vs traditional CMS
A headless CMS only stores and serves content and leaves the pages to a separate front end, while a traditional CMS stores the content and also renders the pages through its themes or templates.
| Headless CMS | Traditional CMS | |
|---|---|---|
| Renders pages | No, a separate front end does | Yes, through themes or templates |
| Editor preview | Built into the front end by developers | Built in |
| Systems to run | Two: the CMS and the site | One |
| Suits | Sites that share parts with a product | Publishing teams on a single site |
Questions
What people ask about headless CMS.
A traditional CMS such as WordPress stores content and also builds the pages visitors see, using themes. A headless CMS only stores and manages the content and sends it through an API, so developers build the pages separately, often in Next.js or Nuxt. Headless gives more control of the front end, and adds a second system to run.
Yes. WordPress can run as a headless CMS through its built-in REST API, which sends content as JSON. A site built in Next.js or Nuxt fetches posts and pages from it while editors keep working in wp-admin with the same roles, scheduling and revisions. WordPress still needs its hosting, updates and backups alongside the coded site.
A headless CMS neither helps nor hurts rankings by itself. What matters is the front end: whether pages arrive as HTML a crawler can read, and whether titles, sitemaps, canonical tags and redirects are built. Next.js and Nuxt render on the server by default, which covers the first. The rest is the developers’ job, since the CMS no longer produces it.
Where this shows up in our work
Related terms
Working on this now?
Tell us what you’re building and where it’s stuck. We reply within 12 hours.
Most teams start with a call, then a sprint or an audit.
The people you’d work with, from the first call to launch