WordPress as the CMS, a modern front end.
WordPress manages the content. A separate front end, built in Astro, Next.js or similar and connected through the REST API or WPGraphQL, handles what visitors see.
The problem
Most sites don’t need this. Some genuinely do.
Headless WordPress means splitting the CMS from the front end. WordPress still holds your content, your editors still log into the same dashboard, but instead of a theme rendering pages directly, a separate application, built in Astro, Next.js or a similar framework, pulls that content through the REST API or WPGraphQL and renders it however it likes.
We’ll say this plainly, because plenty of agencies won’t: most sites don’t need it. A well-built custom block theme, properly cached, gets you fast pages, an editor experience your team already knows, and a fraction of the moving parts. If your site is a marketing site, a brochure site or even a busy content site with normal traffic, headless usually adds cost and complexity without a matching benefit.
Where it earns its place is different: a native app that needs the same content as the website, content going out to several channels at once, traffic and performance targets a standard WordPress theme genuinely can’t hit, or a front end built in a framework your product team already works in for other things. If one of those is true for you, headless is a serious option worth building properly, not a trend to chase because it sounds modern.
What you get
What’s included in a headless build.
WordPress as the CMS
Your editors keep the WordPress dashboard they already know, managing content, media and structure the same way, with nothing about their day-to-day workflow forced to change.
API layer
Content exposed cleanly through the REST API or WPGraphQL, structured for exactly what the front end needs, not a generic dump of every field WordPress happens to store.
Front end build
A fast, modern front end built in Astro, Next.js or the framework that suits your team, rendering your content and handling routing, images and interactivity.
Live preview
Editors can preview draft content on the real front end before publishing, which is the piece that gets skipped in a rushed headless build and causes the most complaints.
SEO carried across
Metadata, structured data and redirects managed in WordPress and rendered properly on the front end, so moving to headless doesn’t cost you search visibility.
Hosting for both halves
The WordPress backend and the front-end app hosted and configured as one system, not two separate projects that happen to talk to each other. See our hosting page.
Process
How a headless build runs.
Assessment
We look at your traffic, your plugins, your team’s workflow and what the front end actually needs to do, and tell you honestly whether headless is worth the extra complexity.
API design
We design the WPGraphQL or REST API structure around the content your front end needs, and decide what stays a standard WordPress feature versus what gets custom-built.
Front-end build
The separate front end gets built, with AI helping scaffold routing, components and the API integration layer while a person reviews the structure and the output.
Preview and editorial testing
Editors test drafting, previewing and publishing on the real system before launch, so the workflow is proven, not assumed to work.
Launch and handover
Both halves go live together, with a walkthrough for your editorial team and documentation for whoever maintains the front end afterwards.
Why Maku
Why we’re honest about when headless helps.
We build both classic WordPress sites and headless ones, so we’ve got no reason to push you towards the more complicated, more expensive option if a block theme would do the job. When headless is the right call, we build the whole system, backend, API and front end, as one project rather than handing you a half-finished API and leaving the front end to someone else.
- Straight advice during scoping about whether headless suits your traffic, your team and your plugins, before you commit to the extra build and hosting cost.
- Live preview built and tested properly, so editors aren’t publishing blind to see how content actually looks.
- A separate front end removes a lot of the common WordPress attack surface, since there’s no theme or page builder rendering directly to visitors, though the API layer and the front-end app bring their own security considerations we account for.
- One maintenance plan covering both halves, so updates to WordPress and updates to the front-end framework stay in sync instead of drifting apart.
Migrating from a classic theme
Moving from a normal WordPress theme.
Most headless projects start life as a normal WordPress site with a classic or block theme. The content, structure and editorial workflow already exist, so a migration to headless is really a front-end rebuild plus an API layer, not a content migration from scratch. We audit the existing theme and any plugins that render front-end markup first, since page builders and some display plugins don’t carry across, and plan replacements for anything the new front end needs to handle instead.
Is headless WordPress actually faster than a normal WordPress site?
It can be, because the front end is a separate, lightweight app that isn’t rendering PHP on every request. But a well-built block theme with proper caching gets most sites most of the way there anyway. Headless is worth the extra complexity when you need very high traffic performance or a front end that a normal theme can’t deliver, not as a default speed fix.
Will our editors lose the ability to preview pages before publishing?
Not if it’s built properly. Live preview takes real integration work in a headless setup, since the editor and the front end are separate systems, but it’s a standard part of how we build these. It’s a fair question to ask any headless build, because a broken preview is one of the most common complaints from editorial teams.
What happens to plugins that render things on the front end, like page builders or SEO plugins?
Plugins that generate front-end markup, page builders especially, mostly stop working as intended, because there’s no front end left for them to render into. SEO plugins still work for managing metadata, since that data gets pulled through the API. We audit your plugin list before recommending headless, so there are no surprises partway through.
Can we go back to a normal WordPress theme later if headless doesn’t suit us?
Yes. WordPress stays the CMS either way, so your content isn’t locked into the headless setup. Moving back means building or restoring a theme that renders the front end directly, which is real work, but the content, users and structure in WordPress carry across without a rebuild from scratch.
Do you maintain both the WordPress backend and the separate front end?
Yes, as one system. We look after WordPress core, plugins and the API layer, and the front end’s framework, dependencies and hosting, so updates to one side don’t quietly break the other. That’s covered through a maintenance plan scoped for a two-part setup, not our standard single-site plan.
What does a headless WordPress build cost?
It costs more than a standard WordPress build, because you’re effectively building and hosting two systems instead of one. The real number depends on the front-end framework, how much content needs to move through the API and what the front end needs to do. We scope it properly and quote a fixed price. Tell us what you’re building and we’ll price it.