← All posts

Comparison

Which is the best headless CMS for an AI? Contentful, Sanity and Strapi, tested

Contentful allows the most of the three — 10 of our 14 jobs against 9 for Sanity and 7 for Strapi — and the reason is not performance or developer experience but a short list of unglamorous features: scheduling, tags and a way to report what is in the space. All three read, write, edit and publish without complaint. The table below is printed from the three adapters that do the work, so it is a comparison of what the APIs permit rather than of what their marketing pages describe.

Published 20 October 2026 · Last updated 20 October 2026

One thing to say first, because it decides whether this post is about you at all: a headless CMS is where content lives, and this product is a way of talking to one. We are not a headless CMS, we store nothing, and we serve nothing to visitors.

Why these three are not like the others

On WordPress or Joomla, the content system and the website are the same thing at the same address. On these three they are not: your website is whatever somebody built on top of the content store, and the store is somewhere else entirely. So the thing you connect is a space, a dataset or a project — not an address a visitor would ever type.

That has two practical consequences. First, there is no "page" to publish in the sense other platforms mean: publishing marks an entry as available to whatever reads the store, and whether a visitor then sees it depends on a website nobody here controls — Contentful in particular will report something as published that no visitor can reach, because the front end has not been rebuilt. Second, there is no fixed content model. On the other platforms a post is a post; here you invented your own types, and nothing can be written until somebody has said which of your types holds articles and which of its fields is the body. We ask that during setup rather than guessing, which is the one bit of this that is slower than the others and the one bit nobody should automate.

The three, side by side

This table is generated from the adapters when the page loads, not typed out. A green cell means the software will attempt that job on that platform; a grey one means it refuses before it tries, because the platform offers no supported way to do it. Bulk work is the one row that is empty for every platform: no adapter claims it yet, and the automation page says so too.

Contentful: 10 of 14, and the only one that can schedule

Contentful's scheduled actions are a real feature of its management API: Contentful holds the booking and publishes the entry itself, rather than something of ours waking up to do it. It also has tags, which is as close as any of the three comes to categories, and enough information about a space to report on it. Two things to know. Its new tags are private by default, and a private tag is invisible to the API that serves your website — so a tag created for filing an article would produce something your own site cannot read; ours are created public, and say so. And a Contentful connection is pinned to one environment of one space: two environments means two connected websites here, which is deliberate, because the alternative is a request landing in the wrong one. Contentful has no SEO metadata of its own, so that row is grey — whatever field you use for a meta description is a field you invented, and writing into somebody's invented field under the name of an SEO capability is a promise we will not make.

Sanity: 9 of 14, and the only one where a draft is a different document

Sanity keeps drafts as separate documents rather than as a state on one, which is clean and catches everybody out once: editing a published article saves to the draft and leaves what visitors read untouched. Our own tool description used to promise the opposite, and it was true everywhere except here. The other Sanity-shaped fact is about its schema. A Sanity schema has traditionally lived in your Studio's code, where nothing outside it can read it — but a recent Studio command stores it in the dataset itself, where it can be read properly. If you have run it, we read your real content model, including types you have defined and not used yet; if you have not, all that is honest is to observe which types your documents actually have, and we label every type with which of the two it came from rather than calling an observation your content model. Sanity can write SEO fields, which Contentful and Strapi cannot, and it cannot schedule: it schedules a release of content, which is a genuinely different thing.

Strapi: 7 of 14, and the one where failures are silent

Strapi is the most self-hosted of the three and the one that asks the most care. Its tokens can be scoped per collection, which is good; the ordinary failure mode is that something is simply not granted, and a token missing a permission produces an answer that reads like an empty site rather than a refusal. So the adapter distinguishes between "that collection is there and your token may not see it" and "nothing is called that", and says which. The bigger trap is between Strapi 4 and Strapi 5: both publish on create by default, and they are stopped from doing so in two different ways — so sending the newer version's instruction to an older one publishes an unfinished draft on a live site. The version is established from the shape of a record before any write, and when it cannot be established, nothing is written. Strapi has no tags or categories of its own and no SEO fields, which is most of the gap between 7 and 10.

How to choose between them, if you are choosing

Nobody picks a content store for how well an assistant can reach it, and they should not. But if the choice is otherwise close, three things in the table are worth real money.

• Scheduling. If you want to ask for something to go out on Tuesday, Contentful is the only one of the three that can hold that booking itself. On the others it is not a field that exists.
• A readable content model. Anything that writes into your store has to know your types. Sanity can now publish its schema where it can be read; Strapi has an interface description that is off by default; Contentful's model is readable through its management API as a matter of course. The more readable it is, the less setup you do by hand and the fewer ways there are to get it wrong.
• Somewhere for SEO text to live. None of the three has SEO fields as a platform feature. Sanity is the only one of the three where ours will write them, and that is because of how Sanity exposes what you have defined — on the other two we would be writing into a field you invented and calling it something it is not.