“Headless” means splitting your website in two: the CMS keeps managing content, but it stops rendering pages — a separate front-end application (usually React or similar) fetches that content and draws the site. Two systems instead of one, connected by an API.
Whether you need it comes down to one question: how many things consume your content?
When headless earns its complexity
When the answer is “more than a website.” A website and a mobile app. Content syndicated to kiosks, partner sites, or digital signage. A product where the front end genuinely is an application — interactive tools, dashboards, things a page-based CMS was never going to render anyway. In those cases one content pool feeding many heads is exactly the right shape, and Drupal in particular does the “content service” role well.
When it’s double the boat for the same lake
When the answer is “a website.” Then headless takes everything you maintain — hosting, updates, security, the developer relationship — and doubles it. Two codebases, two deploy pipelines, two things that can break, and a rebuilt-from-scratch version of everything the CMS gave you free: previews, page-building, SEO plumbing, redirects, forms. The editing experience usually gets worse, because “edit the page and see it” stops being how anything works.
We say this as people who build React happily: a brochure site done headless is the most common over-build we see, and it produces a specific kind of orphan — when the developer leaves, the front end quietly stops compiling, and a site that would have been a routine rescue becomes two rescues stapled together.
The honest test
Count the heads. Zero or one: stay monolithic — a well-chosen CMS rendering its own pages remains the most maintainable, most rescuable, most boring architecture there is, and boring is a feature. Two or more real ones, funded and actually being built: headless is genuinely the right call — budget for two systems’ worth of upkeep from day one, with eyes open.