Separate the content system from its delivery
Keep a coupled publishing system when the editorial team mainly serves a website and its current workflow works. Separate content delivery when independent applications genuinely need the same structured material. Do not replace a CMS simply because headless sounds like an upgrade.
WordPress and headless are not opposites. The WordPress REST API exposes content to separate applications, so WordPress can remain the editorial backend while another application renders the public experience. The decision is architectural before it is a vendor shortlist.
Clodron publishes this comparison from a product engineering perspective. The goal is a publishing process that remains usable, not the largest possible collection of services.
Start with what editors actually change
A coupled setup is attractive when editors mostly work with pages, articles and reusable blocks whose appearance is closely tied to the website. Preview and publishing can be evaluated in the same system. Existing editorial confidence is an asset, not technical debt by default.
A headless setup becomes more compelling when content has a life beyond a page: shared product explanations, help material used inside an application, or structured records consumed by different interfaces. The useful distinction is reusable meaning, not merely exporting formatted text through an API.
Ask editors to describe relationships and approvals. If every content model discussion returns to moving a heading slightly to the left, the need may be visual page composition rather than independent content delivery. Either need is legitimate; confusing them creates an awkward tool.
Price the missing publishing workflow
Separating the frontend does not automatically preserve the old editorial experience. Someone must implement preview authentication, draft access, redirects, image handling, cache updates and error recovery. A content record being saved is not the same event as a correct page becoming public.
The WordPress API distinguishes public content from material requiring authentication. That boundary must survive the custom frontend, rather than being bypassed by a convenient preview endpoint. This is an implementation responsibility, not evidence that headless is inherently more or less secure.
Likewise, a plugin that changes rendered pages cannot be assumed to affect an unrelated frontend. Inventory integrations by what they actually do. A metadata field may transfer cleanly while its rendering, validation and preview need new work.
Compare the cost of change, not fashion
Coupling can be helpful when content and presentation should change together. Separation can help when different teams need independent release cycles. Neither is free: the former constrains interfaces, while the latter introduces contracts and coordination between systems.
The same adoption issue appears in our guide to design systems nobody uses. A theoretically elegant shared layer loses value when real users must work around it. A content model should make routine publication easier, not require architectural approval for every article.
For a custom web platform, we would evaluate frontend ownership and editorial ownership together. Choosing a CMS before naming both owners leaves half the operating model undecided.
Rehearse publication before migrating
This week, take existing content with awkward formatting, an unpublished draft and a changed URL. Reproduce editing, preview, approval, publication and rollback in each proposed approach. Include a failed delivery notification and confirm how the public page is repaired.
Choose the coupled route if it supports the actual audiences and editors without costly workarounds. Choose headless if independent delivery solves a documented requirement and the extra workflow has an owner. Keep WordPress as the headless backend if its editorial experience and content model still fit. A new frontend does not require a new content institution.