A hands-on comparison of the three leading headless CMS platforms for German SMEs – with findings from our own proof of concept and a clear focus on SEO.
Author: André Freier, Managing Director of Calvarius GmbH (Karlstadt am Main). Calvarius advises and builds modern, search-optimized web architectures based on headless CMS for mid-sized companies.
Published: May 2026 · Last updated: May 2026 Methodology: Our own proof of concept across all three systems, supplemented by the providers' publicly documented pricing and feature data (as of May 2026, sources linked at the end).
At a glance: The short version
If you're short on time, here's the conclusion up front:
- Sanity treats content like structured data. The best foundation for complex, multi-channel, SEO-driven content. A development partner handles the one-time setup – afterwards the editorial team maintains everything comfortably through ready-made, reusable templates.
- Strapi treats content like code and hands you the server with it. The choice for full data sovereignty, self-hosting, and connecting relational data.
- Storyblok treats content like a design system. An industry-leading visual editor with which the editorial team assembles pages especially independently once the build is done.
We (Calvarius) chose Sanity after a proof of concept and use it for our clients as well: we set the system up cleanly, once, and hand our clients an editorial environment in which maintaining pages and content is simple and safe – entirely without developer knowledge. Why this division of labor works so well in practice, and for whom a different choice makes more sense, you'll read in detail below.
What this article is about
Choosing a headless CMS is one of those decisions you want to get right exactly once. Choose wrong, and you'll spend the next two years fighting your own system instead of working with it. Because unlike swapping a theme in WordPress, a headless CMS sits deep in the architecture: it determines how content is modeled, how developers query data, how fast pages are delivered – and thereby, indirectly, how well content surfaces in search engines and, increasingly, in AI answer systems.
In our day-to-day consulting at Calvarius, this question comes up constantly. That's why we compared the three most-discussed candidates – Sanity, Strapi, and Storyblok – not just on the basis of data sheets, but by setting them up ourselves in a dedicated proof of concept and testing them against one another. All three are mature, all three have committed advocates – but they pursue fundamentally different philosophies.
One important caveat up front: there is no objectively "best" CMS here. There is only the right one for a particular use case, a particular team, and a particular growth trajectory. This article is meant to help you find yours – not to adopt ours.
Our test setup: How we approached it
So that this comparison doesn't stop at marketing promises, we rebuilt an identical use case in all three systems: a multilingual corporate website with a blog, a product area, and nested content relationships (authors, categories, glossary terms, location pages). We evaluated along five dimensions:
- Content modeling – How cleanly can complex, nested structures and relationships be represented?
- Editor experience – How well do technical and non-technical editors cope?
- Developer experience – How quickly and how controllably can content be pulled into the frontend (Next.js)?
- SEO capability – How well does the system support structured metadata, Schema.org/JSON-LD, and performance?
- Operations & cost – What effort and what ongoing costs arise?
What stood out to us flows into the relevant sections as a "PoC finding."
The three philosophies in one sentence
The most fitting summary, which our PoC also confirmed:
Sanity treats content like data. Storyblok treats content like a design system. Strapi treats content like code – and gives you the server to go with it.
These three sentences explain a surprising amount about each platform's strengths and weaknesses.
Part 1: The candidates in detail
Sanity – The "Content Operating System"
Sanity starts from a radical premise: content is structured data, not pages. Everything is stored as a JSON document in what's called the Content Lake – a cloud-hosted, real-time-capable database. Every article, every product description, every image becomes a reusable data object.
The key building blocks:
- Schema-as-code: Content models are defined in JavaScript/TypeScript, not in a click-based interface. This versions cleanly in Git and is extremely powerful for complex, nested, or polymorphic data structures.
- GROQ: A dedicated query language (Graph-Relational Object Queries) with which you fetch precisely the fields a page needs. GraphQL is also available as an option.
- Sanity Studio: An open-source editing interface, fully customizable in React, that can be tailored down to the smallest detail to fit editorial workflows.
- Portable Text: A structured rich-text format that survives migrations and renders cleanly into any frontend – web, app, voice assistant.
- Visual Editing / Presentation: Sanity now offers a full "click-to-edit" experience directly from the preview.
PoC finding: The greatest strength showed up exactly where we expected it – in the nested relationships. Authors, glossary terms, and locations could be modeled as standalone, referenced documents, and GROQ pulled exactly what each page needed in a single query. What you understand here matters: GROQ and schema-as-code are tools of the setup phase – that is, our job as the development partner. Once the model is in place, editors never see any of it; they work in a tidy input form.
For whom? For companies that want a professionally built, durable content platform and hand the one-time technical setup to a partner. After setup, the in-house team maintains content comfortably through prepared templates – Sanity's full flexibility then sits invisibly "under the hood."
Strapi – The open-source heavyweight
Strapi is the most prominent open-source, self-hostable headless CMS. The Community Edition is free (MIT license), and with more than 72,000 GitHub stars, Strapi has one of the largest ecosystems on the market. Strapi 5 (rolled out in 2025) brought a reworked draft-and-publish logic and TypeScript-first schema definitions.
The key building blocks:
- Self-hosting as the core promise: You run Strapi on your own infrastructure, retain full data sovereignty, and pay no SaaS fees – but you take on operations, maintenance, security, and scaling yourself.
- SQL database underneath: Strapi relies on relational databases (PostgreSQL, MySQL, etc.). A genuine advantage for organizations with existing relational databases, data warehouses, and BI tools.
- Content-Type Builder: A graphical interface that lets even less technical users create content types – out of the box.
- REST and GraphQL APIs: Generated automatically.
- Strapi Cloud: Optionally, a hosted variant is available that takes part of the operational burden off your hands.
PoC finding: The Content-Type Builder felt the most familiar to non-technical colleagues. The sore point showed up in operations: schema changes to a running instance required more care than with the cloud competitors, and it quickly became clear that "free" here means no license fee, not no effort – someone has to be responsible for the database, storage, and maintenance.
For whom? Teams that need full data sovereignty and infrastructure control, want no recurring SaaS costs, bring their own DevOps competence – or have to connect an existing SQL landscape.
Storyblok – The visual editor for marketing teams
Storyblok bridges headless architecture and the visual expectations of marketing teams. Its distinguishing feature is the Visual Editor – a true WYSIWYG experience in which editors click directly on elements in a live preview and edit them. Changes appear in real time.
The key building blocks:
- Visual Editor: Industry-leading. If your marketing team has ever complained that "headless" means "we can't see what we're doing," Storyblok is the answer.
- Component-based model: Developers define reusable components (Bloks); editors assemble pages from them like building blocks. This fits naturally with modern frontend frameworks (React, Vue, Astro).
- Framework-specific SDKs for Next.js, Nuxt, Astro, and SvelteKit that handle the Visual Editor integration automatically.
- Built-in image service and solid SEO fundamentals.
- Release Merging (new in 2026): Automatically detects when released content is changed after release and flags it for re-review.
PoC finding: For building landing pages, Storyblok was unbeatably fast and intuitive – this is where the system serves non-technical users best. But as soon as we wanted to model deeper, multi-level data relationships (e.g., country → city → location), it became cumbersome. Storyblok thinks in pages, not in data graphs. An important practical note: the often-heard "without developers" promise refers to ongoing maintenance, not to the build. In a client project we're familiar with, the setup effort for the component architecture, the frontend, and the integrations turned out to be even higher than initially assumed – so a professional setup by a development partner is the rule here too.
For whom? Organizations whose primary drivers are marketers and editors and who want to work especially independently after the build. The initial build of the components and the frontend should be planned as a full development project here as well.
Part 2: The head-to-head comparison
Architecture & core philosophy
| Criterion | Sanity | Strapi | Storyblok |
|---|---|---|---|
| Core model | Content = structured data (JSON) | Content = code + relational DB | Content = visual components/pages |
| Hosting | Cloud / managed (Content Lake) | Self-hosted or Strapi Cloud | Cloud / managed (SaaS) |
| Database | Content Lake (proprietary, hosted) | SQL (PostgreSQL, MySQL …) | Proprietary, hosted |
| Content modeling | Schema-as-code (JS/TS) | GUI builder + code | GUI (Bloks/components) |
| Query language | GROQ (+ GraphQL optional) | REST + GraphQL (auto-generated) | REST (+ GraphQL from Premium) |
| Rich text | Portable Text (structured) | Blocks / Markdown | Rich-text field |
| Data sovereignty | With Sanity (cloud) | With you (self-hosted) | With Storyblok (cloud) |
Editor experience & administration
This is where the paths diverge most clearly – and exactly where you should honestly assess who in your organization works with the system day to day.
| Criterion | Sanity | Strapi | Storyblok |
|---|---|---|---|
| Editor type | Customizable Studio (form-based + Visual Editing) | Admin panel (form-based) | Visual WYSIWYG editor (leading) |
| Suitability for non-technical editors (after setup) | High (tidy input forms, live preview) | Medium (solid admin out of the box) | Very high |
| Live preview | Yes (Presentation tool, click-to-edit) | Yes (side-by-side, validation-oriented) | Yes (true WYSIWYG, primary interface) |
| Who sets it up? | Development partner (one-time) | Own DevOps / partner | Development partner (one-time) |
| Interface customizability | Very high (React-based) | High (plugins, custom fields) | Medium (component-bound) |
In short: The decisive question isn't "technical or non-technical?" but "How involved is the one-time build – and how easy is the daily maintenance afterwards?" Important: a professional build by a partner is the rule for all three systems once you're talking about a serious corporate website – including Storyblok, whose "without developers" promise refers to later maintenance, not to the build. The real difference comes afterwards: Storyblok plays to its strength in free, visual page-building by editors. Sanity scores with tidy input forms and long-term flexibility. Strapi sits between the two with its admin panel. We explain this split into one-time build and ongoing maintenance in the next section, because it makes the biggest difference for most SMEs.
Set up once, maintain easily forever
A widespread misconception goes: "Sanity is only for developers." That's only true for the setup – not for operation. And the setup is exactly the work that a partner like Calvarius takes on, once.
The reason this works so well: the vast majority of a website's pages follow recurring patterns. One blog page is structurally like the next, one product page like the one after it, one location page like all the others. We model these patterns once as a template (in technical jargon: a schema). After that:
- New content = fill in a form. Your team creates a new page by choosing an existing template and filling in the fields – title, text, image, meta description. No code, no GROQ query, no technical hurdle.
- Consistency is built in. Because every page comes from the same template, important fields (e.g., SEO title or last-updated date) can be made mandatory. No one can "forget" them.
- Live preview included. Through the Presentation tool, editors see their changes directly in the page layout and can click straight into the right field.
- Extensions remain possible. If a new page type is needed later, we add a template – the team keeps working with it right away, without migration pain.
Put differently: you're not buying "a tool you have to program yourself," but a ready-built editorial environment that's as easy to use as a good form – with Sanity's full technical power invisibly in the background.
What works – and what works less well
| Use case / requirement | Sanity | Strapi | Storyblok |
|---|---|---|---|
| Simple blog / landing pages | ✅ Good | ✅ Good | ✅✅ Excellent |
| Complex, nested content models | ✅✅ Excellent | ✅ Good | ⚠️ Limited |
| Cross-document relationships / references | ✅✅ First-class (graph-like) | ✅ Good (true SQL relations) | ⚠️ Moderate |
| True omnichannel delivery (web+app+IoT+AI) | ✅✅ Excellent | ✅ Good | ⚠️ Weaker (page-centric) |
| Visual page-building by marketers | ✅ Good (after setup) | ⚠️ Limited | ✅✅ Industry-leading |
| Full data sovereignty / on-premise | ❌ No (cloud) | ✅✅ Yes (self-hosted) | ❌ No (cloud) |
| Connecting an existing SQL/BI landscape | ⚠️ Via API | ✅✅ Native | ⚠️ Via API |
| Real-time collaboration (multiple editors at once) | ✅✅ Strong | ⚠️ Limited | ✅ Good |
| Scaling to tens of thousands of pages | ✅✅ Very good | ✅ Depends on your own setup | ✅ Good |
| No infrastructure to manage | ✅✅ Yes | ❌ No (except Strapi Cloud) | ✅✅ Yes |
Legend: ✅✅ = particular strength · ✅ = solid · ⚠️ = with limitations / extra effort · ❌ = not intended
Typical problems that arise in practice
Every platform has its recurring friction points. Named honestly – partly from our PoC, partly from documented practice:
Sanity
- GROQ is powerful but new – with a learning curve. That curve, however, concerns the setup (a partner's task), not later content maintenance.
- The cost model is usage-based. Direct (non-cached) API requests cost roughly ten times as much as CDN requests. With a well-considered delivery setup (CDN caching), this can be kept in check from the start.
- Add-ons are expensive: SAML SSO and additional datasets each run into four figures per month – relevant only for larger enterprise requirements.
- Document limits can force a plan upgrade on very content-heavy sites.
Strapi
- Schema changes can require downtime – a frequently cited pain point that demands planning during live operation.
- Self-hosting means: you bear responsibility for upgrades, security patches, backups, and scaling. This is not "set and forget."
- The true costs hide in infrastructure and developer time, not in the (non-existent) license price.
- Multi-channel delivery works but isn't solved as elegantly as in data-centric systems.
Storyblok
- Its strength with pages becomes a weakness with pure data delivery across many channels.
- Built-in datasources don't allow deep, multi-level key relationships.
- GraphQL and advanced workflow/role features are only available from the enterprise tiers (Premium/Elite) upward.
- No native video hosting on par with the image service – many teams make do with Vimeo or similar.
Part 3: The cost question
Prices change constantly – the figures below reflect the situation as of May 2026 and should always be verified on the official pages before a decision. In any case, what matters more than the sticker price is the cost model, because that's where the surprises arise.
Plan overview (indicative figures, as of May 2026)
| Sanity | Strapi | Storyblok | |
|---|---|---|---|
| Free | Free: 20 seats, 10,000 documents, 2 datasets, 1M CDN + 250k API requests/month | Community Edition (self-hosted): full feature set, free | Starter: 1 seat (max. 2), 100 GB traffic, 100k API requests/month |
| Entry (paid) | Growth: $15/seat/month | Strapi Cloud from approx. $15–18/project/month (Essential) | Growth: $99/month (5 seats incl.) |
| Mid tier | Growth + add-ons (quota, support, datasets) | Cloud Pro approx. $90/month | Growth Plus: $349/month (15 seats incl.) |
| Enterprise | Custom (SSO, SLA, support) | Cloud Scale approx. $450/month or Enterprise (self-hosted) custom | Premium / Elite: custom |
| Free-tier generosity | Very high (20 seats!) | Full (self-hosted), but operations cost | Medium (1 seat) |
Notes on the fine print:
- Sanity: The free tier with 20 seats is considered one of the most generous on the market. GROQ, GraphQL, real-time collaboration, and Visual Editing are included in every plan. The differences concern team features and scaling, not core functionality. Watch out for API overages and expensive add-ons.
- Strapi: With self-hosting, "free" means no license fee, not free of cost. Realistic infrastructure costs run, depending on the setup, from a few hundred euros per year upward – plus maintenance and DevOps time. Existing Essential customers keep their old limits; new limits apply only to subscriptions from December 22, 2025 onward.
- Storyblok: The free tier (Starter) is limited to 1 seat – quickly too tight for a real team. The jump to Growth ($99/month) and Growth Plus ($349/month) is steep. Important enterprise features (custom roles, workflows, GraphQL, SSO) only appear in Premium/Elite.
Part 4: Performance & SEO
Now to the heart of our own decision. This is where it gets concrete, because SEO today goes far beyond meta tags.
Is headless even good for SEO?
Yes – when implemented correctly. A headless architecture gives development teams more control over frontend performance, page rendering, metadata, and Core Web Vitals. Built correctly, that means faster load times and stronger technical SEO. The decisive point: headless gives more SEO control, not less – but it shifts responsibility from the plugin (think Yoast) to your own code. Instead of a plugin, you model SEO fields directly into the content model, implement Schema.org data, and automate XML sitemaps yourself.
Performance comparison (indicative figures)
| Metric | Sanity | Strapi | Storyblok |
|---|---|---|---|
| API response time (CDN, P50) | Very good | Depends on your own setup | Industry-leading (~22 ms P50) |
| Rendering strategies | SSG, SSR, ISR (e.g., via Next.js) | SSG, SSR | SSG, SSR |
| Scalability at tens of thousands of pages | Very good (targeted GROQ fetching keeps bundles small) | Self-managed | Good |
| ISR / on-demand revalidation | Well supported (webhook system) | Possible | Possible |
For fairness: on pure CDN-cached API latency, Storyblok is measurably ahead. For most real projects, however, the frontend's rendering strategy matters more than a few milliseconds of API latency – and in all three systems you can build very fast pages with SSG/SSR/ISR.
Why structured data is the decisive SEO lever
Search engines and AI answer systems favor content whose meaning they can reliably grasp. That's exactly what structured, consistently modeled data delivers: it makes authorship, recency, topical affiliation, and relationships between content machine-readable.
The point: when an author is modeled as a standalone, referenced document with their qualifications, this information can be played out automatically and consistently as author schema across all their articles. When every article has mandatory fields for last-updated date, sources, and topical classification, machine-readable quality emerges – not through after-the-fact plugin tinkering, but through the data model itself.
Part 5: Why we chose Sanity
We anchored our decision in four guiding questions. Each one feeds directly into SEO.
1. Content as data – the right foundation for structured SEO
For SEO work that rests on consistent structured content – glossary entries linked into long-form articles, comparison pages, topic clusters, author profiles – Sanity's data-centric approach is the right foundation. Schemas are code, references between documents are first-class citizens, and Portable Text delivers structured rich text that survives migrations and renders cleanly into any frontend.
Concretely: an author exists exactly once as a document, with all relevant attributes. A technical term exists exactly once and is referenced everywhere. From this we automatically generate clean JSON-LD (Article, Person, Organization, BreadcrumbList) – consistent across thousands of pages. It was precisely this consistency that proved most elegant to implement with Sanity in our PoC.
2. Full control over the technical SEO levers
Sitemaps, canonicals, redirects, and internal linking structures are implementation work in Sanity – but work you do once and then fully own. GROQ makes it possible to fetch exactly the fields per page, which keeps bundle sizes and build times manageable even at tens of thousands of pages. On-demand ISR revalidation is well supported through Sanity's webhook system – fresh content appears quickly, without full rebuilds.
3. Single source of truth = consistent content
Because everything syncs from one source, marketing can't publish outdated prices and the app can't pull a wrong description. This consistency isn't just operationally pleasant – contradictory information across channels is a negative signal for search engines, and a single source of truth bolsters quality.
4. Future-proofing for AI-driven discovery
Search is changing. Content no longer needs to be optimized only for classic SERPs, but increasingly for AI answer systems. Structured, cleanly modeled data is exactly the fuel these systems need. Portable Text renders cleanly across desktop, mobile, and voice assistants. Sanity's self-conception as a "Content Operating System" rather than a mere CMS fits this development.
What this choice means – and who carries it
Honesty is part of it: even the best choice has its conditions. The decisive thing is that most of them fall to the implementation partner, not to the client team.
- No full data sovereignty as with a self-hosted Strapi: content sits in Sanity's Content Lake (GDPR-compliant, EU hosting selectable). Anyone who absolutely needs on-premise is better served by Strapi – but for most SMEs, the hosted solution is the more pragmatic and safer path.
- One-time setup effort for schema, SEO fields, and frontend: that's our work as a partner, not yours. For you it means a clearly defined project start instead of ongoing technical burden.
- Attention to the cost model: we design the delivery from the outset (CDN caching, sensible query patterns) so that usage-based costs stay predictable and overages don't arise in the first place.
- GROQ as a setup tool: the learning curve concerns the build phase – that is, us. Your team never comes into contact with GROQ.
In short: the points that elsewhere show up as "Sanity is complicated" are exactly the tasks a good partner takes off your hands. What remains for you is a fast, search-strong website with an editorial environment that feels simple in everyday use.
For companies with strict on-premise requirements, Strapi remains the right choice. And a team whose focus is clearly on maximum visual independence for editors in day-to-day work is well served by Storyblok – though a professional build by a partner should be planned here too. For everyone who wants a professionally built, durable, and search-strong platform – without having to worry about the technology themselves – Sanity in combination with an experienced partner is, in our view, the best overall solution.
Decision aid: Which CMS fits whom?
A note on reading this: "Developer competence" with Sanity does not mean your team has to be able to program. It concerns solely the one-time setup – which a partner like Calvarius handles. Daily content maintenance requires no technical knowledge at all. This applies to all three systems, by the way: a professional build by a partner is the rule for serious corporate projects everywhere – so the tree mainly helps you find the platform that fits your way of working, not one that would get by "without a partner."
The short formula
| If you … | … then lean toward |
|---|---|
| need full data sovereignty & self-hosting | Strapi |
| are connecting an existing SQL/BI landscape | Strapi |
| want to enable true visual page-building for marketers | Storyblok |
| want to start fast and without much setup | Storyblok |
| have complex, nested content models | Sanity |
| publish truly multi-channel (web, app, AI) | Sanity |
| prioritize structured, SEO-driven content | Sanity |
| want a professionally built platform that your team then maintains easily | Sanity (with a setup partner) |
Conclusion
Sanity, Strapi, and Storyblok are all excellent tools – they simply solve different problems. Storyblok wins when the editorial/marketing experience is at the center. Strapi wins when data sovereignty, self-hosting, and connecting relational data matter. Sanity wins when content is conceived as structured data, when flexibility and multi-channel reach are central – and that is precisely the foundation on which modern SEO can be implemented most cleanly.
For us at Calvarius, the decision after the proof of concept was a logical one: anyone who wants consistent, machine-readable, and scalable content needs a content model that carries these properties from the ground up. Sanity gives us this foundation – and thanks to the clear division of labor (we set up, your team maintains), the supposed "developer-heaviness" turns into a genuine advantage: maximum technical strength in the background, simple operation in the foreground.
Our closing advice: don't let yourself be dazzled by feature lists. Ask first who will work with the system, how your content is structured, and where it needs to be delivered. The answer to that picks your CMS almost by itself. And if you need a second opinion along the way: evaluations exactly like this are our day-to-day business.
About the author
André Freier is Managing Director of Calvarius GmbH in Karlstadt am Main. With his team, he advises and builds modern, search-optimized web architectures based on headless CMS for mid-sized companies. The assessments in this article are based on a dedicated proof of concept across all three platforms presented.
Sources & further reading
- Sanity – official pricing overview: https://www.sanity.io/pricing
- Sanity – headless SEO: https://www.sanity.io/headless-seo
- Strapi – Cloud pricing: https://strapi.io/pricing-cloud
- Strapi – new Cloud limits (Dec. 2025): https://strapi.io/blog/introducing-yearly-plans-and-new-limits-for-strapi-cloud
- Storyblok – official pricing overview: https://www.storyblok.com/pricing
- Google Search Central – Helpful content & E-E-A-T: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
Note: All pricing and feature data reflect research as of May 2026. Headless CMS providers change tiers, limits, and features regularly – please verify the details relevant to you on the official provider pages before making a decision.
