Drupal's editorial power. React's frontend speed.
Headless Drupal gives you both halves: editors keep Drupal's workflows, permissions and structured content; visitors get a Next.js frontend that loads like a static site. It's our favourite architecture for large content organisations — and we'll tell you plainly when it's more architecture than you need.
What headless Drupal buys you
One content engine, many frontends
The same structured content feeds your website, mobile app, kiosks and partner sites via JSON:API or GraphQL — written once, published everywhere.
Editorial workflows intact
Moderation states, granular permissions, scheduled publishing, multilingual — the governance features organisations choose Drupal for survive the decoupling untouched.
Performance by architecture
Next.js renders statically where possible, so pages arrive pre-built from a CDN. Core Web Vitals stop being a battle and become a property of the design.
Security surface reduced
Drupal lives behind the frontend, not exposed to the internet's full attention — a meaningful hardening win for high-profile targets.
Redesigns without replatforming
The next rebrand touches the React layer only; content and editorial workflows carry on unmoved. Decoupling is an investment the second redesign repays.
Preview solved properly
The classic headless complaint — "editors can't preview" — is an engineering problem with a known solution. We build draft preview in from the start.
You're building two systems. Be sure it's worth it.
Headless costs more than a well-themed Drupal site — you're building and maintaining a frontend application alongside the CMS. Simple headless projects start around £15,000 and most land £20,000–£50,000. If your content is straightforward and one website is the only channel, traditional Drupal theming delivers 90% of the result for well under half the cost — and we'll recommend exactly that when it's true. Our Drupal team and React team are the same team, so we have no incentive to oversell either half.
What a headless Drupal project involves
The work divides into three streams, and the order matters. Content modelling comes first — before any React is written. In a headless build your content types, fields and relationships become the API contract the frontend depends on, so a badly modelled entity costs twice: once in Drupal, once in every component consuming it. We design the model with your editors in the room, because the second-biggest headless failure mode (after cost surprises) is an editorial experience nobody consulted the editors about.
The API layer is where discipline pays. We expose exactly what frontends need — versioned, documented, cached — rather than dumping Drupal's internals over JSON:API defaults and hoping. Preview is engineered here too: editors see drafts rendered in the real frontend before publishing, which is the feature that decides whether your editorial team loves or resents the architecture. The frontend stream then builds against a stable contract: Next.js components mapped to your design system, static generation for content pages, server rendering where personalisation needs it, and Core Web Vitals treated as a build requirement rather than an aspiration.
Timescales, honestly: a focused headless build — one site, sane content model — typically runs three to five months end to end, with the content model agreed by week three and the first real pages rendering by mid-project. Multisite estates and app-plus-web platforms run longer. The two-system nature also changes maintenance: Drupal core updates and frontend dependency updates on separate cadences — which is why our care plans cover both halves as one product.
Common questions
JSON:API or GraphQL?
JSON:API ships with Drupal core and covers most builds; GraphQL earns its setup cost when frontends need precise, varied queries. We decide from your content model, not fashion — and document the reasoning.
Can we go headless with our existing Drupal site?
Often, yes — if the content model is sound, the CMS stays and we build the new frontend against it. If the model needs work, that surfaces in a free audit first.
What about SEO on a React frontend?
Handled by rendering strategy: pages are server-rendered or statically generated, so search engines see complete HTML. We treat SEO as engineering — metadata, redirects and sitemaps are deliverables, not hopes.
How do editors preview content in a headless setup?
Through engineered draft preview: an editor viewing an unpublished node gets a secure link that renders the draft in the real Next.js frontend, exactly as visitors will see it. It's extra build work — which is why agencies skip it and editors revolt — so we treat it as a launch requirement, not an optional extra.
Does headless Drupal help with accessibility compliance?
It can, done properly: you control every element the browser renders, so WCAG 2.2 AA is enforced at the component level and tested in CI. Done carelessly, client-side rendering introduces new failures — focus management, announcements, keyboard traps. Our builds treat accessibility as a component-library concern, so it's consistent everywhere by construction.
Talk architecture with people who've shipped it
Tell us about your content, your channels and your team. You'll get an honest recommendation — headless, traditional, or hybrid — usually the same day.
Discuss headless Drupal