Content Modeling

Content modeling is the practice of defining the structure, types, and relationships of the content your site or application will use. In SleekCMS, every piece of content — a page, a blog post, an author profile, a hero banner — is backed by a model that declares its shape as a set of typed fields.

This page explains the modeling philosophy behind SleekCMS, introduces the three model types and how they relate, and covers the structural field concepts you'll use to organize content within models.

Why Structured Content Matters

Unstructured content is a single blob of rich text — a WordPress post body, a Google Doc, a Notion page. It mixes data with formatting and gives you no reliable way to extract individual pieces (the author name, the CTA button label, the hero image) for use in different contexts.

Structured content separates every meaningful piece of data into its own typed field. A blog post isn't a rich text blob; it's a model with discrete fields for title, slug, author reference, published date, excerpt, featured image, and a body composed of ordered content blocks. Each field has a type (text, image, reference, boolean), validation rules, and a clear contract with the templates and APIs that consume it.

This matters for three reasons:

Multi-channel delivery. The same content model can feed a static site, a mobile app, a third-party integration, and a future redesign — because the data isn't entangled with any single presentation.

Editor experience. Content editors work with purpose-built forms rather than free-form text. They pick an author from a dropdown, toggle a featured flag, reorder section blocks. The editing interface is derived directly from your model, so the structure you design determines the experience they get.

Governance at scale. When every page and component has a defined schema, you control what content can exist and where. An editor can't accidentally break a layout by deleting a required field or inserting an unsupported element.

The Three Model Types

SleekCMS has three model types. Each serves a different architectural role, and understanding when to use which one is the most important modeling decision you'll make.

Page Models

A page model defines routable content — content that maps to a URL and renders as a page on your site.

Pages are the top-level containers in your content architecture. They hold fields for metadata (title, description, OG image), SEO configuration, and most importantly, the layout structure that determines what appears on the page. Pages can include dynamic block fields that let editors compose the visual layout from a set of allowed blocks.

Pages come in two variants:

Static pages are single instances bound to a fixed path you define in the model (e.g., /about, /pricing). One model, one page, one URL.
Page collections generate multiple page instances from a slug field (e.g., /blog/:slug). SleekCMS creates routes automatically for each instance.

Use page models whenever content needs its own URL.

→ Page Models in depth

Entry Models

An entry model defines structured data that is not directly routable. Entries don't have URLs — they exist to be referenced by pages, other entries, or consumed via the content API.

Entries are your shared, reusable data objects. An author entry holds a name, bio, avatar, and social links. A category entry holds a label and slug. A site settings entry holds global navigation items, footer text, and feature flags. Pages and blocks reference these entries through relational fields, and a single entry can be referenced from many places.

Entries can be configured as admin-only, which makes them invisible to content editors and ideal for global configuration that shouldn't be duplicated or accidentally modified.

Use entry models for shared data, lookup tables, configuration objects, and anything that multiple pages or blocks need to reference.

→ Entry Models in depth

Block Models

A block model defines a reusable, composable content component — a self-contained section or UI element that can be placed inside pages (or other blocks).

Blocks are the building blocks of visual layout. A hero block might have fields for heading, subheading, background image, and CTA button. A testimonials block might have a collection of quote items with author references. A pricing table block might have tier entries and a toggle for annual vs. monthly billing.

Blocks differ from entries in how they're used:

Blocks are embedded inline. They don't appear in a standalone content list; they exist inside the pages and content that contain them.
Blocks are composable. Editors add, remove, reorder, and hide blocks within a page's dynamic block field, assembling layouts from the components you've defined.
Blocks can be nested. A block can contain other blocks, enabling complex but governed layout hierarchies.

The same block model can be used across multiple page models. If you update the block's field structure, the change applies everywhere that block is used.

Use block models for visual sections, UI components, and any repeatable layout element that editors should be able to compose into pages.

→ Block Models in depth

Choosing the Right Model Type

Question	Answer	Use
Does it need its own URL?	Yes	Page model
Is it shared data referenced from multiple places?	Yes	Entry model
Is it a visual section editors compose into pages?	Yes	Block model
Is it global config (nav, footer, feature flags)?	Yes	Entry model (admin-only)
Is it a standalone data record accessed via API?	Yes	Entry model

Fields as Data Structures

Every model is made up of fields. Fields are the atomic units of your content schema — each one defines a named, typed piece of data with optional validation and display rules.

SleekCMS groups fields into four categories:

Textual fields handle strings, rich text, numbers, booleans, dates, and other scalar values. These are the most common fields and cover the majority of your content data.

Media fields handle images, files, and other uploaded assets. Image fields integrate with image processing (via Imgix) for automatic resizing, format conversion, and optimization.

