Modeling content in Sanity for a marketing site

A content model decides what editors can change without asking a developer. The schema records that decision in code, but the decision should begin with the team's work.

For a marketing site, start with ordinary tasks: edit a headline, add an author, publish a story, assemble a landing page and update a shared call to action. The model should make those tasks understandable without exposing every implementation detail.

Decide what deserves its own document

A document is useful when content has its own identity, is reused, or needs an independent editorial lifecycle. Authors and customer stories are common examples.

An inline object can work well when the content belongs to one page or section. But reuse count is not the only test. Content used once may still deserve a document because of ownership, localization, permissions or publishing requirements.

Ask where the content should be edited and whether changing it should affect other pages. That is more useful than automatically making every visible block a document.

Define a small set of page sections

A page can contain an ordered collection of approved sections: a hero, customer logos, benefits, a story feature and a call to action.

Each section needs clear fields and rendering rules. Give editors meaningful choices without exposing every margin, color and HTML element as a field.

For example, the conceptual model might be:

page
  title
  slug
  sections[]
    hero: heading, text, image, action
    storyFeature: reference to customerStory
    callToAction: heading, action

customerStory
  title
  slug
  customer
  body

This is a modeling sketch, not a production-ready Sanity schema. The exact types and validation should follow the site's requirements.

Put guardrails where mistakes are expensive

Required values, clear field descriptions and constrained choices can help editors understand the intended content. Preview labels should identify a section without making somebody open every item.

Guardrails also belong in the renderer. Decide what happens with an unsupported block, an empty reference or a missing image. Make invalid content visible during development and review instead of quietly omitting it.

Do not assume Studio validation covers every data-writing path. Sanity documents that API writes do not automatically run Studio schema validation.

Make preview part of the model

Editors should be able to connect a field to its visible result. Configure previews and, where appropriate, visual editing against the components used by the site.

A useful demo is not just opening Studio. Have an editor change a hero, reorder approved sections and create a page from the available model. Check the preview, publishing action and resulting route.

Start with an editorial task inventory

Ask editors what they change repeatedly and which changes currently require help. A marketing content model should reflect those tasks. The answer may include updating a shared offer, publishing customer stories, creating campaign pages and managing author information.

For each task, identify the content that belongs to one page and the content that has an independent identity. A campaign introduction can be local to the page. A customer story reused on several pages may be better managed as a shared document. The decision should reflect ownership and publishing needs as well as reuse.

Do not begin by turning every component property into a CMS field. A developer may need a layout variant, an internal identifier and a rendering option; an editor may need a clearly named choice with a short explanation. The model should translate between those perspectives.

Model a small marketing site as a connected system

A hypothetical site might contain pages, articles, authors, customer stories and a shared call to action. Pages can assemble approved sections. Articles can reference authors. Story features can reference customer stories. The shared call to action can be reused where a single edit should update several places.

This is a starting model, not a required schema. A small site may need fewer types. A localized or regulated workflow may need additional structure. The useful question is whether editors can predict where a change will appear.

Give each section a clear content contract

Take a benefit grid. The editor may need a heading, introduction and a short list of benefits. Each benefit may contain a title, explanation and optional link. An approved variant can control the visual arrangement where there is a real editorial reason for the choice.

Define the contract in plain language before writing the schema. State which fields are required, what optional values mean and how the renderer behaves when they are absent. Avoid using a required image field if the design supports a meaningful text-only version; avoid pretending an essential action is optional if the section makes no sense without it.

Field descriptions should explain decisions an editor must make. “Choose the customer story this section features” is more helpful than exposing the name of an internal component. Preview labels should identify the section by its content so a long page can be understood without opening every object.

Design validation and error handling together

Validation should protect expensive mistakes and support the editorial process. It can identify missing values, incompatible choices or content that cannot be rendered as intended. It should not force arbitrary limits merely because a number looks tidy in the schema.

Consider the reader's result. A missing destination on a primary action is a different problem from an optional caption being empty. Explain the error at the field where the editor can fix it. Where a warning is appropriate, make clear why the editor might still choose to proceed.

The renderer also needs a policy for unsupported structures and missing references. During development, those conditions should be visible enough to investigate. In production, the page should avoid silently presenting misleading content. Decide whether the correct treatment is a controlled fallback, an omitted optional section or a blocked publication path.

Because content can enter through imports and APIs, include validation in those workflows too. Studio rules alone should not be treated as proof that every stored document has passed the same checks.

Test the model with ordinary and awkward edits

Ask an editor to build a page using the approved sections, then make a change that affects shared content. Confirm that they understand the difference. A convenient reference can become dangerous if nobody knows it updates several pages.

Test long headings, missing optional images, reordered sections and an unpublished referenced story. Preview the page at narrow and wide widths. These cases reveal whether the content model and components were designed together.

Then test a task outside the current model: a new comparison pattern or interactive tool, for example. The expected answer may be that a developer adds a component and schema. That boundary is healthy when it is explicit and ordinary editorial tasks remain independent.

Plan how the schema will change

Content models evolve. Before renaming a field or replacing a block type, identify the documents that use it and the renderer versions that expect it. A migration script or temporary compatibility layer may be needed so existing content remains usable during the change.

Keep changes reviewable. Document why the new shape is needed, what existing records require and how the result will be checked. Avoid leaving obsolete fields indefinitely without explaining whether editors should still use them.

For a Webflow migration, prove the schema with representative imported content before loading the full archive. The Webflow-to-Sanity guide covers conversion and reconciliation. The headless workflow comparison helps define the responsibilities the schema must support.

Keep the first model small enough to understand

Start with the sections the team repeatedly uses, then add new patterns when a real requirement appears. A large catalog of nearly identical blocks can make editing harder by hiding the intended choice. Consolidate patterns that share meaning, keep genuinely different editorial concepts distinct, and use labels that explain the result. Review the model with an editor after real content has been added; the usability of a populated page often reveals problems that an empty schema demonstration misses.

Define the boundary with development

A new page assembled from approved sections can be an editorial task. A new design pattern, data relationship or interactive feature can reasonably remain development work.

That boundary should be explicit before the migration. Independence does not require giving editors an unconstrained design tool; it requires giving them the controls needed for their actual work.

If ordinary tasks still require code changes, investigate the model. If an unusual task requires a new component, that does not automatically mean the model failed.

Plan your publishing workflow around what the team needs to change, then choose the schema that supports it.

Sources

• Sanity: Importing data. Checked September 18, 2026.
• Sanity: Visual editing. Checked September 18, 2026.