Should you move from WordPress to a headless CMS? Decision criteria and hidden costs

Going headless is a trade, not an upgrade. You gain one place to keep content and the ability to serve it to a website, a mobile app, an in-store screen and a partner feed from the same source. In exchange, your team takes over the work a traditional CMS handed you on install: URL management, redirects, sitemaps, preview, forms, search and image processing. If you run one corporate site, a marketing team that updates it without help, and no permanent developer capacity, that trade costs you more than it returns. If content gets reused across several surfaces, a team already builds the front end, and your content behaves more like records than pages, the trade starts to make sense.

The market balance is worth knowing before the meeting. W3Techs data from 20 September 2026 puts WordPress on 58.8% of sites whose CMS is known, and 40.2% of all websites. The traditional side is not standing still either: Drupal shipped Drupal CMS 1.0 on 15 January 2025, a build aimed at marketing teams that works out of the box. So the question is not which option is more modern. The question is which one your publishing routine actually resembles.

What headless means, and what it does not

In a traditional CMS, the content store, the admin panel and the template engine that renders pages are parts of the same application. Headless splits that package in two. The CMS stores content and hands it over through an API; a separate application renders the pages. The first consequence is the one everyone quotes: any client can read the same content. The second gets noticed late. There is no longer such a thing as a page inside the CMS. The front end builds the page, so everything that belongs to a page moves to the front end's side of the line.

There is also a middle option that gets skipped too often. Keep the CMS you already run and use only its API. That is decoupled, or headless, WordPress: the REST API ships in core, and teams that prefer GraphQL install WPGraphQL. Editors keep their habits, the front end gets its freedom, and the risk is a fraction of a full replatform. In most cases this is the version worth trying first.

Four situations where headless earns its keep

• The same content appears on more than one surface. When a product description feeds the site, the mobile app, a dealer portal and a partner data feed, burying that description inside a template is an expensive mistake.
• Your content is records, not pages. Products, branches, events, staff profiles and price lists become useful when they are modelled field by field and can be sorted, filtered and reassembled. A table pasted into a rich text editor cannot do any of that.
• A team already builds the front end. If you have a design system, a component library and developers maintaining both, the CMS template engine is not helping you. It is in the way.
• You operate in several markets and languages. A shared content model across locales is markedly cheaper to run than a separate installation per language. The URL and hreflang side of that is covered in our note on multilingual site architecture.

The inverse is just as clear. One corporate site, campaign pages that marketing assembles itself, and an agency that appears a few times a year: headless will slow all of that down. Editing existing content still happens in the admin panel, no problem there. But a new page type, a new section layout or an unusual campaign page becomes developer work. In the traditional CMS, marketing built those without asking anyone.

The jobs your old CMS did for free

This is where headless budgets break. Everything below arrives with a traditional CMS on install, and becomes a separate line item in a headless build:

• URLs and redirects. When an editor changes a title, the address changes. Someone has to keep a redirect table so the old address does not return a 404. Does that table live in the CMS, the front end or the CDN? Answer it on day one, because most post-launch traffic losses trace back to a redirect map that was never owned. We walked through the discipline in protecting SEO during a redesign or migration.
• Sitemaps, canonical tags, hreflang and robots rules. None of these generate themselves.
• Structured data. The front end emits the schema.org markup, and visibility in search and answer engines depends on it. That side is covered in visibility in AI search.
• Image processing. Resizing, format conversion and responsive variants. Skip it and your Core Web Vitals numbers will show it.
• Forms, site search and comments. Three separate services or three separate builds. Search in particular is harder than it looks, as we covered in site search relevance.
• Field-level permissions. Should an editor be able to change the price field, and who approves publication? Traditional CMS role models are mature; on the headless side this is configuration work you own. Models are compared in our note on authorization.
• Cache invalidation. How many seconds after someone hits publish does the page change? With static generation the honest answer might be "when the rebuild finishes," which editors will not accept. The layering is covered in caching strategy.

None of these items is difficult on its own. Together they are the month nobody put in the first estimate.

Solve preview or nobody will use the system