Structural fields organize other fields within a model. These don't hold content data themselves — they define how fields are grouped, repeated, or composed. There are three structural field types, and understanding the distinction between them is critical.

Relational fields create references between models. A reference field on a blog post page model might point to an author entry model, letting editors pick an author from a dropdown. References can be one-to-one or one-to-many.

→ Field Types reference

Structural Fields: Group, Collection, and Block

Three field types control how content is structured within a model. They look similar at first glance but serve fundamentally different purposes.

Group

A group is a container for organizing fields visually. It doesn't add a new data structure — it simply nests related fields together in the editor UI and optionally arranges them into columns.

Groups are a modeling convenience. Use them to cluster related fields (e.g., grouping "Street," "City," "State," and "Zip" under an "Address" group) so the editor form is scannable and logical. You can reorganize groups without affecting your data.

Groups are not reusable across models. They exist only within the model where you define them.

→ Group fields

Collection

A collection is a repeatable inline structure. It defines a set of fields that editors can duplicate as multiple items within a single content instance — an FAQ list, a feature grid, a set of bullet points.

Each item in a collection has the same field structure, and editors can add, remove, and reorder items. Collections are defined and edited inline; the data lives within the parent model instance.

Collections are not reusable across models. Like groups, they're defined within a single model. If you need the same repeatable structure in multiple models, use a block instead.

→ Collection fields

Block (as a field)

A block field embeds a block model inside another model. Unlike groups and collections, the structure is defined externally in a block model and referenced by the field. This means:

The same block can be used across multiple models.
Changes to the block model propagate to every instance.
Each block has its own view template, separating content structure from presentation.

Block fields can reference a single block type or allow multiple types (via dynamic blocks).

→ Block fields

Comparison

Capability	Group	Collection	Block
Organizes related fields	Yes	Yes	Yes
Repeatable (multiple items)	No	Yes	Yes (via dynamic blocks)
Reusable across models	No	No	Yes
Has its own view template	No	No	Yes
Defined externally	No	No	Yes
Nestable	Yes	No	Yes

The rule of thumb: use groups for visual organization, collections for simple repeatable lists within a model, and blocks for reusable components shared across models or that need independent templates.

Content Architecture

The full content architecture in SleekCMS follows a layered hierarchy:

Page Model (routable container)
│
├── Scalar Fields
│   ├── Title (text)
│   ├── Meta Description (text)
│   └── Published Date (date)
│
├── Group Field
│   └── SEO Settings
│       ├── OG Image (image)
│       └── Canonical URL (text)
│
├── Reference Fields → Entry Models
│   ├── Author → Author Entry
│   └── Categories → Category Entry (one-to-many)
│
└── Dynamic Block Field (composable layout)
    ├── Hero Block
    │   ├── Heading (text)
    │   ├── Background (image)
    │   └── CTA Group
    │       ├── Label (text)
    │       └── URL (text)
    │
    ├── Content Block
    │   └── Body (rich text)
    │
    └── Testimonials Block
        └── Quotes (collection)
            ├── Quote Text (text)
            └── Author → Author Entry (reference)

Content flows from models (schema) to instances (data) to templates (presentation). The model defines what fields exist. The editor creates instances by filling in those fields. The site builder or API delivers the content in the shape the model defines.

Separation of Content and Layout

SleekCMS enforces a deliberate separation between content structure and visual presentation:

Models define data shape. A hero block model declares that a hero has a heading, a subheading, an image, and a CTA — but says nothing about how those fields render.

View templates define presentation. A hero block's view template determines the HTML, styling, and layout. The same block model could have different templates for different contexts or sites.

This separation means you can redesign a site without restructuring content, reuse content across multiple presentation layers, and give editors a clean, form-based experience that doesn't expose HTML or styling concerns.

Impact on the Editor Experience

Every modeling decision you make directly shapes what content editors see and do. This is worth considering intentionally:

The fields you add determine the form inputs editors interact with. A reference field becomes a dropdown. A boolean becomes a toggle. A collection becomes a repeatable item list.
The groups you create determine how the form is organized. Logical grouping reduces cognitive load and makes large models manageable.
The blocks you allow in a dynamic block field determine what layout options editors have. This is your primary lever for balancing flexibility (editors can compose freely) with governance (editors can only use approved components).
The required and validation rules you set prevent incomplete or malformed content from being published.

Well-modeled content makes editors faster and more confident. Poorly modeled content leads to workarounds, inconsistency, and support requests.

What's Next

Page Models — Routing, static pages, page collections, and dynamic block layouts.
Entry Models — Reusable data, references, and admin-only configuration.
Block Models — Composable components, nesting, and cross-model reuse.
Option Sets — Centralized key-value taxonomies for dropdown fields.
Field Types — Complete reference for every field type and its capabilities.