Introduction

The content model is at the backbone of all Stackbit features.

All visual and non-visual information that makes up your website is made of pieces of structured content, whose format is well-defined by your content model. This concept is also sometimes referred to as content schema.

We use content not only to store "pure" content entities such as blog post content and author details, but also to model the full visual layout of the website. Everything is just content.

All components we provide are based on models included in your project. To customize, override or add your own components, you will typically also need to modify or add the appropriate models.

How Stackbit Loads Model Files

If your project is using a supported API-based CMS, the content model is automatically inferred from the CMS and there's no need to define it explicitly. Meaning, you won't find any model files in your project. This feature is available in premium plans.

Models are stored in YAML-formatted files with a .yaml or .yml extension. Each file defines a single model. A model's name is defined in the name attribute within the file, rather than by the file name. However, it is recommended practice to name your files after the model name.

By default, Stackbit will look for models under the directory .stackbit/models in your project.All our themes come loaded with models in that location.

Note that this behavior can be customized if you want to augment the models in your project with models from external packages (or replace the ones in your project completely).

Model Types

Every model must belong to one of three types:

  • Pages (type: page) describe the pages of your site stored in markdown files (e.g. .md, .mdx, .markdown).
  • Data (type: data) describe the arbitrary data of your site stored in data files (e.g. .yml, .yaml, .toml, .json).
  • Objects (type: object) describe the objects that can be nested within other objects of Page and Data models.

Model Naming Rules

As shown in the previous example, models are named as keys within the YAML file and must adhere to the following rules:

  • Must start with and end with a letter
  • Can contain only lower case alphanumeric characters or underscores _