Headless WordPress on Next.js or Astro — keep wp-admin, lose the plugin tax.

Headless WordPress is right when one of three things is true. The default classic WordPress setup is wrong otherwise — headless adds engineering overhead and you should not pay for it without a real reason.

The first reason is performance. A vanilla WordPress site with five or six plugins ships about seven hundred kilobytes of JavaScript before the H1 renders, and with Elementor or Divi plus a typical addon stack, real-world sites ship two to three megabytes on first load. There is a hard ceiling on Lighthouse and CrUX field data even with the best caching plugin in front of it. Headless on a static or ISR Next.js or Astro front-end clears ninety-five plus Lighthouse on shared hosting consistently and the field data follows.

The second reason is engineering experience without losing the editorial team. Engineers who write TypeScript daily get frustrated by the WordPress front-end stack. PHP templates, jQuery, page builder shortcodes — the language is wrong, the tooling is wrong, the deploy story is wrong. Headless lets the engineering team work in a Next.js or Astro codebase with version control, type checking, edge deployment, and component-driven design while editors keep wp-admin, Yoast, and ACF unchanged.

The third reason is multi-destination. A marketing site, a mobile app, an internal portal, and a partner portal all reading from the same content source. Classic WordPress is one CMS, one front-end. Headless WordPress becomes the editorial back-end for whichever destinations you need, each with its own front-end framework optimised for its surface.

Three decisions decide most of the engineering story.

The front-end framework is usually Next.js with App Router for marketing sites and apps with auth or interactivity. Astro is the simplest path for content-heavy sites that benefit from static generation and need partial hydration only on specific components. Nuxt is the right choice when the team already runs Vue. We default to Next.js plus WPGraphQL plus a small custom scaffolding rather than Faust.js because Faust ships opinions we sometimes disagree with — but Faust is excellent if you want the framework to make the decisions for you.

The API layer is WPGraphQL by default. Typed query-by-shape API, ACF support via WPGraphQL for ACF, Yoast support via Yoast SEO for WPGraphQL, RankMath equivalent. WP REST works without a plugin and is fine for simple sites, but you fetch more data than you need and there is no schema introspection on the front-end. Reach for REST only when WPGraphQL is blocked by hosting policy or when you have a very small dataset.

Hosting separates the front-end from the back-end. Front-end on Vercel, Netlify, or Cloudflare Pages depending on team preference. Back-end on Cloudways, Kinsta, or WP Engine on a non-public subdomain — cms.yourdomain.com — locked behind Cloudflare Access or an IP allowlist. Public traffic never hits WordPress directly. WordPress becomes invisible from the public web; only your editors know it is there.

A successful headless WordPress build transports five things from the WordPress side to the public front-end without losing fidelity along the way.

Content is the obvious one — every post, page, custom post type, taxonomy, and ACF field, fetched via WPGraphQL on build or revalidation. Media follows: every uploaded image, with WordPress-side WebP optimisation if available or front-end-side image optimisation otherwise. SEO metadata is the third — Yoast or Rank Math fields bridged via plugin-companion GraphQL schemas, rendered as canonical, title, description, OG, and Twitter card from the typed response.

Schema is the fourth and most teams handle it wrong. We replace plugin-emitted JSON-LD with hand-written templates on the front-end for cleaner output. Article, BlogPosting, Service, Product, BreadcrumbList — all generated from typed data, validated at build time. Redirects are the fifth: anything in Yoast Redirect Manager or the Redirection plugin gets exported and shipped as 301s in vercel.json or _redirects on Netlify, never as JavaScript redirects that lose ranking signal in transit.

The transport is automated. We do not hand-build any of these layers per site. The same scaffolding ships across every headless build we do, which is why the per-site cost has come down over time even as the engineering surface has grown.

Page builders break first. Elementor and Divi inject heavy CSS and HTML into the front-end. None of that runs on a headless front-end. Most migrations ship a content rewrite as part of the project — we extract the content, reformat it to match the new front-end's component library, and skip importing the visual builder layer entirely. Editors get a new, simpler editing UX based on Gutenberg blocks plus ACF flexible content. The content survives, the visual builder does not, and the page weight drops significantly as a side effect.

Comments and forms also need rethinking. Native WordPress comments do not render headless without proxying the rendering. Most teams replace them with Disqus, Giscus, or a custom comment system on the front-end. Forms typically migrate to ConvertKit, HubSpot Forms, or a custom Next.js endpoint hitting an email-sending service. Contact Form 7 and Gravity Forms have headless-friendly versions but require explicit GraphQL integration that adds work.

Front-end plugins are the third thing that breaks. Anything that injects HTML or JavaScript into the WordPress front-end stops working — security plugins, caching plugins, schema plugins, social-share plugins. Each one gets either replaced by code on the front-end or by a managed service. The plugin count typically drops seventy to eighty percent post-migration. That is part of the win, not a regression.