A quote says headless CMS. That's a category, not a product.

The word describes an arrangement, not a product

A content system normally does two jobs. It holds your content, and it turns that content into pages. A headless one keeps the first and drops the second. Content sits in a store with a structure you define, and anything that wants it asks over an API and gets back data. No layout, no page, no opinion about how it looks.

The head in the name is the front end, the part a visitor sees. Take it off and what's left is storage with a door in it.

Four names come up most often, and they aren't variations of one product. Contentful is a hosted service with content types set up in a browser. Sanity's editing interface is software you run and can change, in front of a content store Sanity operates. Strapi and Payload are open source, so you can run them on your own hosting, and Payload's content types live in code alongside the site rather than being clicked together. All four keep moving, so take features and plans from the vendor's own page on the day you compare them.

What it was built to fix

The older arrangement works right up to the second place your content has to appear. A page-based system holds your services inside the pages that display them, so a service description isn't something the business owns. It's part of a template.

Then a mobile app arrives, or a screen in a branch, or a partner listing your services on their own site. Somebody copies text out of a website, pastes it somewhere else, and the two versions start drifting.

Separating the store from the display fixes that, and it's worth being precise that this is the problem it fixes. Content lives once, in a structure, and every surface asks the same API for it. Change a service description and it changes on the website and in the app, because neither was holding a copy.

Editors stop editing pages and start editing records

This is the change your team will feel, so show it to them before anyone signs. In a page-based platform an editor opens a page and changes what's on it. Here they open a record, fill in fields and save. Where those fields turn up was somebody else's decision, made earlier.

For content that repeats, that's a real upgrade. A service has a name, a description, a lead time and three photos, everywhere it appears. Nobody can accidentally bold one description or give another a heading two sizes smaller. Translation gets easier for the same reason: a field is a known thing, and a paragraph buried in a page is not.

It also means the content outlives the site. When the design gets replaced the records don't move, because they were never part of it. Where a site is mostly one-off pages that are each different, though, the model works against you.

Where it stops, and it's the same place every time

Nobody can see the page. That's the ceiling, and most other objections are versions of it.

An editor typing a headline into a text box has no idea whether it wraps onto three lines on a phone. The preview a page-based platform gives away is, here, something somebody builds: a route through your front end that renders unpublished content, secured so it isn't public. Vendors sell tooling to help, and it still has to be wired in.

The second limit is that no ecosystem is waiting for the front end. A form, a site search, a redirect from an old URL, the metadata search engines read. On a page-based platform most of those are an afternoon and a plugin. Here each one is built or bought and wired in, which belongs in the estimate rather than in month four.

The third is composition. If your marketing lead wants to assemble a campaign page out of blocks, that has to be modelled as blocks on purpose, or every new layout goes back to a developer. Teams find this out after launch, when the first campaign page fits no type anybody defined.

If what you want is a colleague changing the site on a Tuesday without booking anyone's time, the Webflow and WordPress pages here describe the other side of this trade.

What it costs you in people

Buyers assume a hosted content store leaves nothing to look after. The store is somebody else's problem, and the front end is entirely yours: a codebase with dependencies that go out of date, a hosting arrangement, a build that must keep working, and no vendor who will fix it at two in the morning. This doesn't reduce the technical people you need. It moves them off the platform and onto your site.

That works when there's a standing arrangement with whoever built it, or a developer on staff. It's a poor fit when the plan is to build once and touch it rarely, because everything that rots is now on your side of the line.

So settle two things before comparing products. Who publishes, and whether they'll ever need to see a page before it goes live. Then who owns the front end in year two.