Headless CMS
A headless CMS manages content and delivers it over an API, with no built-in front-end. The "head" — the presentation layer that a traditional CMS like WordPress bolts onto its content — is removed, leaving a pure content backend. Editors write in a friendly admin UI; developers fetch that content via REST or GraphQL and render it however and wherever they want: a React site, a mobile app, a smart display, all from one content source.
This decoupling is the core idea and the core benefit. Traditional CMSes tie content to a specific presentation (a WordPress theme renders WordPress content as HTML pages). Headless treats content as structured data that any number of front-ends consume — enabling modern Jamstack architectures, omnichannel delivery, and best-in-class frontend tooling (Next.js, Astro) on top of professional content management.
TL;DR
- Headless = content backend + API, no front-end. Editors manage content; developers fetch it via REST/GraphQL and render it anywhere.
- The win is decoupling: one content source feeds many front-ends (web, mobile, IoT), and you use modern frontend tools instead of the CMS's templating.
- You define a content model (structured types and fields) — content becomes typed data, not blobs of HTML.
- Two flavors: API-first SaaS (Contentful, Sanity, DatoCMS — hosted, you don't run it) and open-source/self-hosted (Strapi, Directus, Payload).
- Git-based CMSes (content as Markdown in the repo, e.g. via a Git-backed editor) are a lightweight variant for developer-centric sites.
- The trade vs WordPress: headless gives frontend freedom and multi-channel delivery but requires you to build the frontend — there's no theme to install.
How It Works
The editor experience stays friendly (a rich admin UI); what changes is that content comes out as JSON via an API rather than as rendered pages. Developers own presentation entirely.
Quick Example
Modeling content, then fetching it into a Next.js front-end:
The same getPost content could feed a mobile app, an email digest, or a voice assistant — one source, many heads.
Core Concepts
Content Modeling
The heart of a headless CMS is the content model — you define structured content types (BlogPost, Product, Author, LandingPage) with typed fields (text, rich text, images, references, dates, booleans). This is a schema-design exercise much like database modeling: model content by its meaning and structure, not by how one page displays it.
Good modeling is reusable ("a Product has a name, price, and images" works for web, app, and print); bad modeling bakes in presentation ("a HomepageHeroWithBlueBackground field") and defeats the purpose. Structured content with references between types is what enables one source to serve many front-ends.
API Delivery
Content is delivered via:
- REST — simple, ubiquitous, cacheable.
- GraphQL — fetch exactly the fields/relations you need in one query (popular for content, since pages pull nested, related content).
- CDN-cached delivery APIs — most SaaS headless CMSes serve content from a CDN for speed, with separate content-delivery vs content-management APIs.
Front-ends fetch at build time (static generation — Astro/Next.js SSG, fastest) or request time (SSR/client-side, for frequently-changing content), often with webhooks triggering rebuilds when editors publish.
Types of Headless CMS
Sanity is notable for treating content as queryable structured data with a customizable editing environment; Strapi is the leading open-source self-hosted option; Contentful is the enterprise SaaS standard. The right pick depends on hosting preference, editor needs, and budget model (per-seat/per-API-call SaaS vs self-hosted infrastructure).
Headless vs Traditional CMS (WordPress)
The honest trade-off: headless gives frontend freedom, performance, and omnichannel delivery at the cost of building the front-end yourself — there's no "install a theme and you have a site." For a simple blog or brochure site where an off-the-shelf WordPress theme suffices, traditional WordPress is often faster to ship. For a product with a custom design, multiple front-ends, or a modern-framework team, headless wins decisively. (WordPress can also run headless — using its REST/GraphQL API as a backend for a separate front-end — a common migration path.)
Common Mistakes
Modeling Content Around One Page
The cardinal sin: fields like homepageBanner or aboutPageParagraph2 that encode a specific layout. This recreates coupling inside a decoupled system — the content can't be reused or served to other channels. Model content by what it is (structured, reusable types), not by where it appears.
Underestimating the Frontend Build
"Headless" means you own the entire presentation layer — routing, rendering, previews, forms, search. Teams expecting WordPress-like "install and go" are surprised by the frontend work. Budget for building (and maintaining) a real front-end; the CMS is only half the system.
Ignoring the Preview/Editor Experience
Editors used to seeing their changes rendered lose that in naive headless setups (they edit JSON-ish fields, publish, and hope). Good implementations provide live preview (draft content rendered in the real front-end) — a significant effort that's easy to skip and painful to lack. Choose a CMS and architecture that supports preview if editors need it.
API Cost and Rate Limits (SaaS)
SaaS headless CMSes often bill per API call or seat and enforce rate limits. A client-side-fetched, high-traffic site can rack up costs or hit limits. Prefer build-time fetching + CDN caching, and understand the pricing model before committing.
Choosing Headless for a Simple Site
For a small blog or marketing site with no custom design or multi-channel need, headless can be more architecture than the problem requires. A WordPress theme or an Astro site with Markdown files may ship faster. Match the tool to actual complexity.
FAQ
What does "headless" actually mean?
The "head" is the front-end/presentation layer. A traditional CMS couples content management to a specific front-end (WordPress content → WordPress theme). "Headless" removes that front-end, exposing content purely via API so you attach any head(s) you want — a website, mobile app, or multiple channels from one content source.
Headless CMS or WordPress?
Choose headless for custom designs, modern-framework teams, multiple front-ends (web + app), or performance-critical Jamstack sites. Choose WordPress (traditional) for simple sites where a theme suffices, editor familiarity matters, and you want minimal frontend engineering. WordPress-as-headless is a middle path that keeps its editor while decoupling the front-end.
Which headless CMS should I pick?
Depends on constraints: Contentful/DatoCMS for enterprise SaaS with no ops; Sanity for flexible structured content and a customizable editor; Strapi/Directus/Payload for self-hosted control and no per-call costs; Git-based (TinaCMS, Decap) for developer sites with Markdown content. Weigh hosting preference, editor needs, and pricing model.
How does content get to my site?
Your front-end fetches it via the CMS's REST or GraphQL API — usually at build time (static generation, fastest and cheapest) with webhooks triggering rebuilds on publish, or at request time (SSR) for frequently-changing content. Most SaaS CMSes serve content from a CDN for low latency.
Is a headless CMS good for SEO?
Yes — arguably better, because you control the front-end and can use SSG/SSR for fast, crawlable pages with full control over meta tags, structured data, and Core Web Vitals. The caveat: SEO becomes your responsibility to implement, whereas WordPress plugins handle much of it out of the box.
Related Topics
- Astro — A common front-end for headless content sites
- Next.js — SSG/SSR consuming CMS APIs
- GraphQL — A popular content-delivery API style
- REST API Design — The other delivery API
- SEO Engineering — Owning SEO on a headless front-end
- CDN — How content APIs achieve low latency
- PHP — WordPress's language, the traditional-CMS incumbent