Engineering guides
Headless WordPress or a traditional WordPress website?
Choose the setup your visitors and publishing team can use and your team can maintain. WordPress and Next.js can work together; the decision is about the complete website and its owners.
By Hasnain Qureshi ·
Compare complete setups
Traditional WordPress combines content management and the public presentation within its theme/plugin setup. A headless WordPress site keeps WordPress for content and adds a separate frontend, such as Next.js. A third option is a different CMS with a custom frontend.
That distinction matters when someone asks “WordPress or Next.js?” The combination can preserve a familiar publishing workspace while giving the frontend a different structure. It also creates another application to deploy and maintain.
A practical decision matrix
| Question | Traditional WordPress | WordPress + Next.js |
|---|---|---|
| Who edits? | Editors use the configured WordPress workflow. | Editors use WordPress; fields must map to frontend components. |
| How does preview work? | Review theme and plugin behavior. | Agree draft access and a frontend preview route. |
| What happens to plugins? | Check compatibility with the installed theme. | Check each plugin's API/data and frontend requirements. |
| Who maintains it? | WordPress/theme/plugin owner. | CMS owner plus frontend/deployment ownership. |
| What about search? | Content, URLs and implementation still matter. | Content, URLs and implementation still matter. |
When a simpler site may fit
If your needs are standard pages, a familiar editing workflow and a form that an existing theme/plugin combination handles well, start by checking whether that setup already solves the task. Budget and the team's maintenance capability should be part of the decision.
A slow or confusing page does not by itself establish that the platform must be replaced. Review its content, assets, templates, third-party scripts and visitor journey before proposing a rebuild.
When a separate frontend is worth scoping
A headless approach may fit a custom interface, structured content reused across surfaces or a design that needs a deliberately built component system. Establish the frontend requirement and editorial workflow before committing to it.
My Cambridge Research Park and 1540 Broadway case studies show attributed frontend and WordPress-content integration work. They are useful implementation evidence rather than universal evidence that every business needs the same architecture.
Use a concrete example
Imagine a fictional campus site with building pages, a maintained availability list and brochure downloads. First decide who updates each field. Then decide whether the existing presentation can show that content clearly. Finally, compare the build and maintenance responsibilities of each option.
Download the synthetic content model and the decision worksheet. Use the cost planning calculator to expose scope assumptions, not to substitute an illustrative range for a project quote.
Prepare the implementation brief
Bring the current site, required page types, publishing frequency, plugins/integrations, existing design and expected support ownership. Separate requirements from preferences and record what needs testing.
Explore freelance Next.js development and the migration checklist. A useful initial decision is one your editor, developer and business owner can all explain.