What is headless WordPress?
Headless WordPress keeps WordPress as the place where editors write, and replaces the PHP theme with a separate front end, usually Next.js or Nuxt. The front end reads content through the REST API that ships with WordPress or through the WPGraphQL plugin. Editors keep the interface they know. Visitors get a front end that is built and served separately.
WordPress is GPLv2 and open source, so you can self host or use a managed host. Everything you know about plugins still applies, except the ones that print HTML on the front end.
Who is it for?
It suits teams with a large WordPress library and trained editors who want a faster, more secure front end without retraining everyone. It also suits sites that need the same content in a website and an app.
If you are still deciding whether to keep WordPress at all, read our WordPress vs headless CMS comparison, which walks through when classic WordPress is enough.
What changes, and what breaks
| Area | Classic WordPress | Headless |
|---|---|---|
| Rendering | PHP theme | Next.js or Nuxt app |
| Content API | Built into theme | REST or WPGraphQL |
| Custom fields | ACF in templates | ACF exposed to GraphQL |
| Preview | Built in | Needs wiring on the front end |
| Forms, search, SEO plugins | Plugin renders output | Plugin data must be fetched and rendered by you |
| Page builders | Work on front end | Elementor and similar do not render in a decoupled front end |
The last two rows cause most surprises. A plugin that outputs a shortcode or builder layout has no value to a separate front end, so we list every plugin early and decide for each one: keep as data source, replace, or drop.
What do we build?
Content model. We model custom post types and ACF field groups so they map cleanly to GraphQL types, and flatten page builder layouts into flexible content blocks.
API layer. WPGraphQL with the ACF extension for most projects. We add caching, query limits and authentication for previews, and use REST only where a plugin offers nothing else.
Front end. Next.js with static generation and revalidation when an editor publishes. Previews, menus, redirects, sitemaps, Open Graph data and schema markup are carried over from the old SEO plugin so rankings hold. Our Next.js development team writes this part.
Hosting and security. The WordPress admin moves behind authentication and off the public path, which removes most of the attack surface that made WordPress a target.
When is headless WordPress the wrong choice?
When editors depend on page builders, the cost of rebuilding every layout as a component can exceed the gain. When the team has no front end engineers, a decoupled site adds two systems to maintain. When you want to leave PHP entirely, a different CMS fits better, and we compare Strapi and headless WordPress for that case. WP Engine also sells a packaged option, covered on our Atlas page.
Migration and proof
If you move from classic WordPress to a headless front end, content mostly stays where it is, which makes this the lowest risk route. If you move off WordPress completely, see WordPress to headless CMS migration.
For an archetype, a US-based Series-B fintech moved its marketing site from WordPress to Payload and Next.js. Publish time fell by about 65% and LCP went from 4.2s to 1.4s, since editors no longer waited on developer deployments. That project did not keep WordPress as the backend, but the front end and redirect work are the same.
Working with us
We run headless WordPress projects end to end, or you can hire headless WordPress developers. Our band is $50 to $150 per hour. For other platforms see our headless CMS overview.
