Headless WordPress promises the best of both worlds: editors keep the familiar publishing experience, developers get a modern front-end stack. After shipping a dozen headless projects, here is the honest guide I wish someone had handed me at the start.
When headless makes sense — and when it doesn’t
Choose headless when you have genuinely multiple consumers of content (web, apps, digital signage), hard performance requirements, or a front-end team that lives in React or Vue. Skip it when you have a content site with a small team: the block editor, previews, menus, and plugins you get for free in traditional WordPress take real engineering effort to rebuild against an API.
The stack
- Content API: the REST API ships with core; WPGraphQL is worth the plugin for complex queries
- Front end: Next.js remains the safest choice for incremental static regeneration
- Previews: solve this first, not last — editors will judge the whole project by it
- Webhooks: trigger rebuilds on publish with a small must-use plugin
The three problems everyone hits
First, permalinks: WordPress generates absolute URLs pointing at the CMS domain, and you will chase them through content, menus, and sitemaps. Second, previews: the editor expects to render drafts, and your static front end does not know about them — you need a preview route that queries drafts with authentication. Third, images: WordPress media URLs point at your CMS server, so put a CDN or image proxy in front early.
None of these are hard individually. Together they are the difference between a two-week estimate and a two-month project. Budget accordingly, keep the CMS and front end in separate repositories with separate deploy pipelines, and your future self will thank you.
Leave a Reply