The state of headless CMS

Let's start by assuming you've seen the latest takes from Lee Robinson (Cursor) and Knut Melvær (from Sanity) on the relevance of a headless CMS. The heart of the debate is that a headless CMS must solve everyday content problems, not create complexity.

We define modern content management systems by how effectively they help us streamline operations and move faster at scale, through AI automation, lean management, and shorter build times.

We are firmly in the camp of pro-headless content management systems, but we'd be lying if we didn't say we've bumped into a lot of the points Lee makes in his blog. We'll give our take on the whole ordeal at the end of the blog, so feel free to skip to the end if you're as impatient as we are.

Here is a list of features that we implement for our clients to ship content at speed and without pain.

Agentic editorial experience

The industry as a whole is dramatically shifting towards AI automation and workflows, with the ultimate goal of helping us ship faster. Dynamic, scalable content defines how websites perform, look, and grow on the web.

With the latest agentic features, larger teams can automate content generation, polish, and publish faster than ever. Marketing teams can prompt and generate repeatable features (e.g., SEO fields) without having to do them manually in every instance.

In our case, we use automation to move fast without producing slop; for example, generating FAQs from a blog post.

We also utilize built-in AI features such as Sanity's Content Agent to map and improve content, make global tweaks, and read patterns. It's pretty clever and comes in handy for keeping content up to date. See example below.

Use cases we use this with

These are vanilla versions of the ones we generally implement for clients, but feel free to take them and reword them for yourself.

Write a first draft blog post about [TOPIC]. Include an engaging introduction, 3-5 main sections with H2 headings, and a compelling conclusion with a call-to-action. Target word count: 1200-1500 words.

Analyze this content for the target keyword "[KEYWORD]". Check for:
- Keyword in title, H1, first 100 words
- Keyword density (aim for 1-2%)
- Semantic/LSI keyword opportunities
- Suggest improvements with specific placement recommendations.

For the topic "[TOPIC]", what subtopics, questions, or angles might competitors be covering that this content is missing? Suggest additions to make this the most comprehensive resource.

Review my title tag and meta description for SEO. Current title: "[TITLE]" Current meta: "[META]". Suggest optimized versions that include the keyword "[KEYWORD]" while maximizing click-through rate.

Preview should be a first-class citizen

If we had a dollar for every time an enterprise client came to us with a broken preview, we wouldn't be writing blogs; we'd be sitting on a yacht off the coast of the Bahamas. Most CMS on the market offer no real-time updates, live content context, or even an instant visual validation. Just “save and pray."

If your CMS is not showing editors what they’re changing as they’re changing it, you don’t have a headless CMS… you have a glorified JSON file.

And to be honest, we really don't think publishers should need to speak to a dev to push a change to the page title. Sanity’s Presentation has shown everyone how editing content should feel, with changes visible as you edit. The expectation is simple:

• Real-time updates without having to refresh the page, for both you and your users
• Instant validation that allows editors to see the result before hitting publish
• Preview environments that don’t fall apart when content models change

Visual editing

This is a fancy way of saying a layout editor, where you can stack blocks that your developers have built into any order to create things like landing pages, PPC pages, and services pages.

This differs from something like Webflow/Framer as it's closer to "design on rails". What that means is that you don't have to rely on a designer. Something like Webflow excels if you have a designer constantly creating new pages, but the larger it gets, the more of a pain in the ass it is to maintain.

That's why Visual Editing is such a boon for the marketing team. You drop and drag blocks like pre-defined LEGO, and focus on getting conversions, not correcting padding and proximity.

• Your blocks map directly to real frontend components
• What you drag is what actually renders
• You don’t need to imagine spacing anymore, although spacing can become a problem if you are not careful
• Multi-user edits happen instantly
• Change something, and preview updates before your brain finishes the thought

Stale cache

You’d think by late 2025 we’d all be past the era of “hit purge-all and pray nothing explodes,” but somehow… here we are. We still meet teams who invalidate their entire site because one intern updated a product description. And yes, we judge you. Lovingly, but we judge you.

Smarter route-level validation should be the norm now. You change one document, and only its related routes rebuild. You touch one component, and only the pages using that component refresh. The CMS should understand dependencies, not treat every change like a meteor heading for Earth. And yet every time we onboard a new project, we still find teams doing one of these:

• Hitting “purge all routes” like it’s a life philosophy
• Deploying five times because “the preview isn’t updating”
• Wondering why the homepage still shows data from 2022
• Blaming the CMS when the real culprit is, you guessed it, your caching layer.

Next.js has predictable cache behaviour, granular control, and components that refresh exactly when you need them to. Your CMS fires a webhook, Next.js receives the signal, the exact route gets purged, and your frontend updates instantly. Read more about cache components here.

Here’s the kind of snippet we end up wiring for most teams:

// Automatic route-level cache purge from CMS webhook
import { revalidateTag } from 'next/cache'

export async function POST(req: NextRequest) {
  try {
    const { slug } = await req.json();
    if (typeof slug !== "string" || !slug) {
      return Response.json(
        { success: false, message: "Missing or invalid slug" },
        { status: 400 }
      );
    }
    revalidateTag(`slug:${slug}`);
    revalidatePath(slug);
    return Response.json({ success: true, revalidated: true });
  } catch (error) {
    return Response.json(
      {
        success: false,
        message:
          error instanceof Error ? error.message : "Unknown server error",
      },
      { status: 500 }
    );
  }
}

