What Is A Headless CMS And Why You Should Use One

A traditional CMS stores a page. A headless CMS stores the thing the page is about.

Content sits in a store as structured records, so a product is a name, a price, an image and a set of relationships rather than a page. An API hands those records out, and the website is a separate application that asks for what it needs and decides how it looks. The head is the presentation layer, and once you take it off you can attach as many as you like: the site, the app, the screen in the foyer, the assistant answering questions about the client's products.

Content models come first

Before anyone opens Figma, somebody has to decide what a case study actually is at this organisation. Which fields exist, which are mandatory, whether an author is a name typed in a box or a record with a bio that updates everywhere at once.

That is the whole job. Most of the painful scope arguments I have sat through were content problems found halfway through build and renegotiated as design changes. Get the model right up front and everything after it is assembly.

What your agency gets

• No plugin update treadmill. Nothing runs on the site that your team did not choose, so there is no monthly round of updates, compatibility checks and hoping nothing broke.
• Much lower chance of a client being compromised on your watch. On a plugin-built site almost all the security holes are in the extensions, and every one of them is a decision somebody else made for you. A headless build runs a short dependency list you picked deliberately.
• Content modelling moves the hardest thinking into discovery, where it is scoped and billable, instead of surfacing mid-build as a fight about scope.
• Components become the system rather than documenting it. Build the card once, change it once.
• The component library you build for one client is a real head start on the next.
• A junior can ship a new template without being able to break the system.
• Retainers stop being maintenance you cannot show anyone and become work the client can see the value of.
• Each new channel extends something you already built, so a four year rebuild cycle turns into an ongoing relationship. You stop selling websites and start holding the content layer.

What your client gets

• One edit, every channel. The product description is right on the site, in the app and on the screen in reception.
• Content that survives the redesign. Replace the front end and leave the store alone, so a decade of articles is an asset rather than a migration line in the next quote.
• Real roles and approvals. An editor drafts, a manager approves, a small group publishes, and there is a record of who changed what.
• No public admin login sitting on their website, and an editing environment that can sit behind their own single sign-on.
• Pages built in advance and served from an edge network, so speed holds up during the campaign that works.
• Preview links before anything goes live, and a rollback that takes one click instead of an incident.
• Cleaner SEO, because you control the markup. Every page ships the metadata and structured data you decided on, and nothing gets injected by a plugin nobody chose.

Choosing a platform

Group them by who will own the thing. If the client needs data residency or no vendor dependency, host it yourself with Payload, Strapi, or Directus, which is worth knowing because it sits over an existing SQL database rather than giving you its own store. If nobody wants to be a sysadmin, use Sanity for a complex model, Storyblok when losing edit-in-place is the objection you cannot get past, or Contentful at the enterprise end. For documentation and small sites where the developers are also the editors, TinaCMS or Keystatic keep content as files beside the code.

Do not pick before you understand the content model, and check who owns the vendor this quarter. Two of those names changed hands in the last eighteen months.

When I would talk a client out of it

A brochure site with one editor, one channel and a three year life. Higher setup cost, longer first build, front-end developers required, and modelling that has to happen before design. The payback never arrives, so say so. I would rather lose that job than rebuild it in eighteen months.

Further reading

• Google Search Central, Understanding page experience
• Next.js, Incremental Static Regeneration
• Vercel, How to choose a headless CMS in 2026

Written by: Jamie Esterman Crumb & AWIA Board Member

The Australian Web Awards recognise excellence across six core disciplines: Accessibility, Content, Design, Development, SEO, and User Experience. Subscribe to AWIA’s newsletter for 2026 awards updates, AWIA news and accessibility events as they’re released.