WordPress without template limits

Headless WordPress: content in WordPress, a frontend free of its limits?

Headless WordPress separates content management from the public website. Editors keep working comfortably in WordPress while visitors get a fast, modern frontend.

Discuss the project Back to the home page

Headless WordPress means WordPress stays the place where content is written and managed, but its theme no longer renders the public pages. Content is exposed through a REST API or a GraphQL layer, and the frontend consumes it as a separate application, most often built in React. Editors keep the environment they already know, with the editor, the revisions and the roles they are used to, while visitors get pages that are not constrained by a theme system. The approach makes sense when a larger team handles content, when the same content is reused in several places, or when speed and interactivity requirements outgrow what a theme can deliver. For a small five-page website, a headless architecture would only add overhead. That is why the first consultation always starts with the question of real benefit, not with how fashionable the term sounds.

I have been building WordPress projects for 19 years, including plugins, WooCommerce and integrations, so I know both its classic and its decoupled shape. I build frontends in React and backend layers in PHP, and in Laravel when the project calls for it. I am a freelance developer based in Poprad, I work remote-first, and throughout the project you talk directly to the person who designs the architecture and writes the code. Before any estimate we go through your editorial processes, integrations and the team that will run the system, so the result can be operated without my assistance. The code, the credentials and the documentation belong to the project, not to the supplier.

When headless pays off and when it does not

Headless pays off when a team of editors produces content, when the same data is needed on the website, in an application and in a newsletter, or when a theme-based frontend slows down both the site and the people working on it. Magazines with daily production, catalogues with large volumes of data and multilingual company websites all fit that picture. A smaller site with five pages and a single administrator, on the other hand, is faster and cheaper to solve with a classic theme. Headless is equally unnecessary when the only reason is a feeling that a modern website has to use React. I judge every architecture by its total cost over several years, not only by the price of the first launch. If the analysis shows the benefit is small, I say so openly and propose the simpler route.

Editorial team in a familiar admin
Content for the site and for apps
A small site is fine with a theme

The API layer and the content model

I expose WordPress content through the REST API, or GraphQL where it fits, in the shape the frontend actually uses, without extra assembly on the client side. Content types, taxonomies and custom fields are designed so editors get clear forms and developers get clean, stable data. Public endpoints are cached and versioned, and the sensitive parts sit behind authentication. Redirects and canonical URLs are part of the same layer, so moving to a decoupled frontend does not cost you search visibility. This is also the point where the project can later be connected to a mobile application or to partner systems without disturbing day-to-day editorial work.

REST API or GraphQL
Content types shaped around the editors
Cached and versioned endpoints

A frontend that keeps its speed

The frontend is built in React with server rendering or pre-generated pages, so a visitor receives finished content instead of waiting for JavaScript. Critical styles go into the head, images are served in modern formats at the right dimensions, and interactivity is attached only where it is genuinely needed. The result is stable Core Web Vitals even on content-heavy pages. The frontend only knows the API contract, so a later redesign does not touch the admin or the content itself, and editors can keep publishing while the design changes around them.

React with server rendering
Stable Core Web Vitals
Redesign without touching content

Editorial workflow and preview

The demanding part of a headless project is the editorial process, not the rendering. I set up previews of unpublished drafts, revisions, scheduled publishing and the link between saving content and deploying the frontend. An editor has to see how an article will look without understanding anything about deployments. Every project therefore gets a preview link for work in progress and a documented publishing routine. For teams I include a short manual and a training session in the handover, so a new colleague can take the process over later without calling a developer.

Preview before publishing
Scheduled publishing
Editor training at handover

Delivery, price and taking it over

I work at 40 EUR per hour including VAT and split the project into stages: content model design, API layer, frontend, preview workflow and launch. Each stage can be reviewed on its own, so the decision about the next step rests on a concrete result rather than on promises. Hosting, monitoring and backups are configured to match how demanding the traffic is, and the documentation is handed over in writing. I can also take over a headless project that is already underway: an audit of the API and the frontend first, then stabilisation, and only after that new development.

40 EUR per hour including VAT
Stages with a reviewable result
Ready to be taken over at any point

Frequently asked questions about headless WordPress

How much does headless WordPress cost?

The price depends on the size of the content model, the number of content types and the complexity of the frontend. I work at 40 EUR per hour including VAT, and after the analysis I split the project into stages with a separate estimate for each one.

Why is a classic theme not enough?

For smaller websites it is perfectly enough. Headless makes sense with a larger editorial team, with content reused in several channels, or with speed and interactivity demands that a theme keeps obstructing. If your case is the simpler one, I will tell you.

Who manages the content after handover?

Your editors, in WordPress, exactly as before. Previews, publishing and the content structure are set up so that everyday editorial work never needs a developer.

What happens to the existing plugins?

Content and editorial plugins usually carry over. Plugins that change the output of the public pages are replaced by the frontend. We go through them one by one and decide what stays, what is replaced and what gets switched off.

Can we go back from headless to classic WordPress?

Yes. The content stays in WordPress, so returning to a theme-based frontend is possible without losing data. A well-designed content model makes that return even easier.

Considering headless WordPress?

Send me the brief or the address of your current website. I will tell you whether headless brings a real benefit and propose a first stage with an estimate.

Discuss the project