Why Schema-Driven CMSes Beat Block-Based Page Builders

You shipped the first landing page in an afternoon. The editor dragged in a hero, a three-up feature grid, and a testimonial block, hit publish, and everyone was thrilled. Then the second channel arrived. The mobile app needed the same testimonials without the layout. The sales team wanted to syndicate the feature copy into a deck. A new AI assistant needed to answer questions about the product. And the content was trapped inside a tree of presentation blocks, glued to one page, in one front end, in a shape no other consumer could read. Sanity exists for the moment that block-based page builders quietly fall apart: when content has to outlive the page it was born on.

This is the structural argument for schema-driven content modeling over block-based page building, and it is not a religious one. Page builders win the first sprint. They lose the second channel, the reuse request, and the agent. Sanity is the Content Operating System for the AI era, an intelligent backend that keeps content as typed, queryable, field-owned data rather than a layout artifact. This article walks through where the block model leaks presentation into your content, why that coupling compounds as you scale, and how a schema-first approach with live Visual Editing gives editors the WYSIWYG they actually want without surrendering everything downstream.

The failure mode: content welded to one presentation

A block-based page builder models a page as a tree of presentation components. A hero block holds a headline, a background image, and a layout choice. A columns block holds child blocks. The editor sees the page exactly as it will render, which feels like a superpower right up until something needs that content somewhere the page does not exist.

Consider the testimonial that lives inside a three-up grid block on your homepage. The quote, the attribution, and the company are real, reusable facts about your business. But in the block model they are properties of a layout slot. To answer the question "give me every customer quote we have published," you would have to crawl page trees looking for grid blocks that happen to contain testimonial children, then parse presentation away from substance. The data is there; it is just buried under decisions about how it looked on one screen.

This is the core defect. A page builder optimizes for the rendered output and treats content as a byproduct of layout. That is backwards for any organization whose content will be read by more than one front end. The moment a second consumer appears, a mobile app, a partner feed, a search index, a voice interface, or an AI agent, you are paying to reverse-engineer structure out of a presentation blob. Schema-driven modeling inverts the priority: you describe what a testimonial is once, as a typed object with a quote field, an author reference, and a company reference, and let any number of presentations consume it. Layout becomes a question the front end answers, not a cage the content lives in. This is the first of Sanity's three pillars, Model your business, and it is the difference between content you own and content your page owns.

Why the page-builder advantage inverts at scale

Be fair to the block model: it earns its popularity. A marketer can compose a campaign page in Builder.io or Storyblok without filing a ticket, drag sections into place, see the result live, and ship. For a single designed website with one front end, Webflow CMS or a visual builder is often the fastest honest path to a polished page. If your entire content surface is one marketing site that one team controls, the structural objections in this article may never bite you.

The advantage inverts the moment any one of three things happens. First, a second channel: now the layout assumptions baked into your blocks are dead weight that the app cannot use. Second, reuse: the legal team wants the approved product description in a contract template, and it is fused to a hero gradient. Third, queryability: someone needs to ask a question across all content, and a tree of opaque blocks has no good answer to "find me." Each of these is the same problem wearing a different hat. Presentation and content were never separated, so every downstream use pays an extraction tax.

The deeper issue is organizational, not technical. Legacy systems force you to scale people to scale output, because every new channel or reuse case is manual work against an unstructured artifact. A schema-driven foundation lets you scale output instead, because the same modeled content fans out to every consumer automatically. Sanity treats this as a first principle: rather than making you work the tool's way through a fixed page model, the Studio is a React application you configure with your own schemas, custom input components, and Structure Builder, so the model bends to your business instead of your business bending to a block palette.

Structured fields are access control, not cosmetics

The most underrated consequence of typed content is governance. When content is a single block blob, ownership is a single blob too: whoever can edit the page can edit everything on it. When content is split into typed fields, ownership splits with it, and that is a feature, not bureaucracy.

Sanity's knowledge base makes this concrete with an example from AI agent governance that maps cleanly onto ordinary content. Model an application prompt as a document with separate fields: a voice field of Portable Text blocks, a userContext field, an escalation field, and a mustNotSay field of forbidden topics. Now ownership follows the schema. As the doc puts it, "Splitting the prompt into fields isn't cosmetic. It's access control. Brand owns voice. Product owns how the agent uses user context. Support owns escalation. Compliance owns the never-say list. None of them files a pull request. None waits for a deploy." The fields stitch together at runtime the same way a page builder stitches sections into a page, except every field has a clear owner and a clear audit trail.

