Headless WordPress with Next.js is excellent when it fits. It’s also a bigger commitment than most articles admit. Here’s what I’d want a client to know before they sign off on the rebuild.
What you actually gain
- Edge-cached pre-rendered pages — sub-1s LCP across geographies, not just your local one.
- React/Next ecosystem — animation, state, modern dev tooling.
- ISR (Incremental Static Regeneration) — content can change without a full rebuild.
- Decoupling — the editor never breaks the front-end and vice versa.
What you actually pay
- Two systems to maintain — WP backend + Next front-end. Two deploy pipelines, two security models, two on-call surfaces.
- Editor experience regression — preview, draft, scheduled posts all need careful wiring.
- Plugin ecosystem reduction — most WP plugins assume they render the front-end. Most won’t work in headless.
- Content modeling discipline — sloppy ACF setup that worked in classic WP becomes very visible in a typed schema.
The four moments where it breaks
1. Preview mode
Editors expect “Preview” to show their drafts. With ISR you need to wire up Next’s draft mode + a preview JWT + a way for WP to pass the post ID. Most teams underestimate this. Set aside a full sprint for it.
2. Forms
Gravity Forms / Fluent Forms render server-side in WP. Headless = forms render client-side in Next. Either rebuild forms in React (most flexible) or hit the WP REST endpoint via fetch (fast, less flexible). Either way it’s not “free”.
3. SEO plugins
Yoast / Rank Math write meta tags into the WP head. Next renders its own head. You have to fetch the SEO data via GraphQL/REST and re-render it. The plugins have headless-aware extensions but the integration takes work.
4. Image handling
WP’s image library + Next’s <Image> component don’t naturally play together. You need a custom loader so Next can transform/serve images coming from WP’s media library. Common pattern, but it’s another thing to maintain.
When to do it anyway
Three situations make headless WP unambiguously the right call:
- Content is rendering in multiple places (web + native app + partner widgets).
- Performance budget at edge level matters more than editor familiarity (e.g. global publisher).
- You have React/Next capacity in-house and can’t justify two stacks.
When to skip it
You’re a marketing site with one front-end, no app, no edge requirement, and a team that mostly writes content. Headless WP would technically work but you’d be paying complexity tax for benefits you won’t measure. Stay traditional WP, optimize the theme, ship more content.