Editors want to see the page before they publish it. A headless CMS renders nothing, so it cannot show them. Preview has to be built as a separate path where the front end pulls draft content and renders it, and it has to satisfy three conditions: show the draft state, bypass the production cache, and render the real page. A preview that hides the title tag, the images or the mobile layout forces editors to publish blind.

Build it in the first sprint, not the third month. The acceptance test fits in one sentence: an editor opens a draft, changes the headline, sees the change at the preview address within a few seconds, and that address is not reachable from outside. The last condition matters. An unauthenticated preview endpoint exposes unpublished content, pending price changes and embargoed announcements to anyone who finds the URL, and teams usually discover the problem when a search engine indexes a draft.

Security: the risk moves, it does not disappear

The plugin ecosystem carries real weight. Patchstack's 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem during 2025, a 42% rise year over year. Of those, 91% were in plugins and 9% in themes; core accounted for six, all low priority. Two other numbers from the report speak more directly to business risk: 46% of vulnerabilities had no patch available at the moment of disclosure, and for the most heavily targeted ones the weighted median time to first exploitation was five hours.

Core is not untouchable either. The chain disclosed in July 2026 as wp2shell combined two flaws in WordPress core (CVE-2026-63030 and CVE-2026-60137) to allow unauthenticated code execution on a site with no plugins installed at all. Patches went out on 18 July 2026.

None of that adds up to "headless is safer." The risk moves rather than shrinks. Your admin panel is still an application facing the internet. Your API tokens are now a single key to the entire content store. Your build pipeline becomes part of production, which means every dependency in that pipeline does too. Choose a self-hosted system such as Strapi, Payload or Directus and patching the Node dependency tree is your job now. You trade plugin patching for dependency patching, and both need the same discipline: patch and vulnerability management plus software supply chain security.

The cost is in the implementation, not the licence

Comparing licence fees is the most common way to get this decision wrong. SaaS headless vendors typically price on editor seats, environments and API calls, so the invoice grows with the team. The bigger number sits elsewhere. A realistic budget has these lines in it: content model design, front-end build, preview infrastructure, redirect management, an image service, a search service, a forms service, front-end hosting and editor training.

Moving the existing content is its own line. Migrating a few thousand entries is not an export job. It is field mapping, relinking embedded media, cleaning out legacy shortcodes and building an address-by-address redirect map. The method is in our note on migrating data from a legacy system. A comparison that leaves these out makes headless look cheaper than it is.

Lock-in, ownership and the way out

Pick a SaaS headless CMS and your content lives in someone else's database. That is not bad by itself, but two answers belong in the contract stage. In what format, and how quickly, can you extract all of it? And when the vendor makes a breaking change to the API, how much transition time do you get?

The vendor is not a fixed point either. Figma announced on 17 June 2025 that the team behind the open-source headless CMS Payload had joined the company, and said the product would stay open source. Acquisitions do not always end badly, but ownership changes and roadmaps follow. A self-hosted open-source CMS lowers that particular risk and hands you the operations and patching load instead. Whichever side you pick, run the export once before you commit. An untested exit plan is not a plan.

Six questions that settle it

1. How many surfaces show this content? If the answer is "one website," a traditional CMS is probably the right call.
2. Who maintains the front end for the next three years? Without permanent developer capacity, headless is technical debt with a nicer name.
3. Does marketing need to build landing pages unassisted? If yes, either pick a traditional CMS with a page builder or budget a block-based content model from the start.
4. Is your content pages or records? Structured records like products, branches and events argue for headless.
5. How many languages and markets? Past two languages, a shared content model becomes a serious advantage.
6. What is your exit? If you cannot describe how and how fast the content comes out, the decision is not finished.

The cheapest thing you can do before deciding is watch what the content team actually does for one week. How many times did they create a new page, how many times did they fix existing copy, how many times did they need a developer, and how many addresses changed. Those four numbers settle the question more reliably than any vendor comparison table. At Wedevit we measure the publishing routine you actually have, cost the headless and traditional options against your own numbers, and if the move is worth making, build the content model, the preview path and the redirect map. All of it runs remotely.