# Should you go headless with WordPress or switch to a different CMS?

Reviewed by Martin Dejnicki · facts verified 25 October 2026 · canonical: https://deploi.ca/sanity/compare/headless-wordpress-or-new-cms

## Short answer

Headless WordPress fits when editors must keep the block editor and a team will rebuild what plugins did. WordPress VIP (an enterprise host) says "Headless architecture breaks plugin support" ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026). So Deploi picks Sanity, a headless content management system (CMS), when you rebuild the front end anyway, and hybrid WordPress when one app needs the content.

- **WordPress headless APIs:** REST API in core, GraphQL through WPGraphQL. The core REST API sends and receives JSON; WPGraphQL is a free, open-source plugin that its WordPress.org plugin page says is becoming a Canonical Plugin, so it isn't a core API ([WordPress.org, REST API Handbook](https://developer.wordpress.org/rest-api/); [WPGraphQL, Introduction](https://www.wpgraphql.com/docs/introduction); [WordPress.org, WPGraphQL plugin](https://wordpress.org/plugins/wp-graphql/))
- **Plugins under headless WordPress:** They break, says WordPress VIP. VIP, which sells both modes, says plugins are replaced by custom integrations needing ongoing engineering, and headless will likely be slower without a team to tune it ([WordPress VIP, When WordPress Shouldn't Be Headless](https://wpvip.com/blog/headless-wordpress-tradeoffs/))
- **Sanity editing on every plan:** Visual Editing and real-time editing, Free too. Free is $0, Growth is $15 per seat a month billed monthly, Enterprise is custom, as of October 2026; the editor and the content model both change ([Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity, Sanity for Startups](https://www.sanity.io/startups); [Sanity, Sanity Studio](https://www.sanity.io/studio); [Sanity Docs, Visual editing](https://www.sanity.io/docs/visual-editing/introduction-to-visual-editing))
- **WordPress end of life:** None; PHP says 8.2 security support ends 31 December 2026. Only the latest WordPress is officially supported. The PHP date is a hosting upgrade for any WordPress back end, headless or not, and not a reason to replatform ([WordPress.org, Security](https://wordpress.org/about/security/); [WordPress.org, Release Archive](https://wordpress.org/download/releases/); [PHP, Supported Versions](https://www.php.net/supported-versions.php))

## Deploi's call

Full headless WordPress is the hardest middle: you pay for a new front end and keep running WordPress behind it. Go hybrid if editors must keep the block editor and plugins; move the content to Sanity if you're rebuilding the front end anyway.

**PICK: Move the content to Sanity instead of going headless on WordPress when**

- You're building a new front end anyway, so replacing the theme costs the same whichever content management system (CMS) sits behind it.
- Content needs remodeling into structured types for several channels, so Portable Text's structured JSON beats post markup.
- You'd rather not run a WordPress back end that still needs core, plugin and PHP updates behind the new front end.
- Editors can learn Sanity Studio, with Visual Editing on every Sanity plan, Free included, as of October 2026.

**ALTERNATIVE: Keep WordPress, traditional, hybrid or headless, when**

- Hybrid WordPress: the website stays on its theme and one app or kiosk reads the content through the core application programming interface (API) or the WPGraphQL plugin, so the website keeps its plugins.
- Headless WordPress: editors must keep the block editor, and a dedicated front-end and DevOps team will rebuild previews and plugin features, because WordPress VIP (an enterprise host) says headless breaks plugin support.
- Traditional WordPress: the web is the only channel and marketing depends on plugins, so splitting the stack adds work and no reach.

## Is WordPress already a headless CMS, and what are the options?

WordPress is a decoupled content management system (CMS), not a purely headless one. It ships a theme layer and an application programming interface (API), so it runs headless when a separate front end ignores the theme. Sanity's own guide names WordPress and Drupal as the two most common decoupled CMSs, where "you can use the built-in presentation layer, or you can use the API to serve content to other channels" ([Sanity, Decoupled CMS vs Headless CMS](https://www.sanity.io/decoupled-cms), October 2026). WordPress core's REST (Representational State Transfer) API sends and receives content as JSON ([WordPress Developer Resources, REST API Handbook](https://developer.wordpress.org/rest-api/), October 2026).

That leaves a WordPress site four options:

1. **Traditional WordPress.** The theme renders every page.
1. **Hybrid WordPress.** The theme keeps the website, and one app or kiosk reads content through the API. WordPress VIP (an enterprise WordPress host) says "A single WordPress install can support both a headless and a traditional experience simultaneously" ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026).
1. **Headless WordPress.** A new JavaScript front end, often Next.js, renders every page from the API.
1. **A new CMS, such as Sanity.** The content moves to a different back end, and the front end is new too.

Whether any site should go headless at all is the headless versus traditional CMS question.

## Which option fits which WordPress team?

Traditional WordPress fits a web-only, plugin-led site; hybrid fits one app that needs the content; headless WordPress fits a team whose editors must keep the block editor; Sanity fits a new front end for several channels. Hybrid WordPress is the option that changes least, because the website doesn't move.

**Headless WordPress keeps the editor; Sanity changes the editor and the back end**

| Criterion | Traditional WordPress | Hybrid WordPress | Headless WordPress | Sanity |
| --- | --- | --- | --- | --- |
| Editor | Block editor | Block editor | Block editor | Sanity Studio |
| Previews | Theme | Theme | Rebuilt, or Faust.js | Visual Editing |
| Plugins | All work | All work on the site | Front-end ones break | Rebuilt in the front end |
| Back-end upkeep | WordPress updates | WordPress updates | WordPress updates | Sanity hosts content; Studio upgrades |
| Front-end build | Theme | Theme plus one app | New | New |
| Fit | Web only, plugin-led | One app needs content | Editors keep the block editor | New front end, several channels |

WordPress updates means core, plugin and PHP updates. Upkeep and build rows are Deploi's judgment. Sources: [WP Engine, Faust.js Introduction](https://faustjs.org/docs/); [WordPress VIP, When WordPress Shouldn't Be Headless](https://wpvip.com/blog/headless-wordpress-tradeoffs/); [Sanity, Plans that scale with you](https://www.sanity.io/pricing). As of 24 October 2026.

Moving to Sanity also changes the content model: rich text becomes Portable Text, structured JSON instead of HTML ([Sanity glossary](https://www.sanity.io/glossary/portable-text), October 2026). [Sanity and WordPress side by side](https://deploi.ca/sanity/compare/sanity-vs-wordpress) compares editing and content reuse.

## How does a headless WordPress front end get its content?

A headless WordPress front end reads content through the core REST (Representational State Transfer) application programming interface (API) or the WPGraphQL plugin. A toolkit such as Faust.js restores some WordPress behavior in Next.js. Four pieces do the work, as of October 2026:

- **REST API, in core.** It provides "an interface for applications to interact with your WordPress site by sending and receiving data as JSON" ([REST API Handbook](https://developer.wordpress.org/rest-api/), October 2026).
- **WPGraphQL, a plugin.** It's "a free, open-source WordPress plugin" that adds a GraphQL API ([WPGraphQL](https://www.wpgraphql.com/docs/introduction), October 2026). Its WordPress.org page says it "is becoming a Canonical Plugin", so it isn't a core API ([WordPress.org plugin directory](https://wordpress.org/plugins/wp-graphql/), October 2026).
- **Faust.js.** A toolkit from WP Engine, a WordPress host, it is "a set of tools that make it easy to build headless WordPress apps with Next.js", with template hierarchy, block components and post previews ([Faust.js docs](https://faustjs.org/docs/), October 2026).
- **Managed hosts.** WP Engine's Headless Platform offers "frontend and backend hosting" in one place ([WP Engine](https://wpengine.com/headless-wordpress/), October 2026), and WordPress VIP (an enterprise WordPress host) runs Node.js apps including "decoupled/headless frontends to WordPress" ([WordPress VIP Documentation](https://docs.wpvip.com/node-js/), October 2026).

On the Sanity side, [the next-sanity toolkit for Next.js](https://deploi.ca/sanity/integrations/nextjs) does the same job.

## What does headless WordPress keep, and what does it lose?

Headless WordPress keeps the WordPress admin, users, content and block editor, and loses whatever the theme and front-end plugins did. WordPress VIP (an enterprise WordPress host that sells both modes) says "Headless architecture breaks plugin support", because plugins get replaced by custom integrations that need ongoing engineering ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026). Its list of losses is conditional:

- **Previews and in-context editing** often land on the development backlog. Faust.js restores post previews in Next.js ([Faust.js docs](https://faustjs.org/docs/), October 2026).
- **Tracking and testing.** VIP says pixels, tags, A/B tests and heatmaps become custom integrations or requests to engineering ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026).
- **Speed.** VIP says headless needs an engineering team to tune its components: "Without that team, headless WordPress will likely be slower" ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026).
- **Governance.** VIP says approval chains live outside the content management system unless audit functionality is rebuilt for the headless setup ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026).

The back end doesn't get lighter, because WordPress still stores and serves the content. WordPress publishes no end-of-life date, but "only the latest version of WordPress is officially supported" ([WordPress.org, Security](https://wordpress.org/about/security/), October 2026), so core, plugin and PHP updates continue behind a headless front end. [What breaks for search engine optimization (SEO) when you go headless](https://deploi.ca/sanity/faq/what-breaks-for-seo-when-going-headless) is a separate list.

## What does a headless front end need that a WordPress theme didn't?

A headless front end needs a rebuild trigger: something has to tell it to refresh a page when an editor publishes. A WordPress theme doesn't need one, because it renders pages on request. WordPress VIP (an enterprise WordPress host) says incremental static regeneration (ISR) and related build strategies "require more orchestration in a headless stack" ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026). On Sanity, the documented route is a webhook: "When content changes in Sanity, you can use webhooks to revalidate cached pages in your Next.js application on demand" ([Sanity Docs, Revalidate Next.js pages with Sanity webhooks](https://www.sanity.io/docs/nextjs/validating-sanity-webhooks-nextjs), October 2026). Headless WordPress needs the same trigger, fired from WordPress instead (Deploi's judgment).

deploi.ca's code shows both refresh styles in its own Sanity sections. Its Shopify sections are a headless Next.js front end on Sanity, on an older Next.js release with the Pages Router; the main pages run on other content management systems (CMSs).

- **On publish.** The FAQ hub's code has a signed revalidation route built for a Sanity webhook.
- **On a timer.** The other Shopify sections regenerate their pages at a set interval.

How the signed webhook route is built covers the design and its pitfalls, and [the Sanity and Next.js guide](https://deploi.ca/sanity/integrations/nextjs) owns the fix for a new page that stays 404 after it's published.

## Which option costs more to build and to run?

Neither headless WordPress nor Sanity is cheaper by default, and none of the sources read publishes a total for either build, so compare the drivers. Headless WordPress pays for a new front end and keeps a WordPress host and patching. Sanity pays for a new front end, plan fees and a content migration (Deploi's judgment). WordPress is General Public License (GPL) software with no licensing fees ([WordPress.org, Features](https://wordpress.org/about/features/), October 2026).

**Every path except traditional WordPress pays for a new build; only Sanity removes the WordPress back end**

| Cost driver | Traditional WordPress | Hybrid WordPress | Headless WordPress | Sanity |
| --- | --- | --- | --- | --- |
| License or plan | GPL, no fees | GPL, no fees | GPL, no fees | Free $0; Growth $15 per seat a month |
| Front end | Theme | Theme plus one app | New build | New build |
| Back end | WordPress host | WordPress host | WordPress plus front-end host | Sanity plan |
| Content migration | None | None | None | Script and remodel |

Sanity's self-serve plans bill monthly, as of October 2026 ([Sanity pricing](https://www.sanity.io/pricing); [Sanity for Startups](https://www.sanity.io/startups)). Rows below the first are Deploi's judgment. WordPress VIP (an enterprise host) publishes no prices; each package says Request pricing. Sources: [WordPress.org, Features](https://wordpress.org/about/features/); [WordPress VIP, Pricing](https://wpvip.com/pricing/); [Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity, Sanity for Startups](https://www.sanity.io/startups). As of 24 October 2026.

[The WordPress to Sanity playbook](https://deploi.ca/sanity/migration/wordpress-to-sanity) covers the content migration itself; for your own site, [talk to Deploi](https://deploi.ca/contact).

## When is headless or hybrid WordPress the right call?

Hybrid WordPress is the right call when the website works and one new app or kiosk needs the content, because the site keeps its theme and plugins. Headless WordPress is right when editors must keep the block editor and a front-end team will rebuild what plugins did. WordPress VIP (an enterprise WordPress host) lists reasons to avoid headless, including "Your primary channel is the web" and heavy reliance on plugins for search engine optimization (SEO), analytics, governance or workflow ([WordPress VIP](https://wpvip.com/blog/headless-wordpress-tradeoffs/), October 2026).

> **When Sanity is not the pick for a WordPress site**
>
> - One app or kiosk needs the content and the site is fine: serve it through the core application programming interface (API) or the WPGraphQL plugin and stay hybrid.
> - Editors must keep the block editor and a front-end team is on staff: headless WordPress keeps it.
> - The web is the only channel and marketers depend on plugins: stay on traditional WordPress.
> - Speed is the only complaint: fix hosting and caching first, because a rebuild costs more than that problem.

[Whether to leave WordPress at all](https://deploi.ca/sanity/migration/leaving-wordpress) is a decision of its own, and [enterprise WordPress alternatives](https://deploi.ca/sanity/compare/wordpress-alternatives-for-enterprise) compares the other platforms.

## Deploi's point of view

**Where we disagree.** The common pitch sells headless WordPress as the cheap, safe halfway house: keep the CMS editors know and get a fast modern front end. It isn't cheap, and it isn't automatically fast. You fund a new front end, rebuild the previews, forms, tracking and SEO features that plugins used to handle, and still apply every WordPress core, plugin and PHP update. Even WordPress VIP, which sells headless hosting, says headless breaks plugin support and will likely be slower without a team to tune it. The opposite claim, that WordPress can't run headless, is wrong too: the REST API ships in core.

**What we've seen.** deploi.ca's Shopify sections run a headless Next.js front end on Sanity, on an older Next.js release with the Pages Router and next-sanity ^11.4.2; the site's main pages run on other CMSs. The FAQ hub's code has a signed revalidation route built for a Sanity webhook, while the other Shopify sections refresh on a timer. One lesson sits in the code of the Build vs. Buy pages: a page requested before it is published must also revalidate on its not-found branch, or Next.js keeps the cached miss. A WordPress theme doesn't need this wiring because it renders pages on request. Our view of headless WordPress rests on WordPress, WPGraphQL, Faust.js, WP Engine and VIP documentation.

**Where we would push back.** Deploi builds its own Shopify sections on Sanity, so weigh our pick with that in mind, and notice where it stops. A web-only site whose marketers live in plugins should stay on traditional WordPress and fix hosting and caching first. Moving it buys a rebuild and no new channel.

**What we'd tell you to do first.** List every plugin that touches what visitors see: SEO, forms, analytics, A/B testing, translation. Each one becomes front-end work under headless WordPress and under Sanity alike. If the list is long and the web is your only channel, stay coupled.

## When this answer changes

- WordPress core ships real-time co-editing, which WordPress.org's roadmap places in Phase 3
- WPGraphQL completes its move to a Canonical Plugin, or WordPress adds GraphQL to core
- WP Engine changes or retires Faust.js or its Headless Platform
- WordPress VIP publishes prices or changes its headless guidance
- Sanity moves Visual Editing, the Presentation tool or real-time editing off the Free plan, or changes the Growth price of $15 per seat a month

## How do you migrate from WordPress to Sanity?

See the content mapping, the Gutenberg to Portable Text path, redirects and the step-by-step plan before you commit. [Read the WordPress to Sanity playbook](https://deploi.ca/sanity/migration/wordpress-to-sanity)

## Sources

1. [Sanity, Plans that scale with you](https://www.sanity.io/pricing), checked 24 October 2026
2. [Sanity, Sanity for Startups](https://www.sanity.io/startups), checked 24 October 2026
3. [Sanity, Sanity Studio](https://www.sanity.io/studio), checked 24 October 2026
4. [Sanity Docs, Visual editing](https://www.sanity.io/docs/visual-editing/introduction-to-visual-editing), checked 24 October 2026
5. [Sanity, Decoupled CMS vs Headless CMS](https://www.sanity.io/decoupled-cms), checked 24 October 2026
6. [Sanity Docs, Revalidate Next.js pages with Sanity webhooks](https://www.sanity.io/docs/nextjs/validating-sanity-webhooks-nextjs), checked 24 October 2026
7. [Sanity, Portable Text definition (glossary)](https://www.sanity.io/glossary/portable-text), checked 24 October 2026
8. [WordPress.org, REST API Handbook](https://developer.wordpress.org/rest-api/), checked 24 October 2026
9. [WPGraphQL, Introduction](https://www.wpgraphql.com/docs/introduction), checked 24 October 2026
10. [WordPress.org, WPGraphQL plugin](https://wordpress.org/plugins/wp-graphql/), checked 24 October 2026
11. [WP Engine, Faust.js Introduction](https://faustjs.org/docs/), checked 24 October 2026
12. [WP Engine, Headless WordPress Hosting Solution](https://wpengine.com/headless-wordpress/), checked 24 October 2026
13. [WordPress VIP, When WordPress Shouldn't Be Headless](https://wpvip.com/blog/headless-wordpress-tradeoffs/), checked 24 October 2026
14. [WordPress VIP Documentation, Node.js on VIP](https://docs.wpvip.com/node-js/), checked 24 October 2026
15. [WordPress VIP, Pricing](https://wpvip.com/pricing/), checked 24 October 2026
16. [WordPress.org, Security](https://wordpress.org/about/security/), checked 24 October 2026
17. [WordPress.org, Release Archive](https://wordpress.org/download/releases/), checked 24 October 2026
18. [PHP, Supported Versions](https://www.php.net/supported-versions.php), checked 24 October 2026
19. [WordPress.org, Features](https://wordpress.org/about/features/), checked 24 October 2026