The WordPress Headless Pattern I Am Finally Shipping

I have been skeptical of headless WordPress for years. The promise was good, the implementations were brittle. In 2026 I finally shipped a headless setup for a client that survives real editorial workflows. Here is the pattern, the stack, and what made this attempt work when previous ones did not.

The Stack

• WordPress with the WPGraphQL plugin as the content API
• Next.js as the frontend with ISR for speed
• Vercel for hosting the frontend
• Managed WP host for the backend (not self-hosted)
• Cloudflare in front for the cache and edge protection

What Made This Attempt Different

I stopped trying to match the WP editor experience one to one. Editors use the native WP admin. The frontend fetches and renders. Trying to bolt custom Gutenberg blocks onto headless was the failure mode of every previous attempt I made. The editor wants WP native. Give them WP native.

The Revalidation Flow

// Webhook from WP triggers Next.js revalidation
export async function POST(req) {
  const { slug } = await req.json();
  await res.revalidatePath(`/blog/${slug}`);
  return Response.json({ revalidated: true });
}

Editors see updates within 10 seconds of publishing. That is fast enough to not complain. The first implementation was 5 minutes, which was too slow and prompted a stream of 'is it broken?' tickets. Ten seconds is the threshold where humans stop noticing the delay.

What Still Needs Work

Preview mode. The native WP preview does not point at the Next.js frontend without custom glue. I wrote that glue and it works but it is brittle. If I redid it, I would budget more time for preview. It is the feature editors use most and the one that looks worst when it breaks.

When Headless Wins

When the frontend needs to be faster or more custom than WP themes allow. When the editorial team is already on WP and will not move. When SEO demands core web vitals that WP themes cannot reliably hit. Otherwise, classic WP is still fine.

The Cost Reality

Headless costs more to build and maintain than a classic WP site. Roughly 1.5 to 2x the engineering effort. The performance and flexibility gains have to justify that cost. For most SMB sites, they do not. For enterprise content operations with real traffic, they clearly do.

The Lesson From Previous Failures

Every time I failed at headless before, the root cause was trying to replace too much of the WP experience. This time I replaced the rendering layer and kept everything else. That restraint is what made it ship.