What you will learn in this article

• How entity-centric content modeling makes content reusable across pages, sites, channels, and AI-powered experiences.

• Why separating content from presentation prevents duplication and allows designs to change without rewriting content.

• How atomic fields, relationships, taxonomies, and metadata create structured content that is easier to find, manage, and repurpose.

• How dotCMS supports reuse through Content Types, Containers, APIs, relationships, and shared multi-site content.

• Why naming conventions, documentation, and governance are essential for preventing content-type sprawl and maintaining a reliable source of truth.

• How the dotCMS Content Style Editor lets authors customize each placement’s appearance without changing the underlying content or requiring ongoing developer support.

Most content created by a team has more potential uses than the single place it is first published. An article written for a blog can also power a mobile app, an email campaign, a partner microsite, or a search and AI-retrieval experience, all without additional authoring effort. Whether a team can realize that potential depends less on which tools it uses than on how the content was structured when it was first created.

Content modeled around the entity it represents — a Person, a Promotion, a Product, an Article — retains its structure and meaning regardless of where it is placed. Content modeled around a specific page inherits the assumptions built into that page, such as its layout, its audience, and its position within a template, and those assumptions will be undone manually every time the content is needed somewhere new. The practical difference is when the work happens: a well-modeled content type requires a set of decisions made once, before content entry begins; a poorly modeled one requires rework on every record, each time a new use case appears.

This guide describes those decisions: a set of best practices for modeling content so that it can be placed on additional pages, delivered through additional channels, and shared across additional sites, without requiring a developer to rebuild it for each new context. The principles themselves are not specific to any one CMS. They appear, under different names, in headless CMS documentation, in technical writing practice (DITA and single-sourcing), and in enterprise content strategy (Component Content Management). Each practice below includes a concrete example of how to apply it in dotCMS.

The guide then covers a second, related topic: once content is modeled for reuse, authors still need a way to adjust how a reused component looks in each new placement, since a component styled for one context rarely fits another without some adjustment. dotCMS's Content Style Editor addresses this directly and is best understood as a complement to a well-modeled content type rather than as a separate, unrelated editing feature.

Why this matters: multiplying the value of every piece of content

The approach this guide describes has an established name in content strategy: modeling content as entity-centric rather than page-centric. An entity-centric model represents "the Person" rather than "the About page," or "a Promotion" rather than "the Homepage hero." Because the entity's definition does not reference any particular page, it can be placed in any relevant context without being duplicated or re-templated, and without producing multiple versions of the same information that can drift out of sync.

The distinction is not new — it underpins the "create once, publish everywhere" approach that NPR's engineering team popularized when it rebuilt its publishing systems around display-agnostic content structures — but the pressure to adopt it has increased sharply as content is consumed by systems other than web browsers. Writing in CMSWire in 2026, Ashutosh Kachot argues that content modeled as entities, meaning distinct objects with defined attributes, queryable relationships, and contextual metadata, is what allows AI systems to interpret and act on information, while page-centric models optimize for rendering and leave those relationships implicit.

The same shift shows up in how the platform category itself is described. CMSWire's 2026 guide to digital experience platforms identifies the move "from web-focused, page-based monolithic content to atomic and reusable content" as a defining capability requirement, alongside extensible content types and multi-site, multi-channel delivery.

In headless CMS practice, the discipline that produces this outcome is generally called content modeling: decomposing content into modular, reusable content types and fields, and doing so deliberately, before content entry begins, rather than allowing the model to be defined implicitly by whatever the first page happened to need. The practices below describe how to apply that discipline in specific, actionable terms.

Best Practice 1 — Model entities, not pages

The principle: Before creating a content type, identify what kind of thing it represents, rather than what page it will appear on. A blog post is an instance of an Article entity. A person quoted within it is an instance of an Author entity. A statistic cited within it could be modeled as its own Fact or Statistic entity. Each of these has an identity independent of any particular page; a page displays entities, but does not define them.

Why it enables reuse: If a content type is defined by the page it appears on — a "Homepage Hero Block," for example — reusing it elsewhere requires copying its definition and modifying that copy to fit the new context. If it is defined by what it represents, such as a "Promotion," the same Promotion entity can be placed on the homepage, a category page, an email, or a partner site, because none of those placements is part of its definition. This is the practical difference between a model built for rendering and one built for interpretation and reuse.

