What Is a Headless CMS? WordPress vs Headless vs Custom Builds

A headless CMS is a content management system that separates the panel where content is managed from the interface visitors see. Content is sent through an API, usually as JSON, to a website, mobile app or another channel, and a separate front-end application produces the presentation. In traditional systems such as WordPress, the panel and the presentation live inside the same structure. Which is right depends on who will update the content, how many channels you publish to and the technical team you have.

How does a headless CMS work?

The term "headless" comes from removing the system's "head", meaning the interface visitors see. What remains is the content model, the editing panel and the API that delivers the content. The flow roughly looks like this:

1. An editor edits a post, product or page in the panel and saves it.
2. The CMS stores the content in a database and serves it through an API.
3. A front end, such as Next.js, Nuxt or a mobile app, pulls the content from that API.
4. The front end builds the page and shows it to the visitor.

Payload, Strapi, Contentful and Sanity are well-known examples of this approach. WordPress can also be used headless thanks to its REST API: according to WordPress's own documentation, the REST API lets applications interact with a site by sending and receiving JSON objects, and makes it possible to move content to an entirely separate front end.

Why is WordPress still so widespread?

According to W3Techs data from 30 September 2026, WordPress is used on 40.2% of all websites, and its share among sites with a detectable content management system is 58.7%. That reach has concrete benefits: developers are easy to find, editors get used to the interface quickly, and there are ready-made plugins for most needs such as forms, SEO and multilingual content.

The price is maintenance. WordPress's official security documentation recommends always keeping core up to date, notes that old versions do not receive security updates, and advises keeping plugins updated, deleting unused ones and only getting plugins and themes from trusted sources. As the number of plugins grows, so do the update load, the risk of incompatibility and page weight. A picture we see often is a site that has gathered thirty or forty plugins over the years, which nobody dares to update anymore.

What are the advantages and costs of a headless CMS?

The strengths of a headless setup are:

• Performance: The front end can be written with a modern framework, with pages pre-generated or rendered on the server; it does not carry unnecessary plugin code.
• Multiple channels: The same product description is used from a single source on the website, the mobile app and an in-store screen.
• Design freedom: The front end is not bound by the limits of a theme.
• A narrower attack surface: The admin panel and the public site can run separately.

The costs are real too:

• Everything is developer work. A form, search or redirect management that is a plugin away in WordPress has to be built separately in a headless setup.
• Preview has to be set up. Answering the editor's question "how will this look before I publish?" requires configuring live preview.
• You manage two parts. The CMS and the front end are hosted, updated and monitored separately.

What did we learn running headless on our own site?

pikup.tr runs on a front end written in Next.js together with Payload CMS. Payload describes itself as an open-source framework that installs inside a Next.js application and provides the admin panel, database, and REST and GraphQL APIs in a single codebase. This setup gives us speed, design freedom and the ability to build the content model around our work.

To be clear about the trade-off: adding a new content field to the panel means a database change and an accompanying migration. A job that takes minutes with a WordPress plugin becomes a development task that is planned, tested and released in a headless setup. That is why we recommend headless for projects with a technical team able to carry that discipline.

What should you look for when choosing a headless CMS?

If you have decided on a headless setup, the differences between products show up in the details. Ask these questions when choosing:

• Hosting: Will you run the system on your own server or use the vendor's cloud service? Where data is stored also matters under data protection rules if you process personal data (in Turkey, for example, KVKK).
• License and cost model: Is it open source, or a service priced by number of users or content items? Work out how the cost will change as you grow.
• Editor experience: Can the panel be used in your editors' language, is there live preview, and does image and file management make the editor's job easier?
• Multilingual support: Are field-level translation and language-based URL structures supported?
• Permissions and workflow: Can draft, approval and publishing steps be set up with role-based permissions?

The answers to these questions matter more than flashy feature lists. Having your editors enter one real piece of content from start to finish in a trial version is the best test.

When does custom software make sense?

When content management is a small part of the job. On a platform with a dealer portal, a booking system, a quote and order flow or its own unusual data structures, trying to add that logic to a standard CMS usually strains the system. In that case either a fully custom application, or a headless CMS with custom modules written alongside it, is healthier.

This option has the highest cost and the longest timeline; maintenance, security and documentation are entirely your responsibility or your software partner's. It is not a path to choose because "we might need it one day".

Which option fits which situation?

• A 10 to 20 page corporate site, a few blog posts a month, a small team: WordPress or a concept site designed for you is usually enough.
• Content will also be used outside the web, speed is critical, there are multiple languages: A headless CMS belongs on the table.
• Workflows do not fit standard tools: Custom software, or headless with custom modules.
• There is no technical team and there will not be one: Choose a simple structure that is easy to maintain instead of headless.

Before you decide, answer three questions in writing: who will update the content, and how often? In which channels will the content appear? What will the site need to do a year from now that it does not do today?

What should you watch for when migrating an existing site?

Changing CMS is one of the riskiest jobs for search engine visibility. Keep the old URLs, or link each one to its new address with a permanent (301) redirect, and make sure fields such as title, description and structured data have an equivalent in the new system. On a headless front end, rendering content on the server or pre-generating it, rather than loading it only in the browser with JavaScript, is safer for search engines to read the page fully.

If you would like to talk about which setup suits your project, see our web design and development service, or for a fast, brand-specific start, our Concept Website package.