Route-level purging is the baseline. If your CMS is not able to trigger precise revalidation hooks, or your hosting forces you into full-site busts, you’re basically speed-running “How to DDoS Yourself with Good Intentions.” Next.js solved most of this pain already. You just need a CMS that can actually talk to it properly, like Sanity.

DAM or don’t bother

Most CMS “media libraries” are just glorified Dropbox folders wearing a badge, and that is just embarrassing. A CMS should be able to handle licensing, orientation, search, filtering, versioning, and basic batch actions. Media management today means actual management.

That being said, as much as I would like to say that Sanity has a perfect score, this is the only thing I think they could handle better natively, and we'd love to see their hat in the ring with more integration functionality out of the box. It's a small blip on an otherwise perfect score. B- See me after class.

This is where we think Contentful shines: its default media library is very good at handling many of the above requirements. An alternative is simply running something like Cloudinary to handle this as soon as licensing is involved.

Currently, the best solution in Sanity is the media browser plugin, which is solid for tagging and filtering, but you're going to need to build out your own licensing logic if you need it.

Scheduling

When you really want to move fast, you need to be able to batch publish and even schedule a couple of weeks in advance. Marketing teams should be able to just pick a date, press publish, and trust the system not to break down. If you still need a developer, a CRON job, and a prayer just to publish a page next Tuesday, your CMS is from the wrong decade. You should be able to:

• Publish a single page,
• Drop 200 pages at once,
• Switch on a full seasonal takeover

…without waking up a developer at 11 PM. Sanity’s Releases already does this properly with group releases and predictable scheduling. It's really, really good. Just take the time to learn it. Some of the UX could do with some polishing. Until recently, we thought we had broken the unpublish button, but it's hidden really well.

Native AI

Most headless CMSes are rushing to slap some AI in the product, which is usually a tiny chatbot shoved in the corner that rewrites a paragraph and then begs for a tip, nowhere near what is actually needed.

Generally, whenever you're using AI, you're always fighting the "ejection point." This is the point where you eject out of the tool and use something completely separate. The more integrated the AI, the better.

Without going too deep, we've already used the Sanity AI assistant for:

• Alt text generation
• SEO cleanup and population
• Image classification + tagging
• Brand-tone rewriting
• Query generation that respects your schema
• One click first draft of a blog in a new language

Frankly, Sanity is far too modest about how far ahead they are with AI. It's literally the frontrunner as far as we're concerned, and it released an MCP months before any other content management system we know of.

When everyone else is giving you “rewrite this paragraph.” Sanity content agent gives you “scan 10,000 pages to fix outdated content, update metadata, and translate everything to Arabic” in one conversation.

Publishing, unpublishing, and rollback

Editors break things, that’s part of the job description, so why can’t more platforms let you undo mistakes the same way you undo a typo in Notion?

Publishing needs simpler controls and not an open Jira ticket. What we are saying is that rollback should be instant. If someone accidentally unpublishes the homepage at 4:59 PM on a Friday, you hit undo, it rolls back, and life goes on. Anything slower than that isn’t headless, it’s helpless.

And rollback is only half the story. As we’ve already said, workflows inside a CMS now need actual operational brains that handle multi-environment syncing, release candidates you can test safely, and schema guardrails.

Instant search

Search used to be a tiny checkbox in a CMS settings panel with “Enable search? Yes/No.” If your search still uses this, you're losing customers, revenue, and your team’s sanity (great pun, never been used before).

Today's users expect search to feel instant, smart, and creepily good at guessing intent. And if you’re running an e-commerce site, this is the difference between “Add to cart” and “I’ll check Amazon instead.” Here’s what “normal” looks like now:

• Fuzzy search
• Intent-aware search (yes, users don’t always know what they’re actually looking for)
• AI-embedding search that understands meaning, not strings
• Federated search across products, blogs, documentation, and FAQs
• Image-based search

Slow or dumb search is a quiet revenue killer. And yes, we’ve been shouting about this for a while. We were one of the first teams to build a production-ready search tool on top of Sanity’s embeddings index. When everyone is still talking about AI search now, we were already shipping it.

If you're looking at building e-commerce, talk to us, because there's some pretty nifty stuff you can do with Algolia + Sanity + Shopify.

Dev's favourite CMS

A good CMS must be easy for the content team to use, yes, we have heard this time and again. However, there is a special demographic that feels quite passionate about the craft itself. And they are eager to re-create if the existing one doesn't acknowledge the pain points.

We are referring to devs and dev communities. If they are getting blocked and not happy with the product they are implementing, you are overlooking a major group.

From open-sourcing to building plug-ins, dev communities nourish tools and make them easier to use for everybody else. So a dev-friendly CMS must be the first choice if you want your brand to do well in the long run.

The bottom line for 2026

The platforms that thrive now are the ones removing friction, not adding new knobs for teams to babysit.

Editorial teams want instant previews, real-time collaboration, clean media libraries, and scheduling that doesn’t require cron-jobs. Developers want fewer cache mysteries, smarter routing, and APIs that don’t collapse under load. Everyone wants less duct tape.

To summarise:

Don't build your own CMS, don't roll your own media libraries, focus on finding something that marketing likes and devs don't hate. We always recommend Sanity, but there are lots of good options out there like: Payload, Contentful and Tina CMS. Or the hell with it, go use markdown if your team is just developers and you feel brave.

If you want help picking the right platform or escaping the wrong one, we’re here to help. No question is too big or too dumb; we've heard it all.