Headless CMS or traditional CMS: what the difference means and when each fits

A traditional CMS stores your content and also renders the public pages, all in one application. A headless CMS only stores and manages content and delivers it through an API, and a separate front end, a website, a mobile app or both, decides how it looks. Choose a traditional CMS when you run one website and want editors to publish with the fewest moving parts. Choose headless when the same content feeds several channels, or when your front end team needs full control over a custom web application.

#What headless means in practice

In a traditional CMS such as WordPress, Drupal or a Laravel CMS, one codebase does three jobs: it holds the content in a database, gives editors an admin panel, and builds the HTML that visitors see. Themes and templates live inside the same application.

A headless CMS removes the last job. The "head" is the presentation layer. What remains is the content store, the admin panel and an API, usually REST or GraphQL. The public site is a separate application, often built with a JavaScript framework, that requests content from the API and renders it. A mobile app can call the same API.

Many traditional CMSs can also expose an API, and many headless setups include a preview mode for editors. The line between them is about where the public pages are built, and who owns that code.

#The trade-offs side by side

	Traditional CMS	Headless CMS
Applications to run	One	At least two: the content API and the front end
Public pages	Rendered by the CMS with templates	Rendered by a separate front end
Editor preview	Built in	Has to be built or configured
Several channels (web, app, kiosk)	Possible, less natural	The main reason to choose it
Front end freedom	Limited by the theme system	Any framework the team prefers
Plugins for common features	Usually many	Often built by your own team
Skills needed	One stack	Back end and front end, plus the contract between them

What headless gives you

• One content source for several channels. A product description or a news item is written once and shown on the website, in the mobile app and anywhere else that reads the API.
• A free choice of front end. The web team can use React, Vue or any other framework without working inside a CMS theme system.
• Clear separation. The API and the front end can be deployed and scaled independently, and a design change does not touch the content store.

What headless costs you

• More to build and operate. Two applications mean two deployments, two sets of dependencies and an API contract that both sides must respect.
• Preview and editor comfort. In a traditional CMS, editors see the page as it will look. In a headless setup, previewing a draft on the real front end needs extra work.
• SEO work moves to the front end. Search engines need proper HTML, titles, metadata and sitemaps. A headless front end has to produce them, usually with server-side rendering or static generation.
• Fewer ready-made features. Forms, menus, redirects and search that a traditional CMS gets from a plugin often have to be built on both sides.

#When a traditional CMS is the better fit

• You run one website or blog, and editors need to write, schedule and publish without a developer.
• The team is small and knows one stack well. One application is easier to host, back up and update.
• You want a working site quickly and can live within the structure a theme or template layer provides.
• The content is mostly pages and articles that appear only on that website.

If the site later needs to feed an app, many traditional CMSs can add an API alongside the public pages. You do not have to decide everything on the first day.

#When headless is the better fit

• The same content appears on a website and in a mobile app, or on several sites.
• The public side is really a web application: user accounts, dashboards, interactive tools, with content being one part of it.
• You have front end developers who want full control over performance, design and routing.
• Several teams work on different parts, and a documented API gives them a stable boundary.

Before you choose headless, ask who will build preview, sitemaps, redirects and metadata, and who will keep the API documented and versioned. If nobody owns these, the site will be harder to run than a traditional one. The choice of language behind the API matters too; our comparison of Laravel and Go for an API covers that decision.

#Two open-source examples: PN Press and NextPressKit

PN Scripts publishes two MIT-licensed projects on GitHub that show both approaches. Both are source code you host yourself; PN Scripts does not run either one as a hosted service.

PN Press is a traditional CMS for blogs and company news. It runs on Laravel 13 with a Filament 5 admin panel at /admin, where editors manage posts and categories on one screen: title, URL slug, excerpt, body, status, publish date and featured image. Access is limited to admin and editor roles through Spatie Permission. The same application renders the public blog index, post pages and category archives as server-rendered Blade pages styled with Tailwind CSS, and drafts never appear on the public site. It runs one site, and it deliberately leaves out comments, tags, a media library beyond the featured image, and multi-tenancy. If you are weighing an admin built on Filament against one written from scratch, see our article on Filament or a custom admin panel.

NextPressKit follows the separated approach. It is two repositories: a web front end on TanStack Start, React, TypeScript, Tailwind CSS and Shadcn UI, and an API on Go, Gin and PostgreSQL. The API handles JWT login through HttpOnly cookies or Bearer tokens, roles and permissions, posts, pages, categories, tags and media uploads. It is documented in OpenAPI, with Postman collections for testing, and modules can be switched on or off in the configuration. It is a starting point for a web application where content is one part of the product, such as a SaaS MVP or an internal tool that needs login, permissions and content management.

The two projects reflect the choice this article describes. PN Press is the simpler path when a website with a blog is the goal. NextPressKit suits a product where a documented API and a separate front end are worth the extra moving parts.

#How PN Scripts can help

PN Scripts builds content platforms in both styles and can adapt either open-source project to your needs. The written scope explains which approach fits your content and channels before any work starts. You can read the details and the full stack on the NextPressKit product page.