Headless WordPress for B2B Companies
Headless WordPress separates editing from delivery: WordPress manages the content, a separate frontend renders it. The split pays off for a short list of clear requirements, and it costs more to run than a classic setup, permanently.
The word headless comes up early in most relaunch workshops. The content still lives in WordPress, the frontend is built in React or Next.js, and an interface sits between the two. Behind that are usually two expectations: faster pages and more design freedom.
Headless delivers both, but so does a well-built classic setup for most business websites. A clean theme with solid caching passes Core Web Vitals, and custom Gutenberg blocks give you design freedom beyond templates. What matters is whether your project needs something only a decoupled frontend can do.
What Headless Actually Means
Headless WordPress means WordPress only manages and serves content, while a separate frontend handles the display. The connection runs through the REST API, the interface for structured data exchange between systems. It has been part of the core since version 4.7 in 2016 and exposes posts, pages, media, and custom content types as JSON. The frontend, built with React, Vue, or Next.js, fetches that data and renders it without PHP and without a theme.
In a classic setup, WordPress handles both. The theme and blocks determine the look, editors see roughly the final result right in the editor, and nothing sits between content and output. Which variant fits is one of the fundamental decisions in any WordPress architecture.
Where the Split Pays Off
Headless makes the biggest difference when you publish the same content more than once. If the same text needs to appear on the website, in an app, on showroom screens, and in a newsletter, a single source saves real editorial time. The same goes for frontends that behave more like applications than websites: configurators, login-protected portals, search interfaces with many filters and states.
A decoupled frontend also helps once your performance goals go beyond good caching. Serving statically pre-rendered pages through a CDN is easier to fine-tune there than through WordPress’s own render chain. If you already have a TypeScript team and are planning a decoupled system from day one, Payload CMS is often the better starting point than a WordPress split apart after the fact.
What Two Systems Cost You Day to Day
From the day you split them, you’re running two applications. Two deployments, two update cycles, two sources of failure, and an interface between them that needs securing and versioning. Anything you used to solve with a plugin — a form, a filtered search — now has to be built by hand.
Editors feel the difference most. The block editor deliberately ties content to its display, so decoupled projects often lose the live preview and the layout options built into the blocks. At Lernstudio Barbarossa, more than 165 location managers maintain their own content without ever filing an agency ticket. A setup like that depends on exactly the editor a split would weaken.
In Favor
- Website, app, and other channels from one content source
- Frontends that behave like apps: configurators, portals, filtered search
- Finer control over static rendering and CDN delivery
- Free choice of frontend stack, no ties to PHP or a theme
Against
- Two applications, each with its own deployments and update cycles
- Forms, search, and preview become custom development work
- Editors lose some of the comfort of the block editor
- A standing need for frontend expertise, in-house or at an agency
What Matters During Implementation
Once you choose headless, the frontend takes over jobs that WordPress and its plugins used to handle. Four of them decide whether editors and search engines can actually work with the new frontend.
Getting New Content Into the Frontend
Statically generated pages load fast, but only show the state of the last build. When an editor publishes a post, WordPress notifies the frontend, usually through a webhook, and the frontend rebuilds the affected pages. Next.js handles this with Incremental Static Regeneration and targeted revalidation of individual paths. Without that mechanism, changes only show up at the next full build.
Setting Up Preview for Drafts
The REST API only releases drafts to logged-in accounts. To preview them, the frontend needs authenticated access. An Application Password, built into WordPress since version 5.6, is the usual choice. On top of that, you need a dedicated preview mode; Next.js calls it Draft Mode. A filter in WordPress then points the editor’s preview button to that route. Budget this work in from the start, or editors won’t see their page until it’s published.
Carrying Over SEO Data, the Sitemap, and Redirects
Rank Math and Yoast both expose title, meta description, and structured data through the REST API. The frontend has to fetch that data and write it into the head of every page itself. Redirects from the Redirection plugin, by contrast, only work on the WordPress domain. In a decoupled setup, they belong in the frontend configuration or at the CDN. The XML sitemap needs adjusting too, so its URLs point at the frontend domain.
Locking Down the Backend
If the frontend renders statically or server-side, the WordPress backend no longer needs to be publicly reachable. It can sit on its own subdomain behind an IP allowlist, with visitors only ever seeing the frontend. The API still needs clear rules for which endpoints answer without login and what data they expose. By default, for instance, /wp-json/wp/v2/users lists every author account on the site.
Decoupling Just Part of the Site
Between classic and fully decoupled WordPress sits a middle option that’s enough for many mid-sized projects. WordPress keeps rendering the website itself, and only the app-like sections run as a separate React application. A product configurator or dealer locator sits on the page as a block and pulls its data through the REST API. If products or locations already live in WordPress through an API integration with your ERP or CRM, the application uses the same data as the rest of the site.
For smaller interactive pieces — filters, tabs, wish lists — the Interactivity API, part of the core since WordPress 6.5, is often enough. It brings state and reactivity into custom blocks without a second frontend and without a separate deployment.
Editors keep the editor, preview, and plugins on every other page. You only need frontend expertise for that one application. If this scope stops being enough later on, the content model and the API are already in place, and the step to a fully decoupled setup is smaller.
Common Questions Before the Decision
What is a headless CMS?
A headless CMS manages content and doesn’t output finished HTML. A separate frontend handles the display, pulling content through an interface, usually as JSON. The name refers to the missing head — the missing output layer. WordPress, Payload CMS, and Strapi can all be run this way.
Can you use WordPress as a headless CMS?
Yes, without any technical detours. The REST API delivers posts, pages, media, and custom content types as JSON, and WPGraphQL adds a GraphQL layer on top. That’s where the easy part ends. You build, host, and maintain the frontend yourself, and familiar plugin features disappear.
Can an existing WordPress site be converted to headless?
Yes. WordPress keeps running as the backend, and your content, media, and user accounts stay intact. The frontend, though, gets built from scratch — preview, SEO data, and redirects included. It gets expensive with pages built in page builders like Elementor, because they store content as layout data that’s tightly bound to how it’s displayed.
Does AI visibility require a headless CMS?
No. AI visibility depends on how your content is modeled, not on your architecture. WordPress with well-defined custom post types, custom fields, and Schema.org markup meets the bar just as well as a decoupled system. Free-text pages with no structure are just as hard for machines to use in Payload.
What's the difference between headless and classic WordPress?
In a classic setup, WordPress renders the page itself, the theme and blocks determine the output, and editors see a preview right in the editor. In a headless setup, WordPress only delivers data, and a separate frontend generates the HTML. The same content sits behind both — what differs is how it’s run.
What does a headless setup cost on top?
There’s no reliable flat rate, but the cost drivers are easy to name: a second application with its own hosting and deployment, custom development for forms, search, and preview, plus a standing need for frontend expertise, in-house or at an agency. These costs recur every year.
What does headless mean for SEO?
Both are manageable — the work just shifts. Rank Math or Yoast still generate the meta data and structured data, but in a decoupled setup the frontend has to output it, along with the sitemap and redirects. Server-side rendering or static generation aren’t optional. Google renders JavaScript with a delay, and many AI crawlers don’t render it at all.
Who maintains the frontend long-term?
This question belongs before the project starts, not after. A React or Next.js frontend needs matching expertise on an ongoing basis, whether that’s in-house or at an agency. With integrations like Kampmeyer Immobilien‘s onOffice connection, the direction data flows in also matters more for the effort involved than which frontend technology you pick.
We collect more questions like these under Answers.
What the Choice Comes Down To
Headless answers a frontend requirement. If that requirement exists, it justifies the extra work. If it doesn’t, you’re paying for complexity with nothing to show for it.
Before the project starts, check which channels your content actually needs to reach, and who will still be maintaining the frontend in three years. For many projects, the answer turns out to be a classic setup with a single decoupled application bolted on. We’ve been making this call as a WordPress agency since 2012, across more than 500 projects by now.
Facing a headless decision of your own?
Tell us about your case. We’ll tell you whether decoupling is worth the effort.
