If your WordPress site loads fast enough to rank and editors publish without opening a ticket, keep it. Move to a headless CMS when the theme and plugins are what slow every release, when the same content has to reach more than one channel, or when editors wait on a deploy to change a sentence.
The longer answer depends on what you are comparing. Most teams who ask “WordPress or headless?” are choosing between three setups, not two.
What are the three options?
Classic WordPress. WordPress stores the content and renders pages through a PHP theme. Editors get the block editor, a preview that matches the live site, and a huge plugin catalogue. One system to host and patch.
Headless WordPress. WordPress stays as the editing backend. A separate frontend, usually Next.js, reads content through the REST API in core or through the WPGraphQL plugin. Editors keep the admin they know, and code your team controls renders the site. Our headless WordPress development page covers this route.
A dedicated headless CMS. Content moves to a system built for API delivery: self-hosted Payload or Strapi, or a SaaS product such as Sanity, Contentful or Storyblok. You model content as typed fields and references instead of post bodies full of blocks, and you build the frontend separately.
| Classic WordPress | Headless WordPress | Dedicated headless CMS | |
|---|---|---|---|
| Who renders pages | PHP theme | Your frontend (Next.js, Astro) | Your frontend |
| Editor experience | Block editor with true preview | Same admin, preview needs extra work | Depends on the CMS, preview is built per project |
| Content model | Posts and pages, custom fields by plugin | Same model, exposed over an API | Typed fields and references, defined per project |
| Plugins | Large catalogue, many touch the frontend | Frontend plugins stop working | Integrations are code or vendor apps |
| Hosting | One PHP host | PHP host plus frontend host | Node app and database, or vendor SaaS, plus frontend |
| Main risk | Plugin sprawl and slow pages | Two systems, WordPress quirks remain | Migration effort and a new tool for editors |
| Fits | Content sites run by one team | Teams who like the admin but need speed | Structured content, several channels, compliance |
When is classic WordPress enough?
More often than vendors suggest. WordPress is enough when:
- One marketing team edits one website, and most pages are posts, landing pages and a blog.
- You rely on a few maintained plugins and do not override the theme heavily.
- Core Web Vitals pass with page caching and a CDN in front.
- Nobody needs the same content in an app, a help centre or a partner portal.
In that situation a headless rebuild adds a second system to host, a frontend to maintain and a preview to rebuild, for a gain your readers may not notice. Spend the budget on a theme cleanup, a plugin audit and better hosting instead.
When does headless WordPress make sense?
Headless WordPress is the middle step. It fits when editors are productive in WordPress, the content model is simple, and the trouble is the frontend: slow pages, a theme nobody wants to touch, or a design system the PHP theme cannot follow.
You keep the content and the editor training. You lose everything that renders through the theme: page builder output, many SEO and form plugins, shortcodes. Each needs a replacement on the frontend. Preview has to be wired to the new frontend, and you still patch WordPress core and plugins on the backend. If you want people who know both sides, you can hire a headless WordPress developer to work inside your sprints.
For this choice measured against one specific self-hosted CMS, see our Strapi vs headless WordPress comparison.
When should you move to a dedicated headless CMS?
Move when the problems sit in the content layer, not only in the frontend. The signals we see most often:
- Content has structure WordPress fights. Pricing tables, feature matrices, versioned release notes, product data. In WordPress these end up as custom fields bolted onto posts or as HTML pasted into blocks.
- More than one channel reads the content. The site, a mobile app and in-product help all need the same entries.
- Approval workflows matter. Regulated copy needs draft, review and published states with a record of who approved what.
- Localisation is serious. Several markets, each with its own editors who should touch only their locale.
- Every change needs a developer. Years of plugins and theme overrides make each release a risk.
Self-hosted or SaaS?
If you want the content model in your own repository and the data in your own database, look at Payload or Strapi. Payload runs inside a Next.js app and defines its schema in TypeScript. Strapi has a visual content type builder and a larger plugin marketplace. If nobody on your side wants to run a server, a SaaS CMS takes hosting away in exchange for a subscription priced on seats, API calls or locales.
What did this look like for a fintech we moved off WordPress?
A US-based Series-B fintech came to us with its marketing site on a heavily customized WordPress installation: roughly 40 custom plugins, a tightly coupled theme, and a pipeline that rebuilt the entire site on every change. Every copy change needed a developer review.
We moved the content to Payload and rebuilt the frontend in Next.js, with static generation for marketing pages and ISR for rate and disclosure pages. Compliance review moved into the CMS as draft, legal-review and published states. Results from the fintech replatform case study:
- ~65% reduction in time-to-publish
- LCP of 1.4s, down from 4.2s
- ~3x faster full site builds
- Organic traffic held through cutover
The gain came from structure, not from the word “headless”: an explicit content model, approval states inside the CMS, and builds that only touch changed content.
What does each option cost to own?
We do not quote a price before a short audit, because the drivers vary more than the platforms do. Here is what moves the total:
| Cost driver | Classic WordPress | Headless WordPress | Dedicated headless CMS |
|---|---|---|---|
| Licences | Free core, paid plugins add up | Same as classic | Free if self-hosted, SaaS priced by seat, API or locale |
| Hosting | One PHP host | PHP host plus frontend host | Node host and database, or vendor plan, plus frontend |
| Build effort | Theme work | New frontend, preview, plugin swaps | Content model, frontend, preview, migration scripts |
| Ongoing work | Core and plugin updates | WordPress patches plus frontend upkeep | CMS upgrades or plan changes, frontend upkeep |
| Editor retraining | None | Little | Some, a new admin to learn |
The hidden cost on the WordPress side is plugin maintenance and the developer time each change takes. On the headless side it is the migration itself and the preview editors expect on day one.
How do you migrate without losing rankings?
Treat the URL list as a contract. Export every live URL, decide for each one whether it keeps its path or gets a 301, carry over titles, descriptions and structured data, and test the redirects before cutover. Our headless CMS migration checklist lists the steps we run, and the WordPress to headless CMS migration page explains how we scope that route.
Which one we would pick for whom
- A small marketing team with a content site that already performs: stay on classic WordPress, prune plugins, fix hosting.
- A team happy in the WordPress admin but stuck with a slow theme: headless WordPress with a Next.js frontend.
- A product company with structured content, several channels or compliance review: a dedicated headless CMS. We lean to Payload when your engineers want the schema in code, and to a SaaS CMS when nobody wants to run a server.
- A large site with years of plugin debt and rankings to protect: a dedicated headless CMS, migrated in stages with the redirect map written first.
Still weighing it up? Our headless CMS development services page shows what each kind of project includes, and the page on how we work as a headless CMS agency explains how we run builds and migrations end to end.
