“If the team can’t name the front-end framework they’re committing to before the meeting ends, they’re not ready for headless.”

— Owen, in this episode

Last month, three different clients told me they were going headless. Two of them couldn’t tell me why. One pointed at a slow load time. One said the team wanted to use React. The third had read about headless commerce and was sure it applied. None of them had done the test that matters.

Headless WordPress is the right answer to about one problem in five it gets applied to. The other four — slow site, brand inconsistency, hard-to-train team, mediocre content workflow — get worse when you split the front and the back. There are two systems to maintain now, and there’s a developer dependency where editors used to ship without one. A bad headless decision costs about two years and the back half of an editorial team’s morale. The front end gets faster. The content team gets slower. Content teams beat front-end speed for revenue impact every time — and the bottleneck-in-one-sentence question I went through with Walter in the enterprise WordPress episode is the question that should have been asked here, in this room, before the architecture conversation started.

This episode is about what headless actually solves, what it actually breaks, and the four-question test that should happen before any headless project gets signed.

To go with this episode, I wrote that four-question test out long-form — the failure modes for each question, and the decision rule at the end. Download the headless four-question test.

The source essay this episode is built from: Headless WordPress in 2026: When It Helps and When It Hurts.

Chapter markers

Most modern podcast clients (Apple Podcasts, Overcast, Pocket Casts) surface these as jump-points.

00:00 — Cold open: One in five
00:46 — Act 1: The contrarian read
01:15 — Act 2: The test that matters, schema, preview
03:42 — The turn: Name the framework
04:08 — Act 3: Three flavours, four-question test
06:11 — Close: What’s your bottleneck
06:30 — Sign-off

In this conversation

Christopher — host, has watched the headless decision go both ways with many clients
Frances — peer-founder push: organisational gravity wins, regardless of whether the technical case is real
Walter — eighteen-year witness; brings the editorial-workflow problem (preview button, page builders, the SEO plugins that quietly stop rendering schema)
Owen — turn-deliverer; lands the rule about naming the framework before the meeting ends

The three flavours that dominate in 2026

If a headless WordPress project is on the table, these are the three stacks worth evaluating:

Faust.js + Next.js (maintained by WP Engine) — opinionated, fastest path from “we have WordPress” to “we have headless.” Trade-off: tied to the Next render model and to WP Engine’s hosting recommendations.
WPGraphQL + Astro or Eleventy — static-site generation against the GraphQL schema. Lower runtime cost; harder to set up dynamic personalisation. Best for content-driven sites with a steady publishing cadence.
WPGraphQL + bespoke React, Vue, or Svelte — maximum flexibility, maximum maintenance. Requires a dedicated front-end team to keep alive.

If anyone is still pitching Frontity, the proposal is out of date — Frontity has been deprecated since 2022. If it’s in the proposal, the proposal didn’t get a 2026 refresh.

The failure modes the test exists to catch

Two specific things break in headless projects that nobody puts on the calendar until launch week, and both made it into this conversation because they’re the ones I’ve seen ship as cracks under the foundation.

Owen brings the SEO one: every Yoast and Rank Math assumption breaks the moment the WordPress front end stops rendering the page. Schema, canonical tags, meta descriptions, sitemaps, redirects — none of those plugins render structured data in headless without explicit additional work. Most teams discover this two weeks before launch, when somebody runs the rich-results test on the staging URL and watches half the markup disappear. By then nobody has the capacity to rebuild the structured-data layer, so the launch ships with broken schema and the rankings move accordingly.

Walter brings the editorial one: the preview button. In a standard WordPress site, the preview button shows the editor the post as it will render to a reader — save, preview, save, publish. In a headless site, that preview lives in a separate front-end environment that has to be wired up deliberately. Until it is — and it almost always gets deferred to a “phase two” that takes six months — the editors are working blind. The editorial team usually finds out about this in launch week, or the week after.

The four-question test exists because the calendar didn’t have any of that in it when the team signed.

Credits

Host: Christopher Ross — voice clone trained on Christopher’s recorded audio, used in the studio with his authorisation
Frances, Walter, Owen: synthesised cast personas, characters in the show
Audio production: in-house, Sites I’ve Never Seen studio
AI disclosure: see my standing stance on disclosing every use of AI — the cloned host voice and the synthesised cast both fall under it

Listen

Subscribe in your podcast app of choice — the show is on Apple Podcasts, Spotify, Pocket Casts, Overcast, YouTube Music, Amazon Music, and the Podcast Index. If your app asks for a feed URL, the canonical RSS (Really Simple Syndication) feed is thisismyurl.com/feed/podcast/.

Or download the MP3 (audio file) directly.

What to do next

If you’re in a headless conversation right now — or evaluating a proposal that’s quoted you a headless rebuild — the four-question test is what to take into the next meeting. If you’d like a second set of eyes on what your test turned up, send me a note.

Thanks for listening. — Christopher

Full transcript

Transcript — Episode 0004: Headless WordPress in 2026: When It Helps and When It Hurts

Full accessible transcript of the episode. Speaker labels match the audio. No stage directions, no IPA tags — this is the version for screen-reader and reader audiences.

Christopher: Last month, three different clients told me they were going headless.

Two of them couldn't tell me why.

One pointed at a slow load time. One said the team wanted to use React. The third had read about headless commerce and was sure it applied.

