One CMS runs the site. The other feeds any front-end.
Traditional WordPress is one system doing both jobs. Headless separates the CMS from the front-end so you can build any experience on top.
What each one actually is
WordPress delivering both the admin and the front-end pages of your site.
Traditional WordPress is one platform — the admin edits content and PHP templates render pages. It's simple, mature, and battle-tested.
A CMS that serves content via API to any front-end you build (Next.js, mobile, apps).
A headless CMS (Sanity, Payload, Contentful, WordPress in headless mode) serves content via API. You build the front-end separately — usually on Next.js, Astro, or a native app.
Both sides side by side
Deeper into the differences
How they compare on the things that matter
An honest look at both sides
- +Simple ops
- +Mature ecosystem
- +Editor familiar to most
- +Fast to launch
- −Design bound by theme
- −Multi-channel means duplication
- +Front-end flexibility
- +Multi-channel from one CMS
- +Excellent performance defaults
- +Structured content
- −Higher upfront cost
- −Two systems to maintain
- −Preview requires wiring
Nuanced recommendations, not blanket ones
Simplicity wins.
Content flows to web + app + partner sites.
Front-end freedom on Next.js is the point.
Fewer moving parts, familiar editor.
Delivery architecture patterns
"Headless" is not one thing. These are the four architectures the label actually covers, with the trade-off each carries.
| Pattern | How content flows | Best for | Watch-out |
|---|---|---|---|
| Monolithic WordPress | Theme renders on request | Content sites, low interactivity | Perf ceiling, plug-in sprawl |
| WordPress + REST/GraphQL frontend | Next.js reads from WP | Existing WP investment, new UI | Two systems to maintain |
| Pure headless (Sanity/Contentful) | API-first CMS + custom frontend | Product surfaces, multi-channel | Editor UX must be designed |
| Git-based (Payload, Keystatic) | Content in the repo | Docs, engineering-led teams | Non-tech editors struggle |
| SaaS site builders (Framer, Webflow) | Vendor renders | Marketing-led, low custom | Lock-in + platform limits |
Signals that headless is the right move
- You publish to 2+ surfaces
Website + mobile app + kiosk + partner API — headless removes the duplication tax.
- Your frontend needs are outrunning WP themes
Real-time filters, personalisation, complex forms — you're already fighting the theme layer.
- You have engineers, not just marketers
Headless assumes deploy pipelines and a git workflow. Without them, you'll regret it in month two.
- Editor experience is a first-class requirement
Choose a CMS with strong preview, references, and localisation — Sanity, Storyblok, Contentful lead here.
What we hear most often — and what's actually true
A well-hosted traditional WP can match a headless site on Core Web Vitals.
Small teams use Sanity + Next.js all the time. It's about the shape of the work, not the size of the team.
It can — via WPGraphQL. Many teams keep WP as the CMS and rebuild only the front-end.
Frequently asked questions
Traditional WP, usually. Headless is worth it when the extra flexibility earns back the cost.
Traditional WP has more available talent; headless requires modern front-end engineers.
Yes — commonly by putting Next.js in front of WordPress first, then swapping the CMS out.
For marketing sites with a design-led brand or multi-channel needs: headless. For pure content publishing: traditional.
Not sure which to pick? Let's decide together.
A 30-minute call is enough for us to give you a recommendation — no pitch.