Content Modeling in Optimizely
Why content modeling matters
Section titled “Why content modeling matters”A content model defines how your content is structured — what types of content exist, what fields each type has, and how types relate to each other. Get this right and your content is reusable across channels, easy for authors to manage, and ready for personalization and experimentation. Get it wrong and you end up with rigid page layouts, duplicated content, and expensive rework.
In Optimizely CMS, the content model is the foundation that everything else builds on: the editing experience, content delivery via Graph, personalization rules, and search indexing all depend on how you structure your content types and properties.
How content modeling works in Optimizely
Section titled “How content modeling works in Optimizely”Content types
Section titled “Content types”A content type is a blueprint that defines a kind of content. Think of it as a class definition — it specifies what fields (properties) are available when an author creates an instance of that type.
Optimizely CMS has three fundamental content types:
| Type | Purpose | Example |
|---|---|---|
| Page type | Represents a page with a URL in the content tree | Product page, Article page, Landing page |
| Block type | A reusable content component embedded within pages | Hero banner, Call-to-action, Testimonial card |
| Media type | Files and images stored in the asset system | Image, Video, PDF document |
Developers define content types in code. Authors create instances of those types in the CMS editor.
Properties
Section titled “Properties”Properties are the fields within a content type. Each property has a name, a data type, and editing metadata that controls how it appears in the editor.
Common property types include:
| Property type | Stores | Editor experience |
|---|---|---|
String | Short text (up to 255 chars) | Single-line text input |
XhtmlString | Rich text with formatting | Rich text editor (TinyMCE) |
ContentReference | Link to another content item | Content picker |
ContentArea | Ordered list of content items | Drag-and-drop area for blocks |
Url | External or internal link | URL picker |
Boolean | True/false value | Checkbox |
Int / Double | Numeric values | Number input |
DateTime | Date and time | Date picker |
SelectOne / SelectMany | Predefined choices | Dropdown or checkbox list |
[ContentType(
DisplayName = "Article Page",
GUID = "...",
Description = "A long-form article with author and publish date")]
public class ArticlePage : PageData
{
[Display(Name = "Headline", Order = 10)]
[Required]
public virtual string Headline { get; set; }
[Display(Name = "Body", Order = 20)]
public virtual XhtmlString Body { get; set; }
[Display(Name = "Author", Order = 30)]
public virtual string Author { get; set; }
[Display(Name = "Published Date", Order = 40)]
public virtual DateTime PublishedDate { get; set; }
[Display(Name = "Related Content", Order = 50)]
public virtual ContentArea RelatedContent { get; set; }
}query GetArticles {
ArticlePage(
orderBy: { PublishedDate: DESC }
limit: 10
) {
items {
Headline
Author
PublishedDate
Body
RelatedContent {
... on ArticlePage {
Headline
Url
}
}
}
}
}Blocks: composable content
Section titled “Blocks: composable content”Blocks are reusable content components that authors place inside ContentArea properties. They are the key to composable pages — instead of building monolithic page types with dozens of properties, you create small, focused block types and let authors compose pages by combining them.
Why blocks matter:
- Reuse — The same testimonial block can appear on multiple pages
- Flexibility — Authors build pages without developer involvement
- Consistency — Blocks enforce a structure, so content always looks right
- Headless ready — Blocks translate cleanly to component-based frontend frameworks
Content tree: hierarchy and navigation
Section titled “Content tree: hierarchy and navigation”All content lives in a tree structure, similar to a file system. The tree determines:
- URL structure — A page’s position in the tree defines its URL path
- Navigation — Menus are often generated from the tree hierarchy
- Permissions — Access rights can be set at any level and inherited downward
- Organization — Authors find and manage content by browsing the tree
Design principles for effective content models
Section titled “Design principles for effective content models”1. Separate content from presentation
Section titled “1. Separate content from presentation”Define what the content is, not how it looks. An “Article” type should have properties like Headline, Body, Author — not properties like HeaderBackgroundColor or ColumnLayout. Presentation decisions belong in templates and CSS.
This separation lets the same content render differently on a website, mobile app, email, and digital signage.
2. Prefer composition over inheritance
Section titled “2. Prefer composition over inheritance”Build pages from small, reusable blocks rather than creating large page types with many properties. A “Landing Page” with a single ContentArea and a library of block types is more flexible than a “Landing Page” with 30 fixed properties.
3. Model for the domain, not the design
Section titled “3. Model for the domain, not the design”Name content types after business concepts (Article, Product, Event), not visual layouts (TwoColumnPage, HeroBannerPage). Designs change; business concepts endure.
4. Plan for multichannel from the start
Section titled “4. Plan for multichannel from the start”If your content might be delivered through Graph to a headless frontend, structure it as discrete fields rather than a single rich text blob. Headless consumers can work with structured data; they cannot parse formatting out of HTML.
5. Consider the author experience
Section titled “5. Consider the author experience”Group related properties together. Use display names and descriptions that make sense to non-technical authors. Hide advanced properties in separate tabs. The content model directly shapes the editing experience — a well-designed model makes authoring intuitive.
Content modeling on SaaS vs PaaS
Section titled “Content modeling on SaaS vs PaaS”| Aspect | SaaS | PaaS |
|---|---|---|
| Content type definition | Code + Visual Builder | Code only |
| Block composition | Visual drag-and-drop canvas | ContentArea property (form-based) |
| Deployment of model changes | Push to cloud | Deploy application |
| Property types available | 26 (content editing & authoring) | 14 (CMS 13) / 25 (CMS 12) |
When to revisit your content model
Section titled “When to revisit your content model”Content models are not set-and-forget. Revisit your model when:
- New channels emerge — Adding a mobile app or headless frontend may require more granular properties
- Authors report friction — If authors routinely work around the model (e.g., putting structured data in rich text fields), the model needs refinement
- Personalization requirements grow — Personalization works best with structured properties that can be targeted and varied
- Performance degrades — Overly deep content trees or excessively complex types can impact editing and delivery speed
1. Why should you use blocks instead of adding more properties to a page type?
Blocks let content authors compose pages by combining reusable components. This avoids creating monolithic page types with dozens of properties that require developer changes for every layout variation.
Blocks let content authors compose pages by combining reusable components. This avoids creating monolithic page types with dozens of properties that require developer changes for every layout variation.
Review this topic →2. What is the most important reason to separate content from presentation in your content model?
Separating content from presentation means your content can be delivered to a website, mobile app, email, or digital signage — each with its own rendering — without duplicating the content itself.
Separating content from presentation means your content can be delivered to a website, mobile app, email, or digital signage — each with its own rendering — without duplicating the content itself.
Review this topic →3. When should you revisit your content model?
Content models should be revisited when authors work around them (e.g., putting structured data in rich text fields), when new channels require more granular properties, or when personalization needs grow beyond what the current model supports.
Content models should be revisited when authors work around them (e.g., putting structured data in rich text fields), when new channels require more granular properties, or when personalization needs grow beyond what the current model supports.
Review this topic →