 bundles content management with presentation: the CMS stores the content and generates the HTML pages that the browser renders.){kind=link}
The Architecture That Separated Content From Presentation
A traditional CMS (WordPress, Drupal, Joomla) bundles content management with presentation: the CMS stores the content and generates the HTML pages that the browser renders. The design, the templates, and the content are managed in the same system. This architecture is highly accessible — non-technical users can manage content and publish pages without web development involvement — and has produced the majority of the world’s websites.
A headless CMS separates the content management layer from the presentation layer: the CMS stores content and provides it via API (usually REST or GraphQL), and a separately built front end (a React app, a Next.js site, a native mobile app, or anything else that can consume an API) handles presentation. The ‘headless’ metaphor refers to removing the ‘head’ (the presentation layer) from the traditional CMS body. This separation introduces complexity but provides specific benefits that some projects genuinely need.
Why Headless Architecture Exists: The Problems It Solves
Content that needs to appear in multiple channels simultaneously is the primary headless CMS use case: the same product descriptions appearing on a website, a mobile app, digital signage in a retail store, and a partner’s catalog integration. In a traditional CMS, each channel has its own content management, which creates duplication and synchronization challenges. In a headless architecture, content is managed once and consumed by all channels via API.
Performance is the secondary motivator: a headless front end built as a static site (using Next.js, Gatsby, Astro, or similar) that receives content from the CMS at build time can be deployed to a CDN and served as pre-built HTML — providing the fastest possible loading experience without server-side generation on each request. For content-heavy marketing sites with high traffic, this performance architecture produces measurable improvements in Core Web Vitals and search ranking.
When Headless Is the Wrong Choice
Headless CMS architecture adds significant complexity to web projects: non-technical content editors lose the WYSIWYG editing experience where they can see their content in context as they edit; developers must build and maintain the front end separately from the CMS; the preview experience (seeing content before publishing) requires additional engineering work; and the simpler use cases that traditional CMS handles without additional configuration require custom development in the headless setup.
The projects where headless CMS creates more problems than it solves: small websites where a single channel (the website) is all that’s needed, projects where non-technical content editors need an accessible editing experience without developer involvement in the content workflow, and projects with limited development resources where the front-end development overhead of the headless approach diverts resources from other priorities. A WordPress or Squarespace site for a small business serves its purpose far better than a headless CMS would.
The Popular Options and Their Differences
Contentful is the most established enterprise headless CMS — a mature platform with wide integration support, excellent developer experience, and pricing that scales with usage (which becomes significant at scale). Sanity provides a highly customizable content modeling experience with a real-time collaboration editing interface and a generous free tier. Storyblok provides a visual editor that partially restores the editing-in-context experience that headless architectures otherwise sacrifice — a significant usability advantage for non-technical editors.
Strapi (open source, self-hosted) is the headless CMS for projects where control over hosting and data storage is important and where developer resources exist to maintain the self-hosted infrastructure. It provides the full headless CMS capability without the recurring subscription cost of hosted options, at the cost of infrastructure management. Directus (also open source, self-hostable) wraps any SQL database in a headless CMS interface — useful for projects that need a headless CMS layer over an existing database.
Building the Front End: The Developer’s Half of Headless
The headless CMS is only the content side; the front end that presents that content requires separate development. Next.js (React-based, maintained by Vercel) and Astro (content-focused static site builder with framework-agnostic component support) are the most commonly paired front-end frameworks for headless CMS projects. Next.js’s ability to combine static generation (content fetched at build time from the CMS) with server-side rendering and client-side updates provides flexibility for content that changes at different rates.
The practical deployment architecture for most headless CMS projects: CMS platform provides the content editing interface and API (Contentful, Sanity, or similar), Next.js or Astro generates the site at build time by fetching content from the CMS API, the built site is deployed to Vercel, Netlify, or Cloudflare Pages for global CDN distribution. Webhook triggers from the CMS (fire when content is published) trigger a new build automatically, keeping the deployed site current. This architecture provides excellent performance and developer experience at the cost of the setup complexity that makes it inappropriate for simple projects.