Why headless

What the head was

A headless CMS stores and serves content through an API and leaves rendering to whatever front end you build. The head was the theme and the templates, the part that turned stored content into a page. Remove that part and you have content available to a separate application.

Content is data

My first reason is that content is data. An article has a title, a body, and whatever other fields its model defines. A page is a rendering of that article. Treating the article as data gives you a better starting point than treating its current page as the thing you are storing.

The same source can feed a site, an app, a feed, or a script. You do not have to enter the content again for each destination. Each consumer can take the fields it needs and decide what to do with them.

There is still work in each consumer. An API does not design your app or write your feed. That work belongs with the consumer, where the requirements for its output are clear.

The front end is yours

My second reason is control over rendering. I want to choose the framework, the host, and how the front end produces its pages. I do not want a theme system making those decisions for me.

If you have worked with WordPress, you know what a theme is responsible for. Headless moves that responsibility into the front end you build. You own the templates because they are part of your application.

It also means the choice is yours to maintain. Choosing your own front end includes building it and taking responsibility for it. That is a reasonable trade when a team actually wants that control.

The schema is the contract

My third reason is the schema. The content model defines the API, and types follow from that model. The front end and the content team can agree on a shape instead of agreeing only on a page.

That changes what I want to discuss when modelling content. We need to agree on which fields belong to a type and which parts of the content should be shared. Those decisions describe the data the front end will receive.

The schema is the contract.

The front end depends on a shape, and changes to that shape need attention. Moving rendering out of the CMS does not remove the need for agreement.

A service with an API

A CMS should behave like any other service with an API. Your pages do not run through the CMS's own code, whether that is WordPress's PHP or anything else, and the site is not assembled from plugins that each bring their own data shapes, update cycle and attack surface.

The CMS stores and serves content, and the front end renders it. When something breaks, it is clear which side broke.

When I would keep the head

For a brochure site with an editor who wants to drag things around a page and never touch code, and no developer building the site, I would keep the head. Building a separate front end adds a job that editor did not ask for. I would choose a tool that fits the way they want to work.

For a small shop where the storefront and the catalogue are one product and nobody wants to build a front end, Shopify or WooCommerce handles it end to end. Headless pays off when the catalogue feeds more than one storefront, which is why a headless e-commerce layer is on Shapio's roadmap.

The same goes for any team with no developer. Headless gives you a front end to build. If nobody wants to build one, use the thing with the head.

Changing the contract

The usual headless cost arrives when the model changes. Strapi disables its content-type builder in production, and Payload defines fields in TypeScript. Model changes can mean code, commits, and a deploy.

Shapio's position is that the model should be data too. Change a type in the admin while it runs in production, and the REST and GraphQL APIs serve the new field on the next request. There is no rebuild, restart, or deploy for that model change.

Schema and content ship together in a change set, recorded as a publication snapshot that a build can pin. Every page in the build then sees one consistent moment. That is the contract I want to build against.