[ShellfishMeme]

Because the web is moving away from pure content or shop pages to more holistic interactive experiences where you need to integrate content into complex flows that are more application than website. Plus you might want to reuse said content on mobile apps too. There it really pays off to have your content separated as structured data that you can query for.

[tannhaeuser]

Is that meant as satire or what? Structured content that an end-user can edit, query, share, comprehend, design, etc. is what you have with markup languages, and have had since over 30 years (SGML/HTML/XML). A "headless" CMS is just an API server eg. a tool for JS developers; you could use any JSON or GraphQL API wrapping tool you want (PostgREST, say), or code one yourself in a few lines of code. So I have to say "headless CMS" is really a pure marketing term, and IMHO utter pointless, as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with.

[ShellfishMeme]

> as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with

Sounds to me like you already made a good case for why those products exist.

Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications.

You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return.

Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc.

Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB.

Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless.