
Headless, decoupled, and what the words are doing
Headless means the CMS does not render pages. That is the whole definition and it is worth saying plainly, because the word has been used to sell a lot of things that have nothing to do with it.
The term caught on around 2015 and 2016, largely through Contentful, and it named something that already existed. People had been putting APIs in front of CMSes for years. Giving it a name turned an architecture into a category, and a category can be sold.
What headless specifies is narrow. There is no theme layer. Content comes out as JSON. What you build with it is your problem.
What it deliberately leaves open is everything else, which is why systems that share nothing else are all called headless. Contentful is a hosted service where the model is edited in a web UI. Strapi is a Node application you run yourself with the model in code. Sanity keeps its own query language and a real-time document store. Directus points at an existing SQL database and generates an admin over whatever is already in it. Payload is a Node application where the model is a TypeScript config and the admin is generated from it.
Those are five different products. The only property they share is not rendering your pages.
The distinction I find more useful than headless is where the model lives, because that predicts how the thing feels to work with. Model in a hosted UI means non-developers change it and developers find out afterwards. Model in code means it is reviewed and deployed, and a marketing request becomes a ticket. Neither is correct. They suit different organisations, and picking the one that does not match yours produces friction for years.
Then there is the thing everyone discovers in month two, which is preview.
A coupled CMS has preview for free, because the thing that renders the page is the thing holding the draft. Decouple them and preview becomes a feature somebody has to design: the frontend needs to fetch unpublished content, which means it needs credentials, which means you now have an authenticated rendering path that only exists for previews and is consequently the least tested path in the system. Every headless CMS has a preview story and none of them are as good as just looking at the page.
The second thing is that you have moved work rather than removed it. Menus, redirects, sitemaps and anything else that depends on the shape of the site now lives in the frontend, because the CMS no longer knows what the site looks like. That is correct, and it is also more code than the thing you were avoiding.
I still think it is the right default in 2025, mostly because the content outlives the site. Sites get rebuilt every three or four years. Content does not. Keeping it in a form that does not assume a particular renderer is the same instinct as not storing HTML in the database, applied one level up.