Running WordPress as a headless CMS behind fast Next.js frontends.
Headless WordPress keeps the familiar dashboard for editors while a separate frontend, here Next.js, renders the public site from the REST API. It can make a site faster and more flexible, but it adds a second application to build, host and monitor.
This path explains when that trade is worth it and how to run it in production: typed data fetching, caching and on-demand revalidation, sanitising WordPress HTML, images, previews and SEO. This website is built the same way.
Who it’s for: WordPress developers moving to React and Next.js, and teams planning a headless rebuild.
Start with lesson 1: Headless WordPress with Next.js App Router: a production architecture guide
Editors expect the Preview button to work. In a headless setup it doesn't, until you build it: an authenticated preview route, Next.js Draft Mode, fetching drafts and revisions with an Application Password, and pointing WordPress's preview link at the frontend.
A practical comparison of the WordPress REST API and WPGraphQL for headless sites: what each request looks like, over-fetching and round trips, custom fields, caching, previews, security and the plugins each one needs.
How to run WordPress as a headless CMS behind a Next.js App Router frontend: data fetching, caching, on-demand revalidation, sanitizing content, images and SEO, with code you can reuse.