Headless CMS

The head in the name is the part that renders pages. A traditional CMS or site builder owns it, and that ties your content to its templates and hosting. A headless CMS leaves it out and answers requests for content, which a separate front end turns into the pages visitors see.

Because content lives in structured fields rather than page blocks, it can be reused across pages and queried like data. That shifts work toward the start of the project. The content model has to be designed, since nothing about the tool will force a good one.

Why it matters for a marketing site

In a site builder, the content, the design and the hosting are one product, so outgrowing one means leaving all three. Headless separates them. Editors keep a writing interface, developers keep the code, and a redesign does not touch the content. The trade is that you now have two systems, and someone has to connect them.

How I handle it

I use Sanity. Editors change content there, and the site renders it through Astro on Cloudflare. All three accounts belong to your organization, and I am invited in rather than holding the keys. If one person edits a five-page site a few times a year, you do not need this, and a builder is the honest answer.

Example

Say a marketer corrects a price in the CMS and publishes. The CMS tells the build, the site regenerates the affected pages, and the change goes live with no developer involved. Adding a new kind of section is different: that still needs a component, because the CMS holds content, not layout.

Common mistakes

• Expecting a visual canvas for free. Builders give you one by default. In a headless setup, preview has to be built and maintained.
• Modeling pages instead of content. A schema that mirrors the current layout keeps the coupling headless was supposed to remove.
• Forgetting who gets paged. A builder bundles the hosting. With headless, the site, the CMS and the deploy each have an owner, which should be written down.