One Design System, Every Drupal Multisite
Drupal multisite and Site Studio solve the platform layer. They give you shared infrastructure, shared modules and shared configuration across every site in your estate. But the front end is where brand consistency actually lives or dies. Adding a headless design system means every site gets brand updates, accessibility fixes and performance improvements from a single deployment.
The Multisite Promise and Its Limits
Drupal multisite is a powerful capability. A single codebase serves multiple sites, each with its own content, configuration and domain. Acquia Site Studio extends this further by letting site builders create layouts and components through a visual interface, reducing the dependency on front-end developers. For large organisations managing ten, twenty or fifty sites, these tools solve real problems. Shared security patches. Centralised module management. Consistent content modelling. But they solve the platform layer. The front-end layer often remains fragmented. Each site gets its own theme, its own CSS, its own component implementations. A brand update means touching every theme individually. An accessibility fix needs applying site by site. Performance improvements are local, not systemic. The platform is consolidated. The user experience is not.
Governing the Front End
A headless design system sits above the CMS layer and governs the front end across every site in the estate. It consumes content from each Drupal site through JSON:API and renders it through a single, shared component library. The components are controlled by design tokens that encode the brand: colours, typography, spacing, grid behaviour, motion, elevation. When the brand evolves, you update the tokens. Every site reflects the change immediately. When an accessibility issue is identified in a component, you fix it once in the design system. Every site benefits. When a performance optimisation lands in the rendering layer, every site gets faster. This is governance through architecture rather than through process documents and brand guidelines that nobody reads after the first week.
How It Works with Site Studio
Site Studio provides a visual page building experience within Drupal. Site builders assemble pages from components without writing code. The question is where those components come from. In a traditional Site Studio setup, components are defined within the Drupal theme layer. They are powerful but coupled to the Drupal rendering pipeline. In a headless design system model, Site Studio defines the content structure and layout intent. The headless front end handles the rendering. Site builders still use the familiar drag-and-drop interface to assemble pages. But the components they place are rendered by the design system, not by Drupal Twig templates. This means site builders retain their autonomy and their tools. The design system provides the visual governance. Both layers do what they are best at. Content management stays in Drupal. Brand consistency is enforced by the design system.
What Changes Across the Estate
The brand team gets a single source of truth for digital brand expression across every Drupal site. When the brand guidelines change, the design tokens update and every site reflects the new direction without individual theme work. The security team gets a unified front-end surface to audit. Instead of reviewing fifty different themes with fifty different dependency trees, they audit one component library. The content teams keep their Drupal admin interface, their workflows and their Site Studio layouts. Nothing changes in their daily experience. The finance team stops paying for individual theme maintenance across dozens of sites. The accessibility team fixes issues once and knows the fix applies everywhere. And when a new site needs to join the estate, it inherits the full design system on day one. Not after a six-week theming sprint. On day one.