In dotCMS: Content Types are created independently of any page via the Content Types portlet, specifically so the content isn't tied to a single page's lifecycle. A "Blog" content type, for example, is built from fields like Title, Teaser, Body, Author, Tags, and Categories — nothing in that definition references a specific page or template. The same Blog entry can then be placed on a blog listing page, a homepage "featured articles" widget, a category page, or delivered to a mobile app via the Content API, from one definition.

Best Practice 2 — Separate content from presentation, completely

The principle: A content record should describe what the content is, not how it looks: no inline styling, no hardcoded HTML layout, and no font or color choices stored as part of the content itself. This is one of the oldest principles in information architecture — the same one that gave the web HTML for structure and CSS for presentation — and it remains part of the current accessibility standard. W3C's WCAG 2.2 technique G140 describes the objective as logically separating a document's structural encoding from its presentational encoding, on the grounds that presentational formatting only implies structure visually and does not encode it in a way other systems can reliably interpret.

Why it enables reuse: If how content looks is part of the content record, every new context that needs a different look requires either a new field (which leads to content-type sprawl) or a duplicate copy of the content. If the presentation is kept entirely outside the content record, the same content can be displayed differently in each placement without the content record being touched. As NN/g's Anna Kaley notes, this separation is also what makes content resilient to interface change: the content stays stable while the visual design and delivery channel are adjusted independently, rather than having to be recreated whenever the UI changes.

