Headless WordPress: when it fits and how I quote the build

You know WordPress, but the front end outgrew a theme

The usual trigger is not curiosity about architecture. Marketing or operations already publish in WordPress, sometimes for years, or they just moved to it, and nobody wants to retrain on a new CMS. WordPress is the most widely used CMS on the web, so that is a very common position to be in. At the same time, the product direction needs custom tools, client-facing workflows, or several small applications in the browser, not a classic marketing or corporate site wrapped in a theme.

In a headless setup, WordPress stays the content back end on PHP. A separate front end, usually Next.js or React on JavaScript, loads posts, pages, custom types and fields through the REST API at `/wp-json/wp/v2/` and renders the experience you actually need. WordPress no longer owns the public HTML layout; it owns the content and much of the admin workflow your team already trusts.

Who headless is for, and when a normal WordPress site is better

Headless earns its complexity when WordPress should remain the editorial system but the visitor experience is intentionally custom. If the goal is a straightforward published site with visual editing and no application behavior, a standard WordPress build is simpler and faster to operate. See WordPress web design for that path.

A web application disguised as a website

When I say a web application disguised as a website, I mean the visitor flow behaves like software: authenticated areas, multi-step tasks, dashboards, configurators, or several small apps that share content and business rules. It may still look like a brand site from the outside, but the hard problems live in interaction design and integration, not in picking a theme demo.

• Keep WordPress for content

  Your team keeps posts, pages, custom post types and fields in the dashboard they already know. Training cost stays low compared with moving editorial work to a new headless CMS.

• Skip a custom admin for everything

  WordPress already provides roles, workflows, revisions and media. Pairing it with the REST API often avoids building a separate content admin just to launch the application side.

• Trade theme limits for front-end freedom

  You are not customizing a theme until it breaks. You build a purpose-made interface focused on the jobs your users need to do, while WordPress supplies structured content.

That combination can reach launch day faster than standing up a new CMS plus a bespoke admin, and it is sometimes cheaper, because the editorial layer reuses WordPress instead of being rebuilt. Sometimes cheaper is the honest limit: integration depth, previews and migration work can still dominate the budget.

The stack I use

Most of the time I choose Next.js for the public front end, or React when the project already standardizes on it. The browser experience is JavaScript; WordPress remains PHP on the server as the content system of record. Data flows through the WordPress REST API by default. GraphQL is available through plugins such as WPGraphQL if a team already standardized on it; I still default to REST unless there is a concrete reason to add that layer.

Define the content model up front: custom post types, taxonomies, required fields and which objects the front end must list, filter and detail. Changing the model mid-build ripples through templates, caching and SEO. For deeper product work outside WordPress, compare custom web app development and API integration services.

Plugins: decide before the build

A major advantage of keeping WordPress as the back end is that many plugins still add value on the server: SEO metadata, forms processing, security hardening, caching at the origin, custom post types and workflow. The catch is compatibility: decide the plugin list during scoping so you connect only what the front end truly needs, instead of paying to reverse-engineer every dashboard feature.

SEO in a headless build

Search engines still need clean HTML, stable URLs and accurate metadata on the domain visitors use. Headless does not remove SEO work; it moves part of it into the front-end codebase. I do not promise rankings. I do make sure metadata and content are present in the rendered page source.

When Yoast SEO is part of the stack, I integrate what Yoast already calculates into the Next.js or React layout. For posts and pages, Yoast adds `yoast_head` (prefabricated head HTML) and `yoast_head_json` (structured data) to REST responses. For arbitrary URLs, Yoast exposes `/wp-json/yoast/v1/get_head?url=`. Title, meta description, canonical, Open Graph and schema can flow from those outputs into server-rendered or statically generated pages so crawlers see them without executing a client-only shell.

Previews and editing

Be direct about limits: headless does not give editors a live block-editor preview of the custom front end out of the box. The Preview button in WordPress assumes the theme renders the site. Once the theme is decoupled, preview becomes explicit integration work, not a free extra.

1. Step 1

   Accept that drafts require authenticated API access

   Unpublished content is not available from anonymous REST calls. Use application passwords or another agreed mechanism so the front end can request draft payloads securely.

2. Step 2

   Wire Next.js Draft Mode (or equivalent)

   A secret-protected route on the front-end site enables draft mode when opened from WordPress preview links. While enabled, data fetching uses authenticated requests against the REST API.

3. Step 3

   Document what editors should expect

   Clarify which post types preview, how long draft mode lasts, and whether layout matches production exactly. Partial preview is still common for app-like templates.

How I quote a headless build

Pricing depends on the complexity of the front end and the application you want visitors or staff to use, because that is the variable. We are not pricing a custom theme; we are pricing custom JavaScript focused on your workflows, plus how deeply the app must read and write WordPress through the REST API. Every project gets a fixed written quote before work.

1. Step 1

   Send what the application must do

   Describe user roles, screens, integrations and success checks in plain language. Attach wireframes or an existing site if they exist.

2. Step 2

   List plugins and content types you rely on

   Include SEO, forms, membership, multilingual tools and field plugins. Note which features must survive the move from a theme.

3. Step 3

   I scope front-end effort and integration depth

   I map templates, data flows, auth, previews, migrations and hosting setup. Unknowns become assumptions in writing, not silent extras.

4. Step 4

   You receive a fixed written quote

   The quote states deliverables, exclusions and what requires a change order. Work starts after scope and quote are agreed.

Agencies can deliver under their brand through white-label web development. For advisory work before committing to a build, see WordPress consultant or WordPress outsourcing when you need a delivery partner.

What to send me

The fastest path to a useful quote is a concise brief plus honest constraints. Public URLs are fine for a first pass; credentials come after scope is agreed.

Organization and public site: {{name and URL}}
Why headless now: {{what broke or what the app must do}}
Users and roles: {{visitor, client, staff tasks}}
Must-keep WordPress pieces: {{post types, plugins, editorial workflow}}
Front-end expectations: {{Next.js or React, auth, languages, design reference}}
Integrations: {{CRM, payments, search, internal APIs}}
SEO and URLs: {{Yoast or other, domain plan, redirects needed}}
Previews: {{who previews drafts and how often}}
Hosting today: {{WordPress host; any front-end host preference}}
Timeline and constraints: {{launch window, compliance, approval chain}}