Headless WordPress is the right answer more often than people expect. Your marketing team already knows the WordPress admin, your content already lives there, and the plugin ecosystem solves problems you would otherwise rebuild. What WordPress is bad at is delivering that content quickly to a browser. So keep the admin, replace the theme layer with Next.js, and pull content through WPGraphQL at build time or on a revalidation schedule.
The failure mode of headless WordPress is a setup that is technically elegant and miserable to write in. Preview stops working, ACF fields do not map to anything visible, and the team quietly goes back to the old site. I treat the editing experience as part of the deliverable: working previews, sensible field groups, and a written guide for the people who publish.
WPGraphQL lets the Next.js frontend ask for exactly the fields a page needs, which matters when a single post carries dozens of ACF fields. It also makes ACF and custom post types far less painful to consume. Where a project already leans on the REST API I will work with that instead — the point is fewer round trips, not a particular library.
The riskiest part of going headless is not the build, it is the switchover, which is why I plan it as a full WordPress to Next.js migration in its own right. Permalinks, redirects, canonical tags, structured data and whatever Yoast was emitting all have to be reproduced on the new frontend. I map them explicitly before launch and verify in Search Console afterwards, so traffic does not dip.
Yes — that is most of the point. They write in the same admin with the same ACF fields. What changes is that the public site is served by Next.js instead of a PHP theme, and it is considerably faster.
They do, once wired up. Next.js draft mode plus an authenticated WPGraphQL query means an editor clicks Preview in WordPress and lands on the real frontend rendering the unpublished draft. I consider this non-negotiable in a headless build.
Admin-side and content-side plugins keep working — ACF, custom post types, editorial workflow. Plugins that inject frontend markup or scripts do not, because there is no theme to inject into. I audit your plugin list before the project starts and tell you which ones need a frontend equivalent.
Often not. If you have a dozen pages and no performance problem, a well-built classic theme is cheaper and simpler. Headless earns its keep when you have real traffic, a content team, and a frontend that needs to do more than a theme comfortably can.