Headless WordPress vs traditional — when do you actually need each?

Headless WordPress trades engineering complexity for editorial flexibility. The trade is worth it in roughly three specific scenarios. It is a net loss in roughly five common scenarios. Knowing which is which is the only WordPress-architecture decision that matters in 2026.

The short version: in a traditional WordPress build, the same PHP application stores content AND renders the HTML the visitor sees. In a headless build, WordPress is reduced to the CMS layer; a separate frontend application (typically Next.js or Astro) pulls content from WordPress over a REST or GraphQL API and renders the user-facing site. The architecture sounds elegant. It is also dramatically more expensive to build and maintain, and most clients should not adopt it.

What “headless” actually changes

Three concrete changes happen the moment you go headless. Each has a downstream effect that founders rarely anticipate.

Change 1 — Two technology stacks instead of one.

Traditional WordPress is PHP, MySQL, and the WordPress theme — one engineering stack, one codebase, one deploy pipeline. Headless WordPress is PHP + MySQL on the backend AND a Node.js + React frontend, often deployed to Vercel or Netlify, often pulling data through GraphQL via WPGraphQL. That is two technology stacks, two engineering disciplines, two CI/CD pipelines, two monitoring setups, two security postures. The team you need to maintain it doubles in scope, even if the volume of work does not.

Change 2 — Editors lose what makes WordPress feel like WordPress.

The WordPress editing experience — block editor, live preview, “view post” right after publishing — is built on the assumption that WordPress controls the frontend. When you go headless, that assumption breaks. Live preview stops working by default; you need a custom preview implementation in the headless frontend. The “view post” button might point to a URL that takes 30 seconds to rebuild because static-generation has to revalidate. Plugins that inject content into the frontend (related-post widgets, sidebar plugins, in-content shortcodes from forms or galleries) often stop working entirely because they expect a PHP-rendered page.

Editors notice this within the first week. The complaints we hear most often: “I can’t preview my changes.” “The page takes forever to update after I publish.” “The form I built in Gravity Forms isn’t showing on the frontend.” Each is fixable with engineering, but the fixes are real work that does not exist in a traditional build.

Change 3 — Plugin ecosystem becomes selective.

Many WordPress plugins assume they own the frontend. Yoast SEO outputs meta tags into the rendered HTML; in headless, you need WPGraphQL Yoast or similar to pipe those tags into the Next.js head. Contact Form 7, Gravity Forms, WPForms — each works on the backend but does not render in the frontend without custom integration. Page builders (Elementor, Divi, Beaver Builder) effectively do not work at all because they render frontend HTML that headless ignores. WooCommerce works, but you need WooCommerce Headless or similar to bridge the gap.

The clean way to think about this: in headless WordPress, you can use any plugin that exposes its data through the API. You cannot use any plugin that assumes it controls the frontend rendering. That filter rules out a meaningful percentage of the plugin ecosystem.

The three scenarios where headless earns its complexity

Scenario 1 — You need to serve content to multiple frontends.

If the same content has to appear on a website, a mobile app, a digital signage system, an in-store kiosk, and a smart-TV app — five frontends, one source of truth — headless is the right answer. WordPress as the CMS, five clients consuming the same API. We have built this for retail brands and media companies; it is a legitimate use of the architecture.

Scenario 2 — Your frontend is a React application that needs to be a React application.

If the user-facing site is a real React app — heavy client-side interactivity, state management, dashboard-style interfaces, real-time features — and WordPress is the CMS that powers the marketing surfaces, headless makes sense. The React app needs to be a React app for product reasons; using WordPress to render a React app via PHP is the wrong direction. We have built this for SaaS companies where the marketing site and the in-app help centre share content but the in-app experience is React.

Scenario 3 — You’re at the scale where static generation matters.

Very large content sites — publishers with hundreds of thousands of posts, university sites, large brand sites with extensive editorial — can benefit from static generation at the edge. With headless WordPress and Next.js’s ISR (Incremental Static Regeneration), every page becomes a static HTML file served from a CDN, with sub-100ms TTFB globally. Traditional WordPress can approximate this with full-page caching, but headless + static-generation is the cleaner architecture at that scale.

The five scenarios where headless is a net loss

Marketing site for a small or mid-size business. The complexity overhead does not pay back. Traditional WordPress on a managed host is faster to build, cheaper to run, and easier for marketing teams to operate.

Content site under 10,000 posts. Traditional WordPress with edge caching matches headless performance at this scale, with one-tenth the engineering work.

E-commerce on WooCommerce. Headless WooCommerce exists and works, but the development cost is several times higher and most of WooCommerce’s flexibility (theme customisation, in-product upsells, custom checkout flows) becomes engineering work rather than configuration work.

Sites where the editorial team needs WYSIWYG and live preview. Building those things back into a headless setup is possible but expensive and rarely as smooth as the native experience.

Sites where the budget is “as cheap as possible.” Headless WordPress is roughly 2–3× the build cost of traditional WordPress and roughly 1.5–2× the ongoing maintenance cost. If budget is the constraint, traditional WordPress with strong performance work delivers better outcomes.

The middle path: traditional WordPress, very well built

For about 80% of the clients who ask us about headless, the right answer is not “go headless” — it is “do traditional WordPress properly.” A well-built traditional WordPress site on a modern managed host (WP Engine, Kinsta), with a custom theme, minimal plugin footprint, full-page caching at the CDN edge, and modern PHP, performs nearly identically to headless WordPress on Core Web Vitals. It costs roughly half as much to build, half as much to maintain, and the editorial experience stays intact.

Going headless because “WordPress is slow” is often a category error. Slow WordPress is a build-quality problem, not an architecture problem. Fix the build quality and the speed problem disappears, without taking on the headless complexity tax.

What good headless WordPress looks like (if you do need it)

Three concrete recommendations from the headless builds we have shipped:

Use Next.js, not pure React. Next.js gives you ISR, image optimisation, edge functions, and the React Server Components model — all of which matter for performance and SEO. Pure React (Vite + React Router + a custom build pipeline) gives you a worse SEO and performance story for a content site.

Use WPGraphQL plus ACF GraphQL. The REST API works but is verbose and harder to query. WPGraphQL gives you a strict schema, faster queries, and better tooling. Pair it with ACF Pro and WPGraphQL for ACF if you use custom fields, which you will.

Build the preview workflow first. Editors will use the preview button before they use anything else. If preview takes 30 seconds or fails silently, editorial trust evaporates within the first week. Invest in a custom preview route in Next.js that pulls draft content directly from the API and renders it on demand. This is not optional.

Plan for the hosting reality. A typical headless setup runs WordPress on a managed WordPress host AND a frontend on Vercel or Netlify. You are paying two hosting bills. Build the cost into your year-three plan, not just your launch month.

The honest recommendation

If you have to ask whether you need headless WordPress, you probably do not. The architecture serves specific problems — multi-channel content distribution, React applications that need to be React applications, very large content sites where static-generation pays back. For everything else, traditional WordPress, built with the same engineering care, gives you the same outcomes at half the cost.

At Dream Steps Technologies we have built both. We have rebuilt several headless sites back to traditional WordPress because the team that inherited the headless build could not maintain it. We have built one or two traditional sites into headless because the business genuinely outgrew the architecture. The decision is not technical fashion; it is fit. Make it on fit.

Common questions