A headless CMS is a content management system that stores and manages content but does not decide how it looks. Your website, app or other channel fetches the content and presents it however you design. It suits teams that publish the same content to several places or that want a custom front end. For a small brochure site with one editor, it is often more machinery than you need.
What “headless” means
Sanity’s structured content course defines headless software, such as a CMS, as software that keeps where content is stored apart from where it is displayed (Sanity learning course). The “body” is the content store, and the “head” is the presentation layer.
The same course defines structured content as information broken into its smallest reasonable pieces, explicitly organised and classified so both computers and people can understand it. In practice, that means a product has separate fields for name, summary, price and image rather than one block of formatted text.
Astro’s documentation puts it this way: a headless CMS helps you write your content but does not generate a site that displays it. Astro handles presentation, and the CMS handles the writing environment. You get a visual editor, defined content types and collaboration tools outside the code project (Astro: Content management systems).
Traditional versus headless
| Aspect | Traditional CMS (for example, one that renders its own pages) | Headless CMS |
|---|---|---|
| Content and design | Tightly coupled | Separated |
| Front end | Themes or templates | Any framework you choose |
| Channels | Mainly the website | Website, apps, kiosks and others from one source |
| Editing | Often live preview built in | Preview needs to be built or configured |
| Developer effort | Lower to start | Higher to start |
| Moving parts | One system | CMS plus front end plus hosting |
Who benefits most
- Multi-channel publishers: one product catalogue feeding a site, an app and in-store screens.
- Teams with a custom design system: developers want full control of markup and performance.
- Larger editorial groups: roles, workflows and structured content models matter.
- Sites built with static generators or modern frameworks: the CMS supplies content at build time. See static site generators explained.
Who probably does not need one
- A small service business with a handful of pages that change a few times a year.
- A single editor who is comfortable with files. Astro, for example, has built-in Markdown support and content collections, covered in using Astro content collections for a business blog.
- Teams with no developer to maintain the front end.
The real trade-offs
Preview and editing experience. Editors often expect to see the page as they edit. With a headless setup, live preview is something that must be built, not assumed.
Publishing flow. If your site is built ahead of time, a content change usually triggers a rebuild before it appears. Confirm how your chosen setup handles this. Static output has limits for very large or frequently changing sites, as web.dev notes (web.dev: Rendering on the Web).
More vendors, more cost. You may pay for the CMS, hosting and developer time. Pricing varies, so check each vendor’s current terms.
Integration risk. Astro’s guide says some headless CMSes provide an Astro integration and others provide a JavaScript SDK you install to fetch content, so effort differs by product.
Lock-in. Content model design takes thought. Check export options before committing.
Git-based or API-based
Content can live in your code repository (Markdown files edited through a Git-based tool) or in a hosted service you query through an API. Astro’s guide notes that CMSes can be filtered by type, including Git-based and API-driven, and describes CloudCannon as a Git-based CMS. Git-based setups keep content versioned with code. API-driven services tend to offer richer editorial features. Neither is universally better.
A decision framework
Ask five questions:
- Will the same content appear in more than one place?
- Do non-technical people publish frequently?
- Do we have developer capacity to build and maintain the front end?
- Do we need custom design or performance that a template cannot provide?
- Can we afford the extra complexity and cost?
Mostly yes: headless is worth exploring. Mostly no: choose a simpler tool. If WordPress is on your shortlist, Astro versus WordPress is a fair comparison from official documentation.
Where Radiance Impact fits
Radiance Impact’s Technology division builds business websites and redesigns and can help you weigh a headless setup against something simpler. See the Technology page or contact us.
Sources
- An introduction to structured content, Sanity
- Content management systems, Astro Docs
- Rendering on the Web, web.dev (Google)
