By Mehdi HassanIs headless WordPress with nextjs a good idea for a marketing site?
Headless WordPress with Next.js is a good idea when your editors rely on WordPress workflows, your content is large and structured, and you have developers to maintain both systems. For most small marketing teams, it adds more cost and complexity than it removes.
In a headless setup, WordPress stores and edits content, and a separate Next.js front end fetches that content through an API and renders the site. It's often sold as the best of both worlds. It can be, but the costs are mostly hidden at the start and show up after launch. Our hub on where to go when you migrate from WordPress compares it with simpler routes.
How does headless WordPress with Next.js work?
Headless WordPress with Next.js works by exposing WordPress content through the REST API or GraphQL, usually with the WPGraphQL plugin, and having Next.js fetch it at build time or on request. WordPress stops serving pages to visitors; it becomes a content back end.
- Content API. The built-in REST API or WPGraphQL exposes posts, pages, menus, taxonomies and custom fields.
- Custom fields. Advanced Custom Fields data is exposed through an extension so templates can use it.
- Rendering. Next.js pages fetch content and render it statically, on the server or with incremental regeneration so updates appear without a full rebuild.
- Revalidation. A webhook from WordPress tells Next.js to refresh pages when content changes.
- Hosting. WordPress runs on its own host, ideally locked down; Next.js runs on Vercel, Cloudflare or similar.
The WPGraphQL plugin on wordpress.org and the Next.js documentation are the two references most builds start from.
What are the pros and cons of headless WordPress?
The main pros of headless WordPress are a fast, custom front end and an editor your team already knows. The main cons are lost plugins, harder previews, two systems to maintain and less editor freedom.
Pros
- Editors keep the WordPress interface, roles and workflows.
- The front end can be fully custom, fast and built with modern tooling.
- Content stays where it is, so there's no large import project.
- WordPress admin can sit behind access controls, reducing public attack surface.
- The same content can feed other channels, like an app or docs.
Cons
- Plugins that output on the front end stop working and must be rebuilt.
- Live preview and draft workflows need custom setup.
- Editors can't build new layouts with blocks or page builders as before.
- You maintain WordPress hosting, plugins and security plus a Next.js codebase.
- Every front-end change goes through a developer.
What are the hidden costs agencies selling headless skip?
The hidden costs of headless WordPress are plugin rewrites, preview, forms, search, SEO output and the loss of editor independence. Each sounds small in a proposal and turns into real development time.
Hidden cost | What changes in headless | What you'll need |
|---|---|---|
Plugin rewrites | Sliders, galleries, popups, tables and shortcodes no longer render | React components for each, built and maintained |
Preview | WordPress's preview button shows nothing useful by default | A draft mode in Next.js wired to authenticated API requests |
Forms | Contact Form 7 or Gravity Forms don't render on the front end | A form service or API route, plus CRM integration |
SEO output | SEO plugin fields exist but aren't printed into pages | Code that reads those fields and writes metadata and schema |
Search | Built-in WordPress search isn't on the front end | An API-backed search or a search service |
Editor independence | Block and page-builder layouts don't carry over | A fixed set of blocks mapped to components |
None of these is a reason to avoid headless on its own. Together, they're why a headless build costs more than a theme and why it needs ongoing developer time. Agencies in our research quoted £13k to £30k and 6 to 12 weeks for WordPress to headless Next.js, and ranges vary widely.
How do previews and editing work in headless WordPress?
Previews in headless WordPress work by having the preview button open a Next.js draft route that fetches unpublished content with authentication. It's solvable, but it has to be built, tested and kept working through updates on both sides.
Block content is the other editing challenge. Gutenberg blocks arrive from the API as HTML or structured data, and the front end has to render each block type with a matching component. Most teams pick a fixed set of blocks, such as headings, images, quotes, call-to-action and testimonial sections, and remove the rest from the editor so nobody uses a block that won't render.
Rendering Gutenberg blocks: HTML vs structured blocks
There are two common approaches. The simplest is to take the rendered HTML from the API and output it inside the Next.js template, styling it with CSS. It's quick, but custom blocks and plugin output often come through broken or unstyled.
The more controlled approach is to fetch blocks as structured data, through a WPGraphQL extension that exposes block attributes, and map each block type to a React component. It takes longer but gives consistent design and lets you use proper image handling and links.
Whichever you choose, decide the allowed block list with editors early and lock the rest away.
When is headless WordPress the right choice?
Headless WordPress is the right choice when editors are deeply invested in WordPress, the content library is large, the site also needs custom front-end features, and a developer team will own it long term. If any of those is missing, a simpler route usually wins.
Your situation | Better fit |
|---|---|
Editors depend on WordPress workflows and content is large | Headless WordPress with Next.js |
Editors don't care which CMS they use | Next.js with Sanity or Payload; see WordPress to Sanity or Payload |
Marketing site edited by marketers, no product logic | Framer or Webflow; see WordPress to Webflow |
WordPress works and speed is acceptable | Optimize the current site; see WordPress vs Next.js |
The site sells products | Shopify; compare Hydrogen vs Next.js |
What does headless WordPress cost to run?
Headless WordPress costs WordPress hosting and plugin licences, Next.js hosting, and ongoing developer time for both. The developer time is the largest and most often underestimated line.
Each side needs updates: WordPress core, plugins and PHP on one; Next.js, React and dependencies on the other. API changes in a plugin can break the front end without warning. Plan a monthly maintenance budget from day one. Our guide to the full WordPress to Next.js migration covers the alternatives, and for budgeting other routes, see WordPress to Webflow migration cost or Framer to Next.js migration cost.
If you're running a headless store too, our guides to headless Shopify cost and DTC website cost cover the commerce side.
