Headless CMS for a small business: when it makes sense and when it does not

A traditional CMS such as WordPress does two jobs at once. It stores and manages your content, and it also builds the pages visitors see using a theme. The back end and the front end live together.

A headless CMS does only the first job. It stores content and makes it available through an API. The website itself is a separate application, usually built with a framework such as Next.js or Astro, which fetches the content and turns it into pages.

The name comes from removing the head, meaning the presentation layer, from the content system. The same content can then feed a website, a mobile app, a digital signage screen or an email template.

Popular options include Sanity, Contentful, Storyblok, Strapi, Payload and Directus, some hosted as a service, some installed on your own server. WordPress itself can also be used headless through its API.

For the editor, the daily experience is similar: you log in, edit fields, upload images and publish. The difference is mostly under the surface.

Headless is not only fashion. There are concrete advantages, and they are worth separating from marketing claims.

• Speed. Headless sites are usually built as static or pre rendered pages served from a CDN, which makes them very fast by default and makes good Core Web Vitals easier to reach.
• Security. There is no public admin panel on the website domain and no plugin ecosystem exposed to the internet, which removes the most common attack surface of WordPress sites.
• Design freedom. Developers build exactly the interface needed instead of adapting a theme, so unusual layouts and interactions do not fight the platform.
• Structured content. Content is modelled as fields rather than free form pages, which keeps it consistent and reusable across languages and channels.
• Multilingual and multi channel projects. One content source can serve several websites, several languages or an app without duplicating work.

For a site where speed, security or several channels really matter, these benefits are significant.

The trade offs of headless are less visible in sales presentations, but they matter more for a small business than for a large one.

Every change to the site structure requires a developer. Adding a new type of section, a new page layout or a new form is code, not a plugin install. If you are used to adding features yourself, this is a real loss of independence.

There are two systems to host and maintain instead of one: the CMS and the website. Hosted CMS plans are often free at small volumes but can become costly with more users, locales or API usage.

Previewing content before publishing needs to be set up deliberately. Without it, editors publish blind and check the result afterwards.

The pool of developers who can maintain a headless site is smaller than for WordPress. If the agency that built it disappears, finding someone to take over can take longer and cost more.

And the initial build is usually more expensive, because the front end is custom rather than based on an existing theme.

Headless makes the most sense when at least one of these is true for your business.

• The website is an important sales channel and speed has a measurable effect on revenue, for example with paid traffic or a large volume of mobile visitors.
• You need several languages with a consistent structure, or the same content in a website and an app.
• The design or functionality is custom enough that a theme would need heavy modification anyway.
• You have ongoing access to a developer or an agency on a maintenance agreement, so structural changes are not blocked.
• Security is a priority and you want to avoid plugin updates as a monthly risk.

If none of these apply, a well built WordPress site or a website builder is often cheaper to own and easier to change yourself. A five page site for a local service business rarely needs a headless architecture.

If an agency proposes a headless setup, a few questions help you judge whether it fits your situation or just their preference.

Which CMS will be used, where will it be hosted and what will it cost per month as the site grows? Ask for the price at your realistic number of editors and languages, not the free tier.

What will you be able to change yourself without a developer? Ask them to show the editing interface and try creating a page and changing a section before signing.

How does preview work, and can you see a draft on the real design before publishing?

Who owns the CMS account, the code repository and the hosting? All three should be in your company's name, with the agency given access, not the other way around.

And what would it take for another developer to take over the project? A clear answer, with documentation and a common framework, is a good sign. Vague answers suggest you may be locked in.