Short answer: Choose WordPress when non-technical editors publish many times a day and the site is mostly content. Choose a headless stack — a Next.js front end reading from Sanity, Strapi or Contentful — when the site behaves like an application, needs interfaces no theme can produce, or has to feed more than one destination.
What is the real difference between WordPress and headless?
WordPress is coupled: the editor, the database and the rendered HTML all live inside one PHP application. Headless splits them apart. Content sits in an API-first CMS, and a separate front end requests it and decides how to render it. Editors can have an equally comfortable writing experience on either side — the difference is in deployment, performance ceiling and how much of the front end you control.
When is WordPress still the right call?
When publishing volume is high and the layout is conventional. A newsroom filing twenty stories a day needs category assignment, scheduled posts and a breaking-news ticker that a journalist can edit at 11pm without a deploy pipeline. That is exactly why Jalalabad Today runs on WordPress: the constraint was editorial throughput, not interface novelty.
- Editors outnumber developers. Plugin-level changes beat pull requests when the people making changes do not write code.
- The content model is standard. Posts, categories, authors, media — WordPress models these out of the box.
- Budget favours configuration over engineering. A mature theme plus careful tuning ships in weeks, not months.
When is headless worth the extra moving parts?
When the interface is the product. A storefront with a non-standard checkout, a donation platform with three different giving flows, or a dashboard with live data all need front-end logic that a theme cannot express without fighting it. HandcraftUK needed an enquiry-based checkout instead of card payment; Catalyst BD needed one-off donation, monthly sponsorship and Zakat flows side by side. Both are Next.js.
Headless also pays off when content must reach several surfaces — a website, a mobile app and a partner feed reading the same API — because the content is no longer trapped in the rendering layer.
How do the two compare on the things that bite later?
| Concern | WordPress | Headless (Next.js + CMS) |
|---|---|---|
| Time to first launch | Faster for conventional sites | Slower — the front end is built, not configured |
| Performance ceiling | Good with caching and discipline | Higher — static generation and edge delivery by default |
| Security surface | Plugins and PHP runtime need patching | Smaller — no public admin surface on the rendered site |
| Editor autonomy | Excellent out of the box | Good, but content models must be designed first |
| Ongoing cost | Hosting plus plugin licences and updates | Hosting plus CMS seats, less patching |
What does maintenance actually look like?
WordPress maintenance is continuous and unglamorous: core updates, plugin updates, PHP version bumps and the occasional conflict between two plugins that both want the same hook. Headless maintenance is lumpier — dependency upgrades a few times a year, and a framework major version every so often that needs a developer for a day or two. Neither is free. Anyone who tells you their stack is maintenance-free is quoting month one.
The decision in four questions
- Who changes the site weekly? If the answer is an editor, weight WordPress.
- Does any screen need custom logic? Carts, calculators, dashboards, multi-step flows push toward headless.
- Does content feed anything besides this website? If yes, headless.
- What happens in year three? Pick the option whose failure mode you can live with — plugin rot, or a framework upgrade.
We build and maintain both. If you want a straight recommendation for your situation rather than a pitch, tell us what your team looks like.