engineering//2 min read
Headless or classic WordPress? How to choose
Headless WordPress promises speed and freedom, and sometimes delivers. It also doubles the systems you run and breaks things editors take for granted. A clear way to decide which one your site needs.
In short
- Classic WordPress is the right default for content sites run by marketing teams.
- Go headless when the front end is a product in its own right, or when content feeds several channels.
- Headless means two systems to host, secure and update, and previews you must build yourself.
- Plugins that output front-end HTML (forms, sliders, page builders) do not carry over to a headless front end.
WordPress runs a large share of the web because it is good at one thing: letting non-developers publish. In a classic setup, WordPress stores the content and also renders the pages with a PHP theme. In a headless setup, WordPress only stores content and exposes it through an API, and a separate application, often built with Next.js, renders the site.
What classic does well
- Editors see what they get: previews, the block editor and page layouts work out of the box.
- The plugin ecosystem works as intended: forms, SEO, redirects, multilingual sites.
- One system to host, back up, update and secure.
- Any WordPress developer can pick it up.
With good hosting, page caching and a well-built theme, a classic WordPress site can be fast. Many slow WordPress sites are slow because of heavy themes and page builders, not because of WordPress itself.
What headless does well
- Front-end freedom. A modern framework, component libraries and app-like interactions without fighting a theme.
- One content source, many channels. The same articles can feed a website, a mobile app and an in-product help centre.
- A smaller attack surface on the public site. Visitors hit a static or server-rendered front end, not WordPress directly.
- Performance by default when pages are pre-rendered and served from a CDN.
What headless costs
Concern | Classic | Headless |
|---|---|---|
Systems to run | One | Two: the CMS and the front end |
Editor preview | Built in | Must be built and maintained |
Front-end plugins (forms, sliders, builders) | Work | Rebuilt in the front end |
SEO plugin output | Rendered automatically | Fetched from the API and rendered by you |
Content changes going live | Immediate | Needs revalidation or a rebuild hook |
Skills needed | WordPress | WordPress plus a JavaScript framework |
A decision rule
Choose classic when
- The site is mainly pages and posts run by a marketing team.
- Editors rely on plugins and page layouts they can change themselves.
- There is no in-house front-end team to maintain a second application.
Choose headless when
- The website is part of a product, sharing components and sign-in with an app.
- Content must feed more than one channel.
- You have, or will hire, developers to own the front end long term.
If you do go headless
Use the REST API or WPGraphQL, keep content models simple, and build preview and on-demand revalidation before launch, not after editors complain. Content changes should reach the live site within seconds.
// app/api/revalidate/route.ts: WordPress calls this when a post is saved.
import { revalidatePath } from "next/cache";
export async function POST(req: Request) {
if (req.headers.get("x-webhook-secret") !== process.env.WP_WEBHOOK_SECRET) {
return new Response("Unauthorized", { status: 401 });
}
const { slug } = await req.json();
revalidatePath("/blog");
revalidatePath(`/blog/${slug}`);
return Response.json({ revalidated: true });
}Headless is an architecture for teams that will own a front end. It is not a speed plugin.
