Before you create a model or add a single field in Hygraph, you need a content model. It determines how your content is structured, how pieces of content relate to each other, and how your team works with it every day. A well-designed content model makes your schema easy to extend, your API predictable, and your editorial workflow efficient. A poorly designed one creates bottlenecks that no amount of tooling can fix.

This page covers the foundational questions you need to answer before opening the schema editor.

#What is content modeling?

A content model is the blueprint for your content. It defines what types of content exist in your system, what each type contains, and how types relate to each other.

In Hygraph, the content model lives in the schema editor. Each model represents a content type. For example, Article, Author, or Product. Each model contains fields that define the shape of an entry: a title, a publication date, a cover image, a reference to another model. The relationships between models that are defined through reference fields make a content model more than a collection of forms.

#What is structured content?

Structured content is data organized into discrete, well-defined elements rather than one undifferentiated block of text. Instead of a single document, you have a title field, a summary field, a date field, an image field. Each field has a clear purpose and is independently retrievable.

The practical consequence is reusability. A product name, price, and cover image defined once in a Product model can appear on a product detail page, a category listing, a homepage feature, and a search result, without any duplication.

Content modeling is the step that formalizes this structure. Identify how the concepts in your business domain relate to each other and translate that into a schema. The schema then governs how content is created, stored, queried, and reused.

Structured content

#Why content modeling matters

A content model sits at the intersection of your business goals, your users' needs, your editors' workflows, and your developers' requirements. A model that ignores any one of these groups will create friction for that group.

Here is what poor content modeling looks like in practice:

• Performance problems: Complex queries, deeply nested structures, and redundant data slow down your application and increase API response times.
• Duplicate content: Without clear relationships, editors create the same content multiple times in different places. Updates become inconsistent, maintenance becomes expensive.
• Scalability limits: Rigid, tightly coupled structures resist change. Adding a new content type or distribution channel becomes a much larger undertaking than it should be.
• Editor friction: A CMS built on a poorly designed model is difficult to navigate. Forms don't match how editors think about content, and content quality drops as a result.
• Developer friction: An API shaped by a bad model is hard to work with. Developers spend time compensating for schema decisions rather than building features.

In these scenarios, the CMS is not the bottleneck, but the model is.

#When to start

Before you write code, configure a frontend, or create a single entry, you need to think about content modeling.

The reason is structural. Content modeling is a bottom-up process. You define the shape your data will take, how it will connect, and how it will grow. That definition then informs every decision downstream, such as API design, frontend architecture, editorial workflow, and integration strategy.

Hygraph lets you adjust your schema at any point, and environments make it safer to test structural changes without touching production data. But the later a change is introduced, the harder it becomes. Once you have live content, schema changes can require data migrations, which cost time and resources. A solid model upfront prevents that.

#Who should be involved

Content modeling is a cross-functional activity. No single person has full visibility into the business goals, user needs, editorial workflows, and technical constraints that a good model has to balance.

Who should be involved

• Content creators: The people who use the CMS every day. Their workflow determines what fields and structures need to exist. Involve them early and interview them directly rather than guessing at their needs.
• Designers: Whether you start with the content model, wireframes, visual designs, or code, the team designing your project should be involved in thinking through the design of your content as well.
• Business stakeholders: Whoever is accountable for business outcomes should weigh in on what content serves those outcomes.
• Developers: Developers understand technical constraints such as performance, API shape, integration requirements. Their input prevents decisions that are editorially convenient but technically expensive.
• Content strategist: If your team has one, this person should lead or facilitate the modeling process. They bridge the gap between business needs and content structure.

The goal is to have a model that no single group had to compromise on because all groups helped shape it.

#Where to model your content

Complete your initial research and domain modeling before opening the schema editor. Once you have a clear picture of your content types and relationships, build and iterate directly in Hygraph rather than maintaining a separate planning document that will diverge from the real schema.

Working in the schema editor means you can see exactly what an editor will see when filling in a content form, based on the fields you have defined. You can test queries against your schema in real time to verify the API shape before building against it. You can use environments to experiment with structural changes safely.

Running modeling sessions inside Hygraph with editors, developers, and stakeholders is one of the most effective ways to catch problems early and build a shared understanding of the schema before content creation begins.

#What's next

• Content modeling in Hygraph: Learn how Hygraph's schema primitives (models, fields, components, enumerations) work before you build.
• Plan your content model: A practical guide to research, stakeholder sessions, domain modeling, and schema design.
• Best practices: Best practices for designing a scalable, maintainable, and editor-friendly content model.
• Content modeling walkthrough: A complete walkthrough of building a schema from scratch.

If you are following the Getting Started tutorial, these concepts are applied directly in Lesson 1.1: Design your content models.