Short version
Short answer: headless pays off when several people or systems work with your content, when the same content feeds multiple channels, or when AI agents prepare content for you. For a simple site with one owner who occasionally updates a paragraph, a classic or fully static site is usually smarter and cheaper. This guide helps you make the call honestly — including the questions to ask an agency before you commission anything.
“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 somewhere and read somewhere that headless is better. The question is no longer “what is it” but “is it for me”.
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.
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 something we measure monthly in our cases; light architectures consistently outscore plugin-heavy classic sites there — 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.
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? What a headless CMS is explains the concepts, and 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:
| Factor | Keeps the price low | Drives the price up |
|---|---|---|
| Page types | A handful of templates reused across pages | Every page with its own design and block structure |
| Content model | Clear types your team manages itself | Many nested blocks, roles and workflows per department |
| Migration | Little content or a clean export path | Hundreds of pages, inconsistent structures, broken media |
| Integrations | Standard connectors or none | Booking tools, ERP connections or custom API work |
| Languages | One language | Multilingual with per-language editing and hreflang |
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. That works fine — but you also keep the WordPress maintenance burden: updates, plugins, hosting, security. You trade one system for two.
So ask what you are actually 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; redirects keep you from losing rankings.
- 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 you may expect from an agency
Finally the counter-question: when you commission a headless website, what may 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, and before the switch the current speed and visibility are measured so you can compare honestly afterwards.
- 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 frontend and source. Ask explicitly what the arrangement covers: frontend updates, the CMS, the integration and the hosting.
If an agency does not recognize these questions, or recommends a platform before asking about your team — that tells you enough.
Want a headless site built with those questions already answered? See our headless website approach, or first read how we built this site without a CMS if your team is technical. For the full journey starting from design, website development is the starting point.