Content as data definition
Content as data is the practice of modeling content as typed, structured fields and references that software can query, filter, and transform, rather than as formatted pages or blobs of HTML. Because the meaning lives in the structure, the same content can be reused by any channel, application, or AI system without being scraped or reparsed.
Content as data means treating content as typed, queryable records, such as titles, prices, authors, and the references between them, instead of finished pages. It matters for AI because models and agents can filter, reason over, and act on explicit fields rather than guessing meaning from formatted text. In Sanity, schemas defined in code set those types, Portable Text keeps rich text as structured data, and GROQ queries it like a database, so an agent retrieves exactly the fields it needs.

What does content as data mean in practice?
Content as data means every piece of content is broken into named, typed fields that a program can read without interpreting layout. A product description handled as a page is one block of formatted text in which the name, price, and sizes happen to appear. The same product handled as data is a record with a text field for the name, a number field for the price, a list of sizes, and a reference (a typed link to another record) pointing to its brand.
The difference shows up as soon as something other than a browser needs the content. With content as data, a mobile app, a search index, a voice assistant, and an AI agent can each ask for the price field directly. With a page, each of them has to extract the price from markup and hope the formatting has not changed.
How is content as data different from page-centric and document-centric content?
Content as data differs from page-centric and document-centric approaches in where meaning lives. In a page-centric system, content is authored as a web page, so structure is mostly visual: headings, columns, and styles that describe how things look, not what they are. In a document-centric system, content is authored as whole files or rich-text documents, so a single body holds everything and the parts are not individually addressable.
With content as data, meaning lives in the structure itself. A page-centric system can tell you that some text is bold and large. A document-centric system can tell you that some text is inside a file called the spring catalog. A content-as-data system can tell you that the text is the title of a product, that the product costs a specific amount, and that it belongs to a named brand. Presentation is applied later, separately for each channel, instead of being baked into the content.
Why does content as data matter for AI?
Content as data matters for AI because models and agents work better when facts arrive as explicit fields and relationships instead of prose they must interpret. Three effects stand out.
First, grounding improves. Grounding is the practice of giving a model trusted source material to answer from. When that material is typed data, a retrieval step can select only current, published, relevant records, for example only products in stock in a given region, instead of passing the model whole pages full of navigation, boilerplate, and outdated text.
Second, reasoning gets easier to check. If an answer cites a field, such as a price or a publish date, a person or another program can verify it against the source record.
Third, automation becomes possible. An agent can only act safely on content it can address precisely. Updating a field, translating one component, or flagging every article that references a discontinued product all require content that is structured as data. In our experience, automation built on top of HTML scraping tends to break whenever a template changes, while automation built on fields keeps working because the fields do not move.
How does content as data relate to structured content, schemas, and a content lake?
Content as data is the principle, and structured content, schemas, and a content lake are the pieces that put it into practice. Structured content is content that has been divided into meaningful, typed parts. A schema is the definition of those parts: which fields a type of content has, what kind of value each field holds, and which other types it can reference. A content lake is a single queryable store where all of that structured content lives together, so any application can ask questions across it.
Together these make content behave like a database while remaining editable by people. Without a schema, fields drift and nothing can rely on them. Without a queryable store, structured content stays locked inside the tool that created it. Content as data needs all three to deliver on its promise of reuse across websites, apps, and AI systems.
How do you start treating content as data?
Treating content as data starts with modeling what your content is, not how it looks. A practical sequence works in four steps.
First, list the real things your organization talks about, such as products, people, locations, policies, and articles, and give each one a content type. Second, define a schema for each type with explicit fields, choosing precise field types (dates as dates, prices as numbers) instead of free text. Third, replace copied text with references, so an author or a product exists once and is linked everywhere it appears. Fourth, keep rich text structured, so links, embedded components, and annotations are stored as data rather than as HTML.
Once content is modeled this way, presentation becomes a separate step that each channel handles for itself, and the same content can feed a website, an app, and an AI agent at once.
How does Sanity implement content as data?
Sanity implements content as data through three mechanisms: schemas defined in code, Portable Text for rich text, and GROQ for querying. Schemas are written as code, so content types, field types, validation, and references are versioned and reviewed alongside the applications that use them. Portable Text is a specification for storing rich text as structured JSON, which means paragraphs, links, annotations, and embedded objects remain queryable data instead of becoming an HTML string. GROQ is Sanity's query language, used to filter, join, and project content in the Content Lake the way a developer would query a database, for example asking for only the titles and prices of products under a set price.
This is the foundation that makes Sanity the AI Content Operating System: because content is structured as data from the start, the same fields that power a website can ground an AI model, drive an automated workflow, or be updated precisely by an agent.
Unlock New Possibilities with Sanity
With content as data under your belt, it's time to see what Sanity can do for you. Explore our features and tools to take your content to the next level.
Last updated: