Headless vs. Traditional

By Jared Lyvers, ldnddev — March 16, 2026

Every few years, a new architecture gets declared the future of web development, and everyone scrambles to retrofit their stack. Headless CMS had its big moment — the think pieces wrote themselves, the conference talks multiplied, and agencies started pitching it as the answer to every client problem.

Now that the dust has settled a bit, the picture in 2026 is more nuanced. Headless CMS is genuinely the right choice for certain projects. Traditional platforms like WordPress and Drupal are still the right choice for others. And there's a middle ground — decoupled or hybrid architectures — that serves use cases both ends of the spectrum miss.

We work with all three approaches at ldnddev. Here's an honest breakdown of where each one stands, who it's right for, and how to think about the decision for your next project.

What We Mean by Traditional, Headless, and Decoupled

Before diving into tradeoffs, it helps to be clear on terms — because these get conflated constantly.

Traditional CMS (WordPress, Drupal in coupled mode): The CMS manages both content and presentation. Content editors log into an admin interface, content gets stored in a database, and the CMS renders it into HTML pages. The frontend and backend are tightly integrated. This is how the majority of the web still works.

Headless CMS (Contentful, Sanity, Strapi, Prismic): The CMS handles only content storage and delivery. It exposes content through an API — typically REST or GraphQL. The frontend is completely separate, built with whatever framework you choose (Next.js, Astro, SvelteKit, etc.), and pulls content from the API at build time or request time. The CMS has no opinion about how content gets rendered.

Decoupled CMS (WordPress with a headless frontend, Drupal in decoupled mode): This is the middle path. The CMS still manages content and provides an admin interface, but it also exposes an API for a separate frontend layer. Drupal is particularly well-suited to this — it has robust API-first capabilities built in. WordPress can do it too via the REST API or WPGraphQL. You get the editorial familiarity of a traditional CMS with more flexibility on the frontend.

Where Headless CMS Has a Real Advantage

Let's give headless its due. For the right use cases, it genuinely outperforms traditional architectures.

Multi-channel content delivery. If your content needs to appear on a website, a mobile app, a digital signage system, and a third-party integration simultaneously, headless is the natural fit. You store content once and deliver it anywhere via API. A traditional CMS makes this awkward because it's designed around producing web pages, not raw content payloads.

Frontend flexibility. Headless CMS lets your frontend team work with whatever framework they're best at without being constrained by what the CMS supports. If you want to build with Astro for performance, or Next.js for a complex interactive experience, headless gets out of the way and lets you do that.

Performance ceilings. A statically generated site pulling content from a headless CMS at build time can achieve performance benchmarks that are difficult to match with a server-rendered traditional CMS. Every page is pre-built, lives on a CDN, and requires no database query to serve. For high-traffic marketing sites where Core Web Vitals matter, this is a real advantage.

Developer experience for modern teams. Engineering teams accustomed to modern JavaScript frameworks often find headless setups more comfortable to work in than the PHP-based plugin ecosystems of WordPress or Drupal's theming layer. If you're hiring frontend developers who've never touched PHP, a headless architecture removes friction.

Where Traditional CMS Still Wins

Here's the part that doesn't get written about as often: traditional CMS platforms are still the right choice for a large share of real-world projects, and the reasons are practical, not sentimental.

Content editor experience. WordPress and Drupal have spent years building editorial interfaces that non-technical users can actually operate. The Gutenberg editor in WordPress, Drupal's Layout Builder — these are mature tools that content teams understand. Many headless CMS platforms have caught up significantly, but the polish and ecosystem of plugins, workflows, and user documentation that comes with WordPress or Drupal is still hard to match for organizations with large content operations.

Total cost of ownership. A headless setup almost always means more frontend development work. You're not getting a pre-built theme — you're building a custom frontend from scratch. That's fine when the project budget and timeline support it. For a small business website, a local service company, or an organization that needs to be self-sufficient after launch, the ongoing cost of maintaining a custom headless frontend is often not justified by the benefits.

Plugin and extension ecosystem. WordPress has over 60,000 plugins. Need e-commerce? WooCommerce. Need a membership system? There are five mature options. Need event management, booking, forms, SEO tooling, email marketing integration? It's all there, it's tested, and it works. Building equivalent functionality against a headless CMS from scratch takes significantly more time and money. That cost has to be justified by what you gain.

SEO and content workflows. Both WordPress has a mature SEO ecosystem (Yoast, RankMath) with features like real-time content analysis, schema markup generation, and sitemap management built around the editorial workflow. Replicating that in a headless setup requires more custom work and careful integration with your frontend build process.

Drupal: The Platform That Plays Both Sides

Drupal deserves a separate mention because it occupies a unique position in this conversation. As of Drupal 10 and into 2026, it's genuinely both — a capable traditional CMS and a strong API-first content platform.

Drupal's JSON:API and GraphQL modules are stable, well-maintained, and built to spec. Organizations running Drupal as a traditional CMS can expose the same content through an API for a decoupled frontend, a mobile app, or a third-party integration without a separate headless CMS license or platform. The content modeling capabilities in Drupal — custom entity types, field collections, complex relationships — translate cleanly to API-delivered structured content in ways that WordPress's data model sometimes struggles with.

For enterprise clients with complex content requirements, multi-site needs, or strict security and compliance demands, Drupal in a decoupled configuration is frequently the most cost-effective architecture. You're not paying for a separate headless CMS platform, your content team gets a familiar editorial interface, and your frontend team gets clean API access to well-structured content.

This is an architecture we recommend frequently for mid-to-large clients where content complexity is high but the full headless approach would be overkill on cost or editorial experience.

Headless CMS Platforms Worth Knowing in 2026

If headless is the right call for your project, the platform landscape has matured significantly. A few worth knowing:

Contentful is the enterprise standard — robust, well-supported, with strong tooling and a large ecosystem. It's pricier than alternatives, and the pricing model can surprise you as content volume scales. Best for large organizations with budget to match.

Sanity has become a favorite among development teams for its flexible content modeling (GROQ query language, portable text), real-time collaborative editing, and developer-friendly APIs. It's competitively priced and has a strong community. A good choice for projects where content structure is complex or non-standard.

Strapi is open source and self-hostable, which makes it attractive for teams that need control over their infrastructure or want to avoid recurring SaaS costs. The tradeoff is that you own the hosting and maintenance. Best when your team has the capacity to manage it.

Prismic sits in the middle — simpler than Contentful, more opinionated than Sanity, and well-suited to marketing sites and content-focused projects that don't need complex data modeling.

How We Approach the Decision

When a client comes to us for a new web project, the CMS architecture question usually comes down to a few core questions:

Who is maintaining the content, and how technical are they? If the client's marketing team is going to be in the CMS every day and they're not developers, editorial experience matters a lot. Traditional CMS wins here more often than not.

Does the content need to live in multiple places? Website plus mobile app plus third-party integrations? Headless or decoupled makes more sense.

What's the frontend complexity? A marketing site with standard page types and a moderate design system is very different from a complex interactive platform with custom user experiences. The more custom the frontend, the more headless starts to make sense.

What's the realistic long-term maintenance picture? Who's going to update this in two years? If the answer is the client themselves with limited technical resources, a WordPress or Drupal site with a maintained theme is usually more sustainable than a custom headless frontend that requires a developer to update dependencies.

There's no universal right answer. The right CMS architecture is the one that fits your content model, your team, your budget, and your long-term maintenance plan. What we'd caution against is choosing headless because it sounds more modern, or sticking with traditional because it's familiar. Both decisions can cost you.

Until next time, Jared Lyvers