None of them had done the test that matters.

Headless WordPress is the right answer to about one problem in five it gets applied to. The other four, slow site, brand inconsistency, hard-to-train team, mediocre content workflow, get worse when you split the front and the back. Because now there are two systems to maintain, and a developer dependency where editors used to ship without one.

Frances: You want to start with the contrarian read?

Christopher: Yeah. Because most teams I sit with don't realise it's contrarian.

Frances: OK. Here's what I'll push on. The teams who go headless aren't picking it from a menu of equal options. Their developers want React or Next on their resume. Their procurement wants a story that sounds modern. There's organisational gravity, and the gravity is one direction.

Christopher: Right. And the gravity wins, regardless of whether the technical case is real.

Frances: Most of the time, yeah.

Walter: Christopher, before we go further. What's the test that matters?

Christopher: One sentence. What's the bottleneck on this site, and where does it live? If the answer is the site is slow, that's not an answer. It's a symptom. The honest version sounds like, our category templates have twelve server-side queries that can't be cached because each user sees a different feed. That's a bottleneck on the front end. That's a candidate for headless.

Walter: And if the answer is, we have thirty plugins and the database is hot?

Christopher: Then the bottleneck is in the application layer. Headless doesn't fix it. Headless moves it behind a wall.

Owen: Can I cut in here?

Christopher: Please. Owen.

Owen: I want to bring up the part of this that gets ignored until launch week.

Christopher: Go ahead.

Owen: Schema. Canonical tags. Meta descriptions. Sitemaps. Redirects. Every Yoast and Rank Math assumption breaks the moment the WordPress front-end stops rendering the page. None of those plugins render schema in headless without explicit additional work. Most teams discover this two weeks before launch, when somebody runs the rich-results test on the staging URL and watches half the markup disappear.

Frances: Two weeks before launch.

Owen: Two weeks. And by then nobody has the bandwidth to rebuild the structured-data layer, so the launch ships with broken schema and the rankings move accordingly.

Christopher: I've watched that one. Twice.

Walter: There's a related editorial problem. The preview button.

Christopher: Walter, take that one.

Walter: In a standard WordPress site, the preview button shows the editor the post as it will render to a reader. That's the basic mental model. Save, preview, save, publish. In a headless site, the preview lives in a separate front-end environment that has to be wired up deliberately. Until it's done, and it almost always gets deferred to a quote-unquote phase two that takes six months, the editors are working blind.

Frances: And the editorial team finds out about this when?

Walter: Usually launch week. Sometimes the week after.

Frances: OK. So we're stacking up the failure modes. Schema breaks. Preview breaks. Custom Gutenberg blocks render differently in the front-end framework than they do in the back-end. WooCommerce doesn't work. Page builders don't work. Anything that injects scripts via wp_head has to be rebuilt.

Christopher: And the team's calendar didn't have any of that in it when they signed.

Owen: There's the version of this I'd write down as the rule.

Christopher: Go on.

Owen: If the team can't name the front-end framework they're committing to before the meeting ends, they're not ready for headless.

Not naming the framework means the conversation is being led by the symptom, not by the architecture. And a symptom-led headless decision is the most expensive kind of decision you can make in WordPress in 2026.

Christopher: Yeah.

Walter: What does it cost, in your experience?

Christopher: A bad headless decision costs about two years and the back half of an editorial team's morale. The front end gets faster. The content team gets slower. And content teams beat front-end speed for revenue impact every time.

Frances: Every time.

Christopher: Every time.

Christopher: So here are the three headless flavours that actually dominate in 2026, if anyone's still thinking about it after that. Faust dot js plus Next dot js. Maintained by W-P Engine. Opinionated. Fastest path from we have WordPress to we have headless. Trade-off, you're tied to the Next render model and to W-P Engine's hosting recommendations. W-P GraphQL plus Astro or Eleventy. Static-site generation against the GraphQL schema. Lower runtime cost. Harder to set up dynamic personalisation. Best for content-driven sites with a steady publishing cadence. W-P GraphQL plus a bespoke React or Vue or Svelte front-end. Maximum flexibility. Maximum maintenance. Requires a dedicated front-end team to keep alive.

Owen: And if someone is still pitching Frontity, the pitch is out of date.

Christopher: Frontity is deprecated. Has been since twenty twenty-two. If it's in the proposal, the proposal didn't get a 2026 refresh.

There's a four-question test before any headless project signs. What is the specific bottleneck, in one sentence?

Which framework are we committing to, and who owns it after launch?

What is the editorial workflow on day one of launch?

And what does the schema and canonical strategy look like for the new front-end?

If all four answers are crisp, headless is probably right for the site. If they're not, you're going to ship a faster front-end and a slower content team. And the slower content team is the one that matters for the business.

If you're in a headless conversation right now, here's the only question I'd ask you to take away. What is your bottleneck, in one sentence?

If you can't answer that without hedging, the right next step isn't headless.

It's the audit we talked about last episode.

Christopher: Thanks for spending the time with us.

If you're sitting in a headless conversation this week, the four-question test is the conversation worth having before the contract gets signed. The good vendors welcome it.

This is Sites I've Never Seen. Next time, a different shape — fifteen years of WordCamp talks, and the spine I didn't know I'd been holding.

Glad you were here.

Episode 4 — Headless WordPress