Choose WordPress when marketing staff edit the site daily and the design is conventional. Choose Next.js when the site is part of a product, needs custom behaviour, or your team already writes React. Headless WordPress (WordPress as the editor, Next.js as the front end) is a middle path, but it is two systems to run, so it only pays off for specific reasons.
This piece compares those three setups. For the broader owner-level question of theme-based versus coded sites, see WordPress vs a custom-coded website. For the how-to of moving an existing site without losing rankings, see WordPress to Next.js migration and SEO.
The three setups
Classic WordPress. One PHP application renders pages and provides the admin. Themes and plugins control layout and features.
Next.js with its own content. A React framework renders pages. Content comes from MDX files, a database or a headless CMS. There is no WordPress.
Headless WordPress. WordPress stores and edits content. Next.js fetches it through the REST API (or GraphQL via a plugin) and renders the public site.
Editor experience
WordPress wins here, and it is the strongest argument for keeping it. The block editor, media library, draft and preview, roles and a huge plugin ecosystem are available on day one.
With Next.js and no CMS, editing means changing code. With a headless CMS, editing is good, but you build and maintain the preview flow yourself.
Headless WordPress keeps the familiar admin but changes one thing that matters: preview and page-builder layouts. Anything built with a front-end page builder or a plugin that outputs its own markup does not automatically appear in the Next.js site. You rebuild each layout as a component. Editors lose some freedom to invent new layouts, which can be a feature (consistent design) or a complaint.
Hosting model
| Setup | What you run |
|---|---|
| Classic WordPress | PHP and a database on shared, managed or VPS hosting |
| Next.js | A Node-capable host or serverless platform, or a static export. Plus a database or CMS if used |
| Headless WordPress | Both of the above, and the WordPress origin must stay available and patched |
A common mistake with headless WordPress is treating the WordPress half as safe because it is hidden. It still needs updates, backups and a secured admin. You have also added an API dependency: if WordPress is slow or down, your build or your server-rendered pages are affected unless you cache.
Performance work required
WordPress performance is mostly about restraint and caching: a light theme, fewer plugins, image optimisation, page caching, and a decent host. A well-tuned WordPress site can be fast. The work is ongoing because each new plugin can undo it.
Next.js provides rendering and image-optimisation tools, but defaults do not guarantee scores. You still decide what runs on the client, how fonts and third-party scripts load, and whether pages are static, incremental or per-request. See rendering strategies and SEO and Core Web Vitals in Next.js. Shipping too much client-side JavaScript produces a slow Next.js site just as plugins produce a slow WordPress site.
Judge by measured field data on Core Web Vitals, not by framework reputation.
Team skills
- WordPress: PHP, theme development and plugin configuration. Check available maintainers in your budget.
- Next.js: TypeScript, React and deployment. Plan for a developer or agency to maintain dependencies and deployments.
- Headless WordPress: both skill sets, plus the integration between them. This is the highest bar.
If your team is one marketer and an occasional freelancer, the skills column often decides before performance does.
Migration tradeoffs
Moving from WordPress to Next.js (or to headless) is not only a technical project. You are re-implementing layouts as components, deciding what to do with plugin-driven features (forms, search, redirects, SEO metadata), and preserving URLs and content while monitoring search visibility. The trade you are making is: lose off-the-shelf features, gain control and a smaller runtime surface.
Headless can preserve the content store and familiar editing screens, but previews, plugin-dependent layouts and publishing workflows may still need substantial rebuilding. The cost is that you keep paying for the WordPress half forever. The full-migration path costs more up front but leaves one system. The how-to, redirects and SEO checks are covered in the migration guide, so we will not repeat them.
When each wins
| If this describes you | Pick |
|---|---|
| Marketing team publishes weekly, conventional design, small budget | WordPress |
| Existing WordPress content team you cannot retrain, but you need a custom front end | Headless WordPress |
| Site shares auth, data or components with a product | Next.js |
| Developers maintain the site and content changes are infrequent | Next.js with MDX or a headless CMS (see how to choose a CMS) |
| You accept developer-managed releases and do not need WordPress plugins | Next.js, with an explicit dependency and content-maintenance plan |
Our default for a content-led marketing site with a non-technical editor is plain WordPress, not headless. Headless earns its cost when you need the front end to be a product-grade application, or when you must serve the same content to several channels.
Apex builds sites in Next.js, including the public listings site for Offease. If you are weighing a migration, our web team can review the tradeoffs for your site.