Content model

The blueprint of your content types and their fields, so a 'recipe' or 'case study' is real structure instead of one blob of rich text.

what fields does a blog post havethe shape of my contentcontent types and fieldscontent schemastructured contentcontent modellinghow do I set up my CMS collectionspost type with custom fields

See it

Live demo coming soon

What it is

A content model is the blueprint of the content types a system stores and the fields each one carries: a 'recipe' has prepTime, servings, ingredients, steps; a 'case study' has client, industry, metric, quote. It also names the relationships between types (a post references an author, an author has many posts). This is the layer that turns content from one giant rich-text blob into data you can sort, filter, syndicate, and put on a card. The old NPR slogan for the payoff is COPE: create once, publish everywhere.

Model before you build whenever the same content has to appear in more than one place: a listing card, a detail page, an RSS feed, an app, a structured-data block for search. Every modern CMS asks you for this up front, whether it calls them collections (Astro), schemas (Sanity), content types (Contentful), or blocks and fields (Payload, WordPress ACF). If the answer lives in the field, you can render it a hundred ways. If it lives inside a paragraph, you can only print it.

Gotcha: the common failure is modeling the page layout instead of the content. Fields named hero_headline, section_2_image, and bottom_cta_text describe one design, so the day you redesign, every entry is wrong and nothing is reusable. Name fields after what the thing means, not where it sits. The opposite failure is over-modeling: fourteen optional fields nobody fills in, on a type that publishes twice a year.

Ask AI for it

Design a content model for [project]. List each content type with its fields: field name, type (string, rich text, date, number, reference, media, enum), required or optional, and a one-line note on what it is for. Show relationships between types explicitly. Name fields after meaning, never after page position, so no hero_headline or section_2_text. Keep optional fields to a minimum and justify each one. Then show the same model expressed as an Astro content collection schema with Zod, and flag any field that would break if the site were redesigned.

You might have meant

content strategycontrolled vocabularycontent briefsingle sourcingcontent lifecycle