What "headless" actually means
In a traditional CMS, the same system that lets an editor write a blog post also renders the HTML page a visitor sees — the "body" (front end) is attached to the "head" (content management).
A headless CMS keeps only the content-management half: editors still get a familiar interface to create and organize content, but instead of rendering a page, the system exposes that content through a REST or GraphQL API for any front end to fetch and display however it wants.
What you gain, and what you give up
The main win is front-end freedom: the same content can power a React web app, a mobile app, and a smart-TV interface from one source, and the front-end team isn't constrained by whatever templating language the CMS happens to support.
The tradeoff is that a headless CMS gives editors no visual preview of the final page by default (what they see in the editor isn't what a visitor sees, unless you build a separate preview feature) and the project now has two systems to run and secure instead of one.
When it's actually worth the tradeoff
It earns its complexity when content genuinely needs to reach more than one front end (web plus a mobile app, for instance), when the front-end team wants a specific framework the CMS doesn't natively support, or when the project needs to scale content delivery independently from a specific rendering technology.
For a straightforward single-website project with one content editor and one front end, a traditional CMS is usually simpler to run day to day — headless is a real architectural upgrade for a specific set of needs, not a strict upgrade over traditional CMS in every case.