{{text}}
Share
A headless CMS is a content management system that stores and structures information without deciding how it is displayed. It exposes content through an API, and a separate frontend handles rendering. The word headless refers to exactly that: the missing presentation layer.
It is a powerful architecture and a frequently mistaken one. This article gives the real costs, the search traps, and a grid for deciding whether your project actually calls for it.
Headless and coupled: the real difference
A traditional CMS, also called coupled or monolithic, manages content and its presentation in one tool. You edit an article and you see the page. A headless CMS cuts that chain in two: a structured content store on one side, an application that queries it on the other.
| Coupled CMS | Headless CMS | |
|---|---|---|
| Rendering | Handled by the CMS, templates included | Built and hosted separately |
| Publishing a page | An editor action | Editor action, then a frontend deploy in many setups |
| Changing a page structure | An editor action | A code change |
| Multiple surfaces | One site, rarely more | Site, app, product, anything that reads the API |
| Technical SEO | Provided by default | Written and maintained by you |
| Ongoing dependency on engineering | Low after launch | Permanent |
The third row is the one that matters most. It decides whether your marketing team works on its own or files a ticket for every change.
What headless genuinely gives you
Reusable content. The real argument. If the same product record has to feed a website, a mobile app and an internal catalogue, storing it once and exposing it through an API is the correct answer. No other architecture does this cleanly.
Frontend freedom. Your developers pick the framework, the hosting and the rendering strategy. If your interface has requirements no visual tool covers, that is decisive.
Clean separation of responsibilities. The content team cannot break the display, and the engineering team is not bound to the editorial calendar.
All three benefits are real. All three assume a permanent development team. Without one, none of them materialises.
What it costs, licence and everything else
Prices taken from vendors' official pricing pages in September 2026. They cover the CMS licence only.
| Vendor | Free tier | First paid tier | Higher tier |
|---|---|---|---|
| Contentful | 0 dollars, 10 users, 25 content types, 2 locales, 100,000 API calls per month | Lite at 300 dollars per month, 20 users, 3 locales, 1 million API calls | Enterprise on quote |
| Sanity | 0 dollars, 20 seats, 2 public datasets, 10,000 documents | Growth at 15 dollars per seat per month, up to 50 seats, 25,000 documents | Enterprise on quote |
| Storyblok | 0 dollars, 1 space, 1 user, 100 GB traffic, 100,000 API calls, 2 locales | Growth at 99 dollars per month, or 90.75 dollars billed annually | Growth Plus at 349 dollars per month, then Premium and Elite on quote |
| Strapi Cloud | No hosted free tier | Starter at 35 dollars per month per project, 100,000 API requests | Pro at 90 dollars, Business at 450 dollars per month per project |
Those figures are not the project budget. Four line items that comparisons systematically leave out sit on top:
- frontend development, which is a full application project and not a theme to install;
- its hosting, with its own invoice and its own monitoring, a subject we cover in our web hosting guide;
- maintenance, meaning framework and dependency upgrades;
- engineering time per change, the most underestimated item of all.
Compare that with a coupled CMS where hosting, security and rendering are included in the subscription. Our article on Webflow pricing gives the reference figures on the coupled side.
Is Webflow headless? No, and that is the point
Webflow is a coupled CMS: content and the template that displays it live in the same place. The confusion comes from its Data API, which lets you read and write collection items from outside. That API makes Webflow a programmable content source, not a headless CMS, because rendering stays with Webflow.
The API has its own limits, worth knowing before you build on it: 100 items per bulk request, one publish per minute, and 301 redirects reserved for Enterprise plans. We documented them while building the editorial automation described in our article on the Webflow MCP server.
On capability, CMSWire reported on 14 April 2026 that Webflow had completed the migration of all customer sites to a rebuilt CMS architecture on 9 April, with 40 collections per page, 10 nested lists per page, 100 items per nested list and 3 levels of nesting. A share of the cases that historically justified going headless no longer do.
Search in a headless setup: five traps
Headless is not bad for search. It simply makes you responsible for everything a coupled CMS used to provide without anyone thinking about it.
1. Rendering. If pages are rendered client-side only, content depends on JavaScript executing. Server-side rendering or static generation are not options here, they are prerequisites.
2. Meta tags. Title, meta description, canonical, Open Graph: each becomes a field to create in the CMS and wire into the code. One forgotten field and an entire template ships without a title.
3. Structured data. None is generated by default. You produce it at render time and validate it. Same subject as our article on structured data, except that nobody hands you a starting point.
4. Sitemap and redirects. Two features to build. Redirects in particular become a table to maintain, when they are a configuration line elsewhere.
5. Canonicals. The most expensive trap, because it is silent. A canonical injected in JavaScript and absent from the raw HTML can deindex whole sections of a site with no alert firing.
Our decision grid
Three questions usually settle it.
Does the content feed more than one surface? If yes, headless defends itself immediately. If the content only serves a website, the main argument falls away.
Do you have a permanent development team? Not an occasional contractor, a team. Without one, you are buying a dependency rather than a freedom.
Who publishes, and how often? If it is marketing, several times a week, on page structures that keep moving, coupled wins almost every time. If it is a normalised feed of product records, headless is comfortable.
In practice, most of the B2B marketing and brand sites we meet belong on a coupled CMS, and a share of them run headless for reasons inherited from an old technical decision. That is exactly the situation we handled on the CADvision project: the issue was never the power of the tool, it was how long a page took to go from idea to live.
A third path that gets ignored
Between fully headless and fully coupled sits a hybrid setup we use regularly: a coupled CMS for the brand site, fed by API from the business system for content that originates elsewhere. Marketing keeps its autonomy over pages, and the data that must stay in sync stays in sync.
This approach requires deciding clearly who owns each field, and never letting two systems own the same data. That is the only discipline to hold, and it prevents half the redesign projects we see coming.
Frequently asked questions about headless CMS
What is a headless CMS, in one sentence?
A CMS that stores and structures content but renders nothing: it exposes content through an API, and a separate frontend written by your developers decides how it looks.
Is Webflow a headless CMS?
No, and the confusion is common. Webflow is a coupled CMS: content and presentation live in the same tool. It does expose a Data API that lets you read and write content from outside, so you can use it as a content source, but rendering stays with Webflow. See our article on Webflow.
What does a headless project actually cost?
The CMS licence is never the main line. On top of it sit frontend development, its hosting, its maintenance, and engineering time for every change to presentation. On a B2B marketing site, that last item usually exceeds the licence within the first year.
Is headless better for SEO?
Neither better nor worse by nature, but far easier to get wrong. Rendering, meta tags, structured data, sitemaps, redirects and canonical URLs all become code you write and maintain. A coupled CMS handles them by default.
When is headless genuinely the right call?
When the same content has to feed several surfaces: a website, a mobile app, kiosks, a product. When you have a permanent development team. And when the frontend has requirements no visual tool covers.
Can you migrate from headless to Webflow?
Yes, and we see it regularly on marketing sites where the content team depends on the developers' backlog to publish. The thing to plan for is the existing URL structure and the redirect map, as on any website redesign.
What are Webflow's CMS limits in 2026?
According to CMSWire, Webflow completed the migration of all customer sites to a rebuilt CMS architecture on 9 April 2026. The limits announced alongside it are 40 collections per page, 10 nested lists per page, 100 items per nested list and 3 levels of nesting.
Do you need a developer to maintain a headless site?
Yes, permanently. That is the structural difference with a coupled CMS: in headless, swapping two blocks on a page is a code change, not an editor action.
Synqro is a Webflow Premium Partner agency in Paris. Weighing headless against coupled on a redesign? We audit what exists and decide on measurable criteria, not on a technical preference. Talking to a Webflow expert early makes that call faster. See how we work or tell us about your setup.
Synqro's latest achievement
