Structured content definition

Structured content means storing content as discrete typed pieces, a headline field, a price field, a publish date, rather than as one page-shaped blob of markup. In Sanity, those types are declared as schemas in your codebase, plain JavaScript or TypeScript objects that describe the structure, relationships, and constraints of your content, while the Content Lake that stores it is itself schema-less, so the model can change without rebuilding the database.

What makes content structured rather than unstructured?

Structured content has three properties, and content that lacks any one of them is unstructured. The first is granularity: content is decomposed into the smallest independently useful units, so a product's price, name, and disclaimer are separate, addressable pieces, not three sentences inside one text field. The second is explicit typing, meaning each unit carries a machine-readable declaration of what it is (a date, a reference to an author, a currency amount), not just how it should look. The third is presentation independence: the stored form makes no assumptions about the channel that will render it, so layout is a downstream decision.

Unstructured content is the opposite case: a single undifferentiated payload, like a Word document, a wall of pasted HTML, or a page assembled in a visual editor where the headline, the price, and the legal disclaimer are all text nodes in one field. The tell is not the absence of formatting, because unstructured content can look perfectly tidy. The tell is the absence of addressability. If you cannot ask the system for every product's price without parsing HTML, the content is unstructured, no matter how neat the page looks. Digital.gov puts the same idea plainly: think about content as building blocks instead of pages.

The consequences follow directly from the three properties. Content can be reused without being duplicated, corrected in one place and updated everywhere it appears, delivered to a website, an app, and an in-store screen from the same source, validated field by field, and queried like data.

What is the difference between structured content and structured data?

Structured content is how content is stored and modeled at the source, while structured data is machine-readable markup added to an already rendered page to describe what that page is about. The two terms are near-homonyms and search results blend them, but they sit at opposite ends of the pipeline. Structured data in the search engine sense means schema.org vocabulary expressed as JSON-LD or microdata in the HTML of an output page. Structured content is the shape of the content before anything is rendered.

You can have either one without the other. A page whose body is a single pasted HTML string, with an SEO plugin emitting Article markup on top, has structured data over unstructured content. A carefully modeled content repository that renders plain HTML has structured content and no structured data. They compose well, because typed source fields make correct markup straightforward to generate, but they are not the same thing.

There is a second, unrelated meaning of "structured data" that trips up readers from data engineering. In that field, structured data means data that fits a rigid tabular schema of rows and columns, and unstructured data means documents, images, and free text. By that taxonomy most content is semi-structured: typed fields wrapping human prose. So "structure your content" never means "flatten your content into a spreadsheet." Structured content keeps the prose. It just stops treating the prose as the only unit.

How is structured content different from content modeling and headless delivery?

Content modeling is the practice, structured content is the result, and headless is a delivery choice that is independent of both. A content model is the blueprint: which content types exist, what fields each one carries, and how they reference each other. Structured content is what you have once content is stored according to that blueprint. The distinction matters because a team can model badly and still have structured content, which is why "we have a CMS with fields" is the start of the conversation, not the end.

Headless describes how content is delivered, over an API and decoupled from any single rendering layer. Structured content describes how content is modeled. Decoupling delivery does not structure anything on its own. A headless system that serves one giant HTML body string per page has moved the problem, not solved it. Conversely, a tightly coupled system with a genuinely granular model still has structured content.

Tagging and metadata have a similar relationship. Adding taxonomy terms to an item is a real improvement, and metadata is part of the definition, but metadata describes the whole item from the outside. Structured content decomposes the inside of the item. A blog post tagged "pricing" is better organized. A blog post whose price figures live in typed fields is structured.

Can long-form writing and rich text be structured content?

Yes. Long-form prose stays prose in structured content, because rich text can be modeled as an array of typed blocks with typed inline annotations and embedded references, rather than as one HTML string. That is what makes a pull quote, a footnote, or an embedded product card independently addressable inside an article body. HTML in a textarea is the unstructured version of exactly the same writing.

Sanity handles this case with Portable Text, a structured rich-text format that separates content from presentation and can be inspected as the underlying JSON. In a schema, a Block field used inside an array gives you block content as Portable Text, and the same schema files declare the other primitives that make decomposition real: String, Number, Boolean, Date and DateTime, Image and File, Reference, Array, Object, Slug, and Geopoint. Reference fields create indexed, queryable links between documents, and document types do not have to map to a page or a post; a type can just as easily be a project, a person, a product, or a place.

For teams whose writers work in free-form drafts, Content Mapping uses the schema to transform a free-form document from Canvas into a structured document in the Content Lake, where it can then be edited in the Studio and other apps. When the model needs to change, schema migration tooling programmatically transforms existing content to match the new structure and runs validation rules across the whole dataset.

Why does structured content matter for search, AI, and multichannel delivery?

Structured content matters because typed, addressable pieces can be filtered and recombined by machines. That requirement is shared by multichannel publishing and by AI retrieval. The idea is older than the current AI cycle. It came out of technical documentation and XML publishing, then entered web content strategy as COPE, Create Once Publish Everywhere, coined in 2009 by Daniel Jacobson, then Director of Application Development at NPR, whose public API launched in 2008 around that model.

Retrieval systems benefit for a specific reason: structure gives them typed predicates to filter on and stable units to chunk against. Sanity is The Content Operating System for the AI era, and the querying layer is GROQ, described in Sanity's own agent context material as precise, filterable, and totally fresh by default, with hard filters composing alongside keyword and semantic ranking in a single query. Sanity's production observations on Context MCP show that the heavy majority of agent calls are structured GROQ queries and schema lookups, with semantic search a small slice, and with embeddings opt-in and off by default. That is a first-party observation about Sanity's own platform, not an industry-wide measurement.

Be careful with the term AI-ready content, which vendor copy often uses as a synonym. Structured content is a precondition for it, not the same thing. AI readiness also depends on freshness, permissions, and evaluation, none of which structure alone provides.

Last updated: September 10, 2026