Building a headless website: when it pays off (and when it doesn't)

“Headless” sounds like a technique you should simply want. Search behavior shows it too. People search for headless website development and headless WordPress migration because they need a site built and read somewhere that headless is better. The question is no longer “what is it” but “is it for me”. Want to see the two kinds of systems side by side first? Read what a headless CMS is.

The honest answer: sometimes yes, sometimes genuinely no. And the difference rarely lies in the technology itself — that part is mature. The difference lies in your team, your content and how often you publish.

I build both variants myself: headless with a CMS like Storyblok for teams with editors, and fully without a CMS with content in Git for technical teams. This guide is the decision help I also bring to the table, including the cases where I talk clients out of headless. Already sure and looking for someone to build it? Our headless website approach has its own page. Already decided on Storyblok? Switching to Storyblok is the migration guide that follows this decision.

When headless pays off

Headless earns its keep when content and presentation truly need to be separate. If you recognize one of these situations, it deserves a serious conversation:

• Multiple channels. You send the same content to a website, an app or a customer portal. One source, multiple frontends: exactly what a headless CMS does.
• A team publishes together. Editors, marketers and developers work on content at the same time. A visual editor with roles and workflows keeps that manageable without routing every change through a developer.
• You want to replace the frontend later. A redesign without a content migration: with a headless architecture the source stays put and you only rebuild the presentation layer.
• AI agents prepare content. Structured, machine-readable content — through an API or as typed files — lets agents read, prepare and check content, with a human approving the diff. We work this way ourselves; the agent prepares, the team decides.
• Performance is a hard requirement. A static frontend that serves pre-rendered HTML is easy to keep fast, and we measure that monthly in our cases. Those measurements show the scores of our own sites, not a controlled comparison with plugin-heavy classic sites. That is how we build headless websites.

The last two are not headless arguments on their own — you can be fast with a classic CMS too. But combined with a separated content source they make the architecture far easier to reason about.

One example from our own work is the Verhuurwinkel online store. Two sources are separated from the frontend there. Storyblok supplies all content, and the client’s ERP supplies products and stock, each through its own API. Astro renders most of the store as static HTML. In the measurement of September 17, 2026, the site scored 99/100 for mobile PageSpeed, and the LCP for Chrome users (p75) was 0.7 seconds. Those numbers describe this implementation, not headless in general.

When headless does not pay off

Equally honest in the other direction, because this is where agencies often fall short:

• One owner, few changes. Do you update a paragraph or a photo once in a while? The visual editor of a classic CMS or a small static site is simpler and cheaper — both to build and to maintain.
• Small budget, short lifespan. A headless project means content model, frontend and integration. For a temporary site or a one-off campaign that is quicksand.
• No editorial team, no channels. Without a second channel and without a team collaborating, you buy flexibility you will never use. You do pay for the complexity.
• Everything revolves around one established ecosystem. A client with a booking tool or payment module woven deep into the old CMS loses that integration in a headless switch — or pays twice to rebuild it. Deeply woven plugins are an expensive reason to stay.

Torn between headless and classic? The headless CMS implementation page shows what a transition involves in practice.

What drives the price of a headless website

I don’t publish rates — they depend too much on your project — but I can explain honestly what makes the quotes you receive differ:

Note the third row: migration is often the biggest hidden cost. More on that in the WordPress question below.

Headless WordPress: the specific trap

The search term headless WordPress deserves its own paragraph, because expectations often run crooked here. The idea: “we keep WordPress and add a fast frontend”. The reality:

Your WordPress content is read through the REST API and the entire frontend is rebuilt in a framework like Astro or Next.js. WordPress itself describes that as a legitimate use of the API:

So technically it works fine. But you also keep the WordPress maintenance burden: updates, plugins, hosting, security. You trade one system for two. The same REST API Handbook also says you shouldn’t feel obliged to use the API if your site already works the way you want.

So ask what you are trying to solve:

• Do you want speed? A light frontend delivers that; the question is whether WordPress must remain the source. Often, exporting content to a static site or a modern CMS is more efficient than laying an API layer over WordPress.
• Do you want better management? A new frontend does not fix your management problem; look at the CMS itself.
• Do you want to keep what works? If your site performs and your theme is custom, weigh what the switch buys you against months of migration work and double maintenance.

What you as a client provide before the build

A headless project runs smoothly to the degree that you have three things clear before the first sketch:

• Content types. What pages do you have — home, service, case study, blog, glossary? Which blocks appear on them? This becomes the content model, and it is the backbone of everything that follows.
• URL plan and redirects. Which old URLs exist and where should they go? A migration is the moment to repair your URL structure. Permanent redirects help you keep the visibility you have built up. Google’s site move guide advises keeping redirects for as long as possible, generally at least one year.
• Media and rights. Where do your images and videos live, who owns them and in what quality? Moving media is more tedious than you think and stalls many migrations.

An agency that does not ask these questions before quoting has not understood your project yet.

What to expect from an agency

Then the counter-question: when you commission a headless website, what can you count on? These are the four points I add to every conversation:

• A content model your team can handle, not the agency’s. After handover you should assemble pages yourself without a developer.
• A migration plan with redirects and a baseline measurement. Old routes are forwarded cleanly. Before the switch, the agency measures the current speed and visibility so you can compare honestly afterward.
• Monthly measurements after handover. If you commission a headless site for speed, ask for monthly PageSpeed and Search Console reporting. We measure our own cases this way; that regularity is the difference between claiming and knowing.
• A maintenance arrangement covering both halves. Headless means maintaining a frontend and a content source. Ask what the arrangement covers: frontend and dependency updates, the CMS, the integration between them, and hosting. Our website maintenance page explains how we handle that rhythm.

If an agency does not recognize these questions, or recommends a platform before asking about your team, that tells you enough.

Four questions to decide for yourself

Still unsure? Answer these four questions honestly, ideally with the people who will work with the site.

1. Do two or more people work on your content at the same time? Yes points toward headless with an editor and roles. No means a classic CMS or a static site is usually enough.
2. Does the same content need to reach two or more channels? A website plus an app, customer portal, or newsletter calls for one central source. A single website rarely needs that separation.
3. How much do you need to migrate, and are you tied to plugins? Hundreds of pages or a booking module built deep into your current CMS make the switch expensive. Count that migration before you decide.
4. Can you maintain two halves? Headless means a frontend and a content source, each with its own updates. If that doesn’t fit your budget or team, a simpler setup is the better choice.

Yes to the first two questions and a manageable migration? Then headless is a serious option. Mostly no? Then a simpler setup usually gives you more for less money.

Want a headless site built with those questions already answered? See how we build a headless website, or first read how we built this site without a CMS if your team is technical. For the question before that one — whether your site needs to be extensive at all — read simple website: when less is more. And for the full journey starting from design, website development is where it begins.