Headless Drupal — when it actually makes sense
Headless has been a popular term for a few years. Like all architectural choices, it suits some projects well and others not at all.
Headless Drupal means Drupal serves only as the backend — managing content, users, permissions and delivering data through an API. The frontend — what visitors actually see — is built with a separate technology: Next.js, Gatsby, Vue, React or another framework.
The alternative is "coupled" or traditional Drupal, where Drupal manages content and also renders HTML directly to the browser.
When headless is justified
Multiple channels, one content source
When the same content needs to reach a website, a mobile app, digital signage and partner APIs — headless is the natural choice. Drupal manages content in one place and each channel consumes it in its own way.
Demanding frontend requirements
When the frontend requires very fast loading, complex interactivity or application-like behaviour that is difficult to achieve with a traditional Drupal theme — a Next.js or similar solution can deliver better results.
Independent teams
When backend and frontend teams work with different technologies and release cycles, headless architecture gives them independence — the frontend does not depend on Drupal's release schedule.
When headless adds complexity without benefit
A simple content website
When the site is primarily informational — articles, pages, a blog — traditional Drupal delivers the same result with less complexity. Headless adds infrastructure, maintenance and development costs that a simple site does not need.
A small team
Headless architecture requires two separate competencies: Drupal backend and a frontend framework. If the team has one or two developers, traditional Drupal is often more practical — everything in one place.
Editors need live preview
In traditional Drupal, editors see changes immediately. In a headless architecture, live preview requires a separate solution — achievable, but adds work.
Technical options
Drupal supports headless use in several ways:
- JSON:API — built into Drupal core, covers most standard use cases
- GraphQL — more flexible query language, suitable for complex data structures
- Decoupled Router — helps the frontend follow Drupal's URL structure
Drupal is well prepared for headless use — JSON:API is mature enough to cover most projects without additional libraries.
Example: Haridussilm
An Estonian example of headless Drupal in production is haridussilm.ee — the Estonian Ministry of Education and Research's education data portal. Drupal acts as the backend, managing content and data served via API to a separate frontend.
WebPro assisted with the Drupal backend development for Haridussilm. It is a good illustration of when headless makes sense: data comes from multiple sources, is processed and exposed in structured form, while the frontend handles visualisation independently.
The hybrid approach
Many projects do not choose fully one or the other. Drupal can render most of the page traditionally while certain interactive parts — search, a calculator, filters — are built as separate React components.
This "progressively decoupled" approach is often more practical than full headless — it preserves Drupal's strengths (content management, accessibility, SEO) and adds frontend freedom where it is genuinely needed.
Summary
Headless Drupal is a powerful architectural choice for large multi-channel platforms where a dedicated frontend team is building a complex user interface. For most medium-complexity websites, traditional or hybrid Drupal is more practical and cheaper to maintain.
If you are evaluating architectural options, describe the project to us — we can help decide which approach best fits the actual requirements.
Kaido Toomingas
WebPro Company OÜ
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.