In dotCMS, this shows up architecturally in the separation between Content Types (data), Containers (what content types can appear where, and in what format), Templates (page layout), and Themes (a site's shared look-and-feel — CSS/JS/Velocity files that can be swapped without touching a single piece of content). A blog post's Content Type has no opinion about whether it renders with a sidebar or full-width; that's a Template and Theme decision made independently. This is also the architectural principle that the Content Style Editor (covered in Part 2) is built to preserve: it keeps presentation choices out of the content record even while giving authors control over them.

Best Practice 3 — Decompose into atomic, structured fields — not one text blob

The principle: A content type consisting of a single large rich-text field provides little more structure than an unformatted document: every consuming system receives an undifferentiated block of HTML that it has to parse itself in order to extract anything usable. Breaking content into its smallest meaningful, independently addressable parts — title, summary, body, author, date, image, tags, each as its own field of the appropriate type — allows each part to be retrieved, validated, and displayed on its own. The logic mirrors Brad Frost's atomic design methodology for user interfaces, in which individual elements compose into components and then into larger interface sections; applied to content rather than markup, fields correspond to the smallest units and content types to the components assembled from them.

Why it enables reuse: A consuming channel, whether a mobile application, a search index, an AI retrieval system, or a partner feed, can only make use of the parts of a piece of content that it can address individually. If an author's name is written as part of a sentence inside a body paragraph rather than stored in its own field, no consuming system can reliably extract it. In practical terms, structuring content into discrete fields is what allows key information to live in defined fields with queryable relationships, rather than being locked inside prose that each consumer has to interpret for itself.

In dotCMS: The Content Types portlet ships dedicated field types for exactly this purpose — Text, Textarea, Date-and-Time, Select, Radio, Category, Tag, Relationship, Image, and the Block Editor (a structured JSON rich-content field, rather than raw HTML) — so a content architect chooses the right atomic type for each attribute instead of defaulting to one WYSIWYG field for everything. The dotCMS "Blog" content type is a working example: Title (Text), Teaser (Textarea), Body (Block Editor), Author (Relationship — see Best Practice 4), Tags (Tag field), and Categories (Category field) are all separately addressable, separately queryable, separately displayable, and separately reusable.

Best Practice 4 — Reference, don't duplicate

The principle: If the same information needs to appear in more than one place — an author's bio on every article they've written, a product spec on every page that mentions the product — model it once as its own entity and reference it, rather than re-entering or copying it everywhere it's needed. This is the same mechanic that structured authoring standards such as DITA formalize as single-sourcing: content components are reused across documents by reference, so an update to the source propagates to every place it is used.

Why it enables reuse: Copied content diverges from its original as soon as either copy is edited independently of the other. In an organization with, for example, a dozen pages referencing the same author bio, an update applied to only some of those pages leaves the rest out of date, and there is no way to tell from the content itself which version is current. This is not only an internal housekeeping problem: Content Marketing Institute's 2026 analysis of content governance describes distributed teams producing overlapping, unsupervised versions of the same information as a primary source of brand inconsistency, and identifies a shared source of truth as the corrective. A referenced entity has exactly one source of truth: every place that references it reflects an edit as soon as that edit is published, because there is only one underlying record.

In dotCMS: this is what the Relationship field type is for. Instead of a free-text "Author Name" field on every Blog entry, the Blog content type relates to an Author content type (with its own fields — name, bio, headshot, social links). Updating the Author's bio once means every Blog post related to that Author reflects the change on next render, without any of those articles being re-edited individually. The same pattern applies to product specs, legal disclaimers, or any fact that's genuinely singular but referenced in many places.

Best Practice 5 — Design content types to be channel-agnostic

The principle: A content type should not assume it will only ever be rendered as an HTML page. A model that follows the preceding practices — an entity-based structure (Best Practice 1), atomic fields (Best Practice 3), and no embedded presentation (Best Practice 2) — can generally be consumed as-is by a website, a native mobile application, a voice assistant, a partner's API integration, or an AI system performing retrieval, because each of these consumers reads the underlying data rather than any particular HTML rendering of it.

Why it enables reuse: A content model designed around a single rendering path, such as one specific page template, has to be restructured as soon as a second channel needs to consume the same content. A channel-agnostic model does not require that restructuring, because it was not built around any single rendering path as an assumption in the first place. Google's own guidance for AI-driven search surfaces makes the same point from the consuming side: content should carry machine-readable structured markup and be prepared to appear across multiple surfaces rather than a single page rendering.

In dotCMS, every Content Type is automatically exposed over the Content REST API and GraphQL API, in addition to being renderable on traditional (VTL) pages. The same blog content used on a dotcms.com-style website page can be queried directly by a headless front end (Next.js, Angular, a mobile app) via the same underlying content record — there's no separate "headless version" of the content to maintain. This is the mechanical reason dotCMS blog content describes structured content as enabling content to be "reused, revised, and shared across various platforms without requiring manual copy-pasting."

Best Practice 6 — Use taxonomies and metadata to drive dynamic reuse

The principle: Manually placing a piece of content wherever it needs to appear works while a site has a small number of pieces of content and a small number of placements. Past that scale, reuse needs to happen automatically: content should be discoverable and placeable based on what it is — its tags, categories, and type — rather than requiring an editor to remember to add it somewhere. Metadata is what makes that possible, and its role has grown as content is consumed by retrieval and AI systems in addition to page templates; CMSWire's 2026 review of the component content management category describes modular, consistently tagged, semantically enriched content as the precondition for reliable automated reuse and retrieval.

Why it enables reuse: Reuse driven by tags or categories means new content becomes reusable as soon as it is tagged correctly, without requiring an editor to manually place it in every relevant location. A "related articles" widget that queries content by tag will automatically include next month's new articles that carry that tag; a widget populated through manual curation will not.

In dotCMS, the Tag and Category field types exist for exactly this purpose. A widget or query on a page can pull "all Blog content tagged personalization" or "all Case Studies in the Financial Services category" dynamically — the underlying content doesn't need to know, in advance, every place it might eventually surface. dotCMS also auto-suggests existing tags from a shared Tag Pool as authors type, which keeps the taxonomy consistent enough for these queries to remain reliable over time.

Best Practice 7 — Standardize how content types render, so the same type can look different in different contexts

The principle: The same entity often needs more than one visual treatment — a summary card in a listing, a full layout on its detail page, a compact version in a sidebar widget. That's a rendering decision, not a content-modeling decision, and it should be handled as a swappable rendering rule rather than by creating multiple near-duplicate content types for the same entity.

Why it enables reuse: If "the compact version" and "the full version" are modeled as two different content types, they diverge immediately: an edit to one does not affect the other, producing two sources of truth for what should be a single entity. Handling this at the rendering layer keeps exactly one content record while still allowing multiple presentations of it.

In dotCMS, this is the specific job of Containers. A Container determines which Content Types are allowed inside it, and how each type renders inside that particular Container — so the same Content Type can have a "detail" Container on an article page and a "summary" Container on a listing page, without the underlying content record changing at all. Containers are themselves reusable across Templates, so a "Blog Summary" Container built once can be dropped into any Template that needs a blog-teaser layout.

Best Practice 8 — Plan for reuse across sites, not just across pages

The principle: Everything above addresses reuse within a single site. Organizations running multiple brands, regional sites, or partner microsites on one platform need a further decision: which content is genuinely global (a company boilerplate, a shared legal disclaimer, a common CTA), and which is intentionally site-specific. That decision should be made explicitly in the content model, rather than left to whichever editor happens to need the content next. Multi-site, multi-channel, and localization support are treated as baseline platform capabilities in current market analysis, which makes the modeling decision, rather than the platform capability, the limiting factor for most organizations. (CMSWire, "Digital Experience Platforms (DXPs): Your 2026 Comprehensive Guide", January 2026)

Why it enables reuse: Without a designated shared layer, cross-site reuse defaults to copying content per site, the same content-drift problem described in Best Practice 4, at a scale where it is considerably more expensive to correct later.

In dotCMS: every site is an instance of the Host Content Type, and dotCMS provides a dedicated global content store — the System Host — for content that should be available to every site on the same instance. A content record with a Site-or-Folder field can be assigned to a specific host (site-specific), or the System Host (globally shared). A shared "Author" entity or a standard CTA block used across a company's regional sites is a natural fit for the System Host: it is defined once, reused on every site on the instance, and edited once when it needs to change.
(Not every content type can live on the System Host — Pages, Templates, Containers, and file-based assets are scoped to a specific site by design; for those, a dedicated shared-content host with appropriate cross-site permissions is the usual approach.)

Best Practice 9 — Govern the model: naming, documentation, and resisting type sprawl

The principle: A content model tends to degrade gradually, through an accumulation of individually convenient but uncoordinated additions: a one-off field added for a single campaign, a near-duplicate content type created because the existing one was hard to find or understand. Clear naming conventions, documentation of what each content type and field is for, and a preference for extending an existing type over creating a similar new one, are what keep a model reusable years after launch rather than only at launch. Governance is what produces the shared source of truth that distributed teams can work from.

Why it enables reuse: A field named field7 or a content type named Blog2 cannot be reused safely by a new team member, since its purpose is not evident from its name; the more likely outcome is that the team member creates a third, similar content type rather than risk modifying something they do not understand. Content models that are documented and consistently named are more likely to be reused as intended, rather than worked around. Governance controls such as schema validation, review, version control, and audit trails serve the same end, and become more rather than less important as content production is partly automated.

In dotCMS: the Content Types portlet supports descriptive labels, help text, and a JSON view of the full content type schema that can be exported as living documentation. Practically: before building a new Content Type, check whether an existing one, extended with a new field, already covers the need, and keep a written record — even a simple one — of what each Content Type and Relationship is meant to represent. This is a matter of process discipline rather than a specific feature, but it is the practice that determines whether the preceding practices continue to hold up over time.

Part 2 — The Style Editor: extending reuse from content into presentation

The practices described above address the content side of reuse. A separate issue remains even for a well-modeled content type: the same content can be placed in a new context and be structurally correct but visually wrong for it, because the new placement calls for different styling — a different background color, different spacing, or different text alignment — than the original placement. Historically, there have been two ways to address this:

1. Add a presentation field to the content type, such as backgroundColor or fontSize. This works, but works against Best Practice 2, since it moves presentation decisions into the content record, and against Best Practice 9, since each new styling need tends to produce another one-off field.

2. Submit a request and wait for a developer to implement the specific variant in code.

Both approaches carry a cost: the first degrades the content model over time, and the second reintroduces the dependency on development work that modeling for reuse is intended to reduce. The dotCMS Content Style Editor addresses this by giving content authors direct style control over an individual placement of a component, without adding fields to the content type and without requiring a developer to write code for each new variant.

What it is

The Style Editor is a feature inside the dotCMS Universal Visual Editor (UVE). A small style icon appears over any styleable component in the editor; clicking it opens a panel of style controls — defined per Content Type — that an author can adjust directly: typography, layout, background colors, borders/shadows, responsive behavior, and more, depending on what you choose to expose. Changes apply immediately, with no CSS knowledge required and no developer ticket. It works on both traditional (VTL) dotCMS pages and headless front ends served by an external application.

How it's configured

The design detail that matters here is where the style options are defined: in a schema attached to the Content Type itself, separate from the content type's fields, and separate from any front-end application code. This is what avoids reintroducing the field-sprawl problem described in Best Practice 9.

To configure it:

1. Open the Content Types portlet and open the Content Type to configure.

2. Select the Style Editor tab.

3. Add one or more Sections — visual groupings in the editor pane (e.g., "Typography," "Layout"). Sections are UI-only; they aren't stored on the content.

4. Add Fields to each section — the actual style controls. There are four field types:

   • Text — free text or numeric entry (e.g., a specific pixel value)

   • Dropdown — single-select list (e.g., font size presets: S / M / L / XL)

   • Radio — single-choice set, optionally with an image preview per option (e.g., layout thumbnails)

   • Checkbox Group — independent toggles an author can combine (e.g., bold / italic / underline)

Changes to the schema take effect immediately on any page containing that Content Type — no deployment, no code change.

How the values are stored and used

When an author makes selections, they're saved to the contentlet as a flat object under a single property: dotStyleProperties. This keeps the content record clean: the style choices are stored alongside the content but namespaced separately from its actual fields, and a field the author never touches simply does not appear in the object.

Developers read this value wherever the component is rendered:

• On traditional dotCMS pages (Velocity/VTL):

$dotContentMap.dotStyleProperties.fontSize
$dotContentMap.dotStyleProperties.orientation

(Identifiers containing hyphens need map-access syntax: $dotContentMap.dotStyleProperties['title-size'].)

• On headless front ends (React, Angular, etc.), via the dotCMS SDK:

function BlogPost({ title, body, dotStyleProperties }) {
    const fontSize = dotStyleProperties?.['font-size'] || '16px';
    const layoutClass = `layout-${dotStyleProperties?.layout || 'default'}`;

    return (
        <div className={layoutClass} style={{ fontSize }}>
            <h1>{title}</h1>
            <p>{body}</p>
        </div>
    );
}

The schema itself never has to be defined in front-end code — the SDK fetches it automatically from the admin-configured schema. A front-end developer's job is limited to a single setup pass: deciding, together with design and content stakeholders, which properties should be author-controllable, then writing the handful of lines of component code that map each stored value to a CSS property or class. After that one-time setup, every future style adjustment is an author action rather than a developer task.

A concrete example: why this increases reuse, not just convenience

Take a Promo Banner Content Type — headline, body text, a CTA link, an image — modeled according to the practices described above: it is an entity (a Promotion), its content is separated from presentation, its fields are atomic, and it is exposed for reuse across pages and, via the System Host, across sites.

Marketing wants to place the same Promo Banner contentlet in three places this quarter: the homepage hero (large, centered, bold background), a category page sidebar (compact, left-aligned, subtle background), and a partner site running the same platform (matching that partner's brand color rather than the parent brand's). Before the Style Editor, this required either three separate near-duplicate Promo Banner records, which breaks the single-sourcing described in Best Practice 4, or three development tickets for hardcoded variants.

With a Style Editor schema configured on the Promo Banner Content Type — a Typography section (heading size), a Layout section (alignment), and a Background section (color swatch dropdown) — the same underlying contentlet is placed in all three locations, and each placement gets its own style selections. This behavior is documented directly in dotCMS's SDK reference: the same contentlet, placed in different Containers or on different pages, can carry distinct, independently saved styles for each placement, while an edit to the underlying content itself, such as updating the CTA copy, still propagates to every placement, because every placement references the same underlying content record.

Summary

Model content for reuse first. This means modeling entities rather than pages, structured fields rather than large text blocks, references rather than duplicated copies, taxonomies rather than manual placement, and a shared content layer for anything genuinely used across sites—with deliberate governance to keep the model usable as it grows.

Give authors independent style control over each placement, separate from the content model. Without this, content may be technically reusable while every new placement still requires a developer to make it fit. The Content Style Editor removes that bottleneck by keeping style choices separate from both the content and front-end code.

Together, these practices reduce duplicate work, development requests, and the cost of launching new pages, campaigns, sites, and channels. Content teams can move faster and adapt existing material themselves while preserving consistency and a single source of truth. Each piece of content can deliver value in more places, increasing its useful life and improving the return on the effort invested in creating it.