WordPress vs headless CMS: when does each fit?
Headless CMS or WordPress? We build both and explain when Sanity + Next.js, WordPress or MedusaJS is the best fit for your project.
- Published
- Updated
- Reading time
- 6 min

In short
- A headless CMS like Sanity with Next.js fits when content goes to several channels, is structured or needs custom workflows, and there is a development budget.
- WordPress fits typical business websites with editors who know it, existing sites and projects that need the broad plugin ecosystem.
- For online stores with custom data models we use MedusaJS with Sanity and Next.js. Both routes can be fast: under 100 ms with Sanity and under 200 ms with WordPress.
A headless CMS like Sanity with Next.js fits when content goes out to several channels, is structured or needs custom workflows, and there is a development budget. WordPress fits typical business websites with editors who already know it. Both can be fast: Sanity + Next.js responds in under 100 ms and WordPress with FrankenPHP in under 200 ms.
Is headless always the better choice?
The agency says you need a headless CMS and the developer wants to build in Next.js, while you've heard that WordPress is outdated.
Both camps have a point. Headless pays off most when content is structured and used across several channels. WordPress pays off most when the site is a typical business website and the editors already know the tool. It isn't outdated either: according to W3Techs, WordPress is used by 40.2% of all websites and 58.6% of websites with a known CMS (October 2026).
We build both, and below we go through when each one fits.
What does "headless" actually mean?
In a traditional CMS, content management and presentation are tied together. You write content in wp-admin, and WordPress generates the HTML visitors see.
In a headless CMS, the two are separate. Content is stored as structured data and delivered via API, and a separate frontend (typically React with Next.js) fetches it and builds the website. The CMS has no say in how the content looks.
WordPress can be used headless via its REST API or WPGraphQL. It's a bit like buying a station wagon and taking out the seats to use it as a van: it works, but you could have bought a van in the first place.
Sanity: when content goes to several channels
Sanity is a headless CMS founded in Oslo in 2016, with headquarters in Oslo and San Francisco today. It has a real-time database and a customisable editor interface built in React. Content is stored as structured data and delivered via GROQ or GraphQL.
Together with Next.js, you get:
- Response times under 100 ms with static generation and ISR
- Structured content you can reuse across channels
- No plugins, and so no security holes from third-party code
- Live preview with Visual Editing directly in the website
- TypeScript all the way, from CMS to frontend
- Code that is simpler to develop, test and maintain
Sanity + Next.js works best when the same content goes to a website, an app and other channels, when the content model doesn't fit into pages and posts, or when editors need custom workflows. It takes a development budget, because more of the site is built for you instead of coming from ready-made plugins.
Editors manage fine. Sanity Studio is easy to use, you can shape it to your needs, and it's no harder than WordPress for producing content.
MedusaJS: commerce with custom business models
For online stores with their own data models and business rules, we use MedusaJS. It's an open source framework for headless commerce, built in Node.js with a modular architecture.
Compared with WooCommerce, you get:
- No PHP, no WordPress and no plugins to keep updated
- A modular architecture where you only use what you need
- An API-first design, built for headless from the start
- Custom data models and rules without fighting a fixed store structure
MedusaJS suits new online stores where you're starting from scratch. With Sanity for content and Next.js for the frontend, you have a complete e-commerce platform with no technical debt from day one.
When WordPress is the right choice
In these situations, WordPress is the right choice:
Typical business websites. A business website with 5–50 pages, a blog and some landing pages rarely needs more than WordPress, especially when the editors already know it. The plugin ecosystem covers most forms, SEO and integrations.
Existing WordPress sites. If you have a WordPress site that works, with established content, integrations and a team that knows the tool, it's rarely worth migrating to headless just because it's fashionable. Modernising with WPFluent and FrankenPHP often gives you more for your money.
Limited development budget. WordPress gives you a lot out of the box: themes, plugins and an editing tool people know. A headless project builds more from scratch, so sites with many integrations cost more to develop.
Clients who want WordPress. Some clients know WordPress, like it and don't want to learn something new. That's a fair enough reason.
WooCommerce with specific plugins. Some niche WooCommerce plugins, such as particular shipping integrations, inventory management and B2B features, have no equivalent in MedusaJS yet. The WooCommerce ecosystem is still broader.
With the right architecture, WordPress is neither slow nor insecure. The risk sits in the plugins: Patchstack recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, and 91% of them were in plugins. Only 6 were reported in WordPress core itself. We build WordPress with FrankenPHP Worker Mode for response times under 200 ms, CI/CD pipelines and proactive security. It still takes more maintenance than Sanity. The full recipe is in how we took WordPress from 4 seconds to 180 ms.
The hybrid solution: WordPress backend with modern frontend
Some projects need the WordPress admin, because editors know it or the WooCommerce integrations are already in place, but want a faster and more flexible frontend.
In that case we use WordPress as the backend and React/Next.js as the frontend. You keep wp-admin for content and order processing, while customers get a fast React web app.
We only recommend this when it's needed. The hybrid costs more to build and maintain than a pure Sanity build, and most projects do fine with either Sanity + Next.js or plain WordPress.
Norwegian requirements and platform choice
Some Norwegian requirements affect the choice:
Payments. WooCommerce has mature plugins for Vipps, Norway's most widely used mobile payment app, and Klarna. MedusaJS has no official Vipps module, and the official Klarna plugin is built for Medusa v1. In Medusa v2 we connect payments through the payment provider API, either via a payment service provider such as Stripe, Adyen or Pay., or as a custom integration.
BankID. Norway's standard electronic ID can be integrated in both ecosystems, but neither has it built in.
GDPR and data storage. Sanity stores customer data on Google Cloud with Belgium as the primary location, so primarily in the EU, but also lists the USA as a processing location in its list of sub-processors. The region can't be chosen. WordPress lives wherever you host it, and at PXL it's in the EU.
Tripletex and PowerOffice. For these Norwegian accounting systems WordPress has ready-made plugins, while with headless you build the API integrations yourself. With heavy accounting integrations WordPress can be simpler, but that comes down to development work more than to the platform.
What we recommend
We follow four rules:
- Typical business website with editors who know WordPress? WordPress, built with version control, CI/CD and fast hosting.
- Content for several channels, structured content or custom workflows, and a development budget? Sanity + Next.js.
- Online store with custom data models? MedusaJS + Sanity + Next.js. If the store needs specific WooCommerce plugins, WooCommerce is still a good choice.
- Existing WordPress that works? Modernise it with WPFluent, FrankenPHP and CI/CD, and don't migrate just for the sake of it.
We charge the same regardless of platform, so the recommendation is only about what serves you best for the life of the site. Who should build it is a separate question, which we cover in a WordPress agency or a developer team.
Not sure? Get in touch and we'll give you a no-obligation assessment of which platform fits your project.


