Blog
An architecture choice, not an upgrade.
When headless Drupal solves real problems, and when it just adds work without any real benefit.
Headless Drupal is an architectural choice, not an upgrade.
You take the frontend out of Drupal and build it separately, and Drupal delivers the content as structured data.
That solves real problems, but it adds work that only becomes visible after launch.
This article looks at the trade-off from your side: what it asks of your organisation, what you get back, and when the answer is no.
What the setup involves technically and how I run such a project is covered on headless and decoupled Drupal.
What headless changes about your project
Headless moves the rendering of your pages from Drupal to a separate application.
Drupal remains the content model, the permissions and the editorial environment, and delivers the content through JSON:API in core or through the GraphQL module.
The frontend becomes its own project in Next.js, Nuxt or Astro, with its own repository and release cadence.
Everything Drupal used to hand you, from metatags to forms, search and language routing, you build again there.
You buy freedom in the presentation layer and pay for it with work Drupal otherwise did for you.
What headless asks of you on top
The cost of headless sits in the maintenance, not the build.
Four items always come back.
Two codebases instead of one
Every change to a content type touches two projects.
Adding a field is five minutes of work in Drupal, but the frontend also has to fetch, render and test it.
Your version management doubles too: Drupal 11 is the stable line at 11.4.x, Drupal 12 is released in the week of 7 December 2026, and your frontend framework has its own major versions.
Preview stops working automatically
Preview is the item that gets forgotten most often.
On a classic Drupal site, an editor sees an unpublished revision straight away, in the real layout.
Headless needs its own route for that, a secured token and an environment that rebuilds fast enough.
The same goes for layout: every block your editorial team places is a component someone has to build.
Hosting and deployment double up
You have two environments running separately that need to work together.
Drupal with PHP and a database, the frontend with Node or a build step, plus a caching layer and cache invalidation the moment content changes.
That adds two deployment pipelines, and with every incident the question: is the problem in the backend, in the frontend, or in between.
Knowledge in your team, also in three years
Headless asks for two specialisms, or someone who genuinely masters both.
A Drupal profile that sets up the content model and the API layer correctly, and a frontend profile that keeps a JavaScript framework running in production.
The architecture doesn't change my rates, but it does change the number of hours and the number of roles.
What such profiles cost on the Belgian market is covered in what a freelance Drupal developer costs, my own hourly and daily rate is on rates.
For a frontend profile, the rate depends on the market for JavaScript specialists, so ask that separately.
What you get back for it
The benefits are real, but narrower than the stories suggest.
The strongest one is content you publish more than once: if the same articles, products or locations go out to a website, an app and a partner, then an API-first backend is the logical shape.
The second is an existing design system in React or Vue, because rebuilding that in Twig wastes the work already done.
The third is team structure, because two repositories let a frontend team and a backend team release independently.
The speed myth
Speed is the argument that comes up most often and holds up least.
A classic Drupal site with correct caching, optimised images and little JavaScript achieves comparable results in practice.
A JavaScript framework actually adds code the visitor has to download and run, so the gain depends on how the frontend is built, not on the architecture itself.
If your site is slow today, the cause is usually in that frontend and not in Drupal, so measure before you rebuild: why your PageSpeed score isn't your speed explains what you should measure instead, and Core Web Vitals for Drupal shows where the real gains are.
Want to outsource that work instead of rebuilding, then that runs through technical SEO and frontend performance.
Seven situations with a clear answer
This is how I answer the question in an intake.
Usually one of these situations decides it.
| Situation | Answer | Why |
|---|---|---|
| One website, editorial team in Drupal, no other channels | No | Double maintenance with no second consumer of your content |
| The same content goes to website, app and partners | Yes | Content you publish more than once belongs behind an API |
| Design system in React or Vue, with its own frontend team | Yes | You reuse components, teams stay independent |
| The site is slow and headless is meant to fix that | No | Measure first where the time is being lost |
| Marketing builds pages themselves and wants preview | Usually no | Layout freedom and preview cost the most build work |
| Application with logged-in users, Drupal supplies the data | Yes | Drupal is genuinely a backend here, the interface a separate product |
| You're on Drupal 10 and need to migrate before 9 December 2026 | No, not now | Two changes in one move makes it needlessly risky |
That last one deserves an explanation.
Drupal 10 reaches end of life on 9 December 2026 and 10.6.0 is the last minor release, so many organisations now have a hard deadline.
What that date actually asks of you is covered in Drupal 10 loses support on 9 December 2026.
Do the migration and a new frontend in one move, and if something breaks you won't know which change caused it.
First to a supported version, then the architecture question: Drupal migration and upgrade.
The middle way that fits more often
Between fully headless and fully classic sits a variant that works out better in most projects.
Drupal renders the pages, and only the parts that genuinely need a rich interface, a configurator, a map, a filterable search module, become components that call the API.
You keep preview, layout management and multilingual support in core.
Frontend freedom only where it's needed, rather than everywhere.
That middle form is what I mean by decoupled Drupal, and it's the proposal I make most often.
Accessibility shifts to your side
In a headless setup, you're responsible for all the semantics yourself.
In the classic setup, Drupal core delivers correct HTML and a foundation for screen readers, and that's exactly why Drupal is more accessible than most CMSes.
Rebuild the frontend, and you start from zero: headings, labels, visible focus, status messages and route changes you set correctly by hand, and you test them yourself against the four principles of WCAG.
The European Accessibility Act, directive 2019/882, has applied since 28 June 2025, with WCAG 2.2 level AA and EN 301 549 as the standards.
Not sure whether those rules affect you, then first check whether the European Accessibility Act applies to your website.
If it does, this is a hard budget item, not something you can cut, and every release of your own frontend needs to go through the accessibility tests you run yourself.
How I approach that is covered on digital accessibility.
You can reverse it, but it isn't free
An architectural choice you can't undo is a risk, so ask that question before you start.
The good news: in a headless setup, Drupal stays a fully-fledged Drupal site.
The content model, the permissions, the revisions and your editorial environment are all still there, so you can later hand the display back to a Drupal theme.
What you don't get back is the investment in the frontend and everything you rebuilt there: components, routes, forms and the accessibility work that went into it.
The other way round, the step is smaller.
Build classic now, and if it turns out in two years that a second channel is genuinely needed, that same site can deliver the content through JSON:API without you having to overhaul the content model.
That difference in risk is an argument for starting classic while you're still unsure.
Who maintains the frontend in three years
This is the question asked least often in intakes, and the one that turns out most expensive later.
You can hand a Drupal site over to almost any Drupal agency for maintenance.
A custom-built frontend in a JavaScript framework is more specific, and whoever built it knows it best.
So ask yourself who does the security updates for that framework, who fixes the build pipeline when it breaks after a version jump, and who knows the components once your editorial team wants something new.
If that role doesn't sit in-house, put it in a contract, for example through an agreement for Drupal maintenance and support or by hiring a freelance Drupal developer for a fixed number of days.
A headless setup without a named owner for the frontend ages faster than a classic site, simply because there are more parts that need attention.
Three questions that decide the choice
- How many channels consume the same content today, and which ones are planned within two years?
- Who maintains the frontend in three years, and can you replace that role?
- What does the editorial team need to do itself: update text, or assemble pages with preview?
A genuine second channel, a team that carries the frontend, and an editorial team that only manages content, make headless defensible.
Missing one of those, and a well-built classic Drupal site is the honest answer.
Not sure about the architecture?
Tell me about your situation via contact: which channels, which team, which deadline.
I'll look at your request and give you honest advice, even if that advice is that you don't need headless.
Frequently asked questions
Is headless Drupal faster than a classic Drupal site?
Not automatically, and often not.
A classic Drupal site with correct caching, modern image formats and limited JavaScript achieves comparable results.
A JavaScript framework, in fact, adds code the visitor has to download and execute, so the gain depends on how the frontend is built, not on the architecture itself.
What happens to preview and layout management when you go headless?
You rebuild both of those.
In a classic Drupal site, an editor sees an unpublished revision immediately in its real formatting, and headless requires its own route for that, a secured token, and an environment that rebuilds fast enough.
The same goes for layout: every block your editorial team places is a component someone has to build.
If your marketing team assembles its own pages, this is usually the argument for not going fully headless.
Who maintains the frontend of a headless site?
Someone with knowledge of the framework that frontend is built in, and that's a smaller pool than the Drupal market.
Count on security updates for that framework, a build pipeline that needs to work again after a version bump, and components someone needs to know as soon as your editorial team wants something new.
If that role isn't in your team, lock it down contractually before you start, since a frontend without an owner ages fast.
Can a headless site meet WCAG 2.2 AA?
Yes, but you build the accessibility entirely yourself.
The semantics Drupal core provides disappear as soon as you rebuild the frontend: you set up headings, labels, visible focus, status messages and route changes by hand.
Also count on testing every release of that frontend yourself, since there's no longer a theme layer doing the groundwork for you.
Can you roll back a headless frontend later?
Yes, because in a headless setup, Drupal remains a fully-fledged Drupal site.
The content model, the permissions and the revisions are still there, so you can later use a Drupal theme for display again.
What you lose is the investment in the frontend, so that choice is reversible but not free.
Should I migrate first or build headless first?
Migrate first.
Drupal 10 reaches end of life on 9 December 2026, so a supported version is the priority.
If you do the migration and a new frontend in one move, and something goes wrong, you won't know which of the two changes caused it.
Bring your site to a supported version first and answer the architecture question afterwards, from a working starting point.
A question about this topic?
Briefly describe your situation, and I'll let you know what's going on and what it would cost. No sales pitch.