The payoff comes from where this content lives. Because it is content in the Studio, you get, in the words of the same doc, "real-time collaboration, version history, scheduled publishing, and rollback for free." A block-based blob denies you exactly this granularity. You cannot give Compliance edit rights to the forbidden-topics list and only that list when the list is a paragraph inside a section inside a page tree. Schema-driven modeling makes field-level ownership, review, and Content Releases possible because the boundaries between concerns are real objects, not visual regions an editor happened to drag near each other.

Querying a model versus crawling a tree

Once content is modeled as typed objects, you can ask it questions. This is where the gap between a schema-driven backend and a block tree becomes a chasm, because a page builder has no real query surface; it has a renderer.

GROQ, Sanity's query language, lets you ask for exactly the shape you need in a single round trip, including projections, filters, and references followed inline with the arrow operator. Want every published testimonial with its author's name and company resolved? One query, one trip, exact shape. Compare that to GraphQL's fixed shapes and resolvers, where you shape responses against a predefined schema graph, or to a page builder, where the answer is "parse the HTML." GROQ also goes somewhere neither a block tree nor pure GraphQL can: hybrid retrieval inside the query itself. Sanity's documented pattern filters with structural predicates, then runs a score pipeline that blends a BM25 keyword match with semantic similarity:

*[ _type == "product" && category == $category && price < $maxPrice ] | score( boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText) ) | order(_score desc)

As the knowledge doc explains, "The predicates do the filtering that has to hold. The score pipeline blends a BM25 keyword match on the title (weighted 2x, because title hits matter more) with a semantic similarity score across the document. The result is a small, ranked list that matches both the structural constraints and the vibe." Pure structured query alone "falls over the moment the user says 'something like X' or 'the cozy one.'" Blending both in one query is the capability a layout-first builder cannot approach, and it maps to the third pillar, Power anything: one model, queried any way a consumer needs.

Live preview without collapsing the model

Here is the objection worth taking seriously. The single best thing about a block-based builder is that editors see what they are getting. They drag a section, the page updates, no imagination required. Tell a marketing team they must give up WYSIWYG to gain structure, and they will, correctly, push back. A structured model that ships as a blind form of fields is a real regression in editor experience.

The false premise is that you must choose. You can have a fully structured content model and live, in-context editing on top of it. Sanity bridges this with Visual Editing and the Presentation Tool: editors work against the real rendered front end, click an element on the live preview, and jump straight to the field that controls it, with edits reflected as they type. The content stays modeled as typed objects in Content Lake; the preview is a view onto that model, not the model itself. Click-to-edit is powered by source maps that trace a rendered element back to the field and document it came from, so the WYSIWYG affordance sits on top of structure rather than replacing it.

This is the reframe the whole article builds toward. Storyblok and Builder.io reach live preview by making the block tree the content; the preview is faithful because the layout is the data. Sanity reaches the same in-context editing outcome by making the preview a projection of a structured model. Editors get the immediacy they want, and the organization keeps content that a second channel, a query, a contract template, or an agent can consume without an extraction project. You are not trading editor experience for structure. You are keeping both.

Structured content is the substrate for AI and agents

The last argument is the one that has aged the block model fastest. Every organization is now wiring content into AI assistants, and AI consumers are brutally honest about the cost of unstructured content. A model fed a presentation blob has to paraphrase it, and Sanity's knowledge base puts the consequence bluntly: "A tool that returns prose forces the model to paraphrase, and paraphrasing is where facts go to die."

The same doc reports what the team observed building agents against the Sanity Context MCP endpoint: "the ones that worked returned schema-shaped responses the model could pass straight through. The ones that struggled got a wall of text back and re-narrated it, badly. If your agent is supposed to return three products, the tool should return three product objects, not a paragraph describing them." A block-based page is precisely the wall of text problem in structural form. Hand an agent a page tree of presentation components and it must reverse-engineer meaning from layout, exactly when you most need facts to stay facts.

This is why CMSes that bolt AI on as a side panel miss the point, while a content backend built for it does not. Sanity positions Content Lake as fuel for AI assistants and exposes Agent Actions, schema-aware APIs for generating, transforming, and translating content with LLMs that you can call anywhere you run code. Because retrieval is wired into the content backend, the freshness problem, incremental indexing, re-embedding on change, deletion handling, and backfill for schema changes, "stops being something you maintain." Structured content is not a nicety here. It is the substrate. The intelligent backend for companies building AI content operations at scale starts from typed, queryable content, which is exactly what a block-based page builder, by design, does not produce.