Structuring content for reuse
The main promise of a What is a CCMS? is write once, publish everywhere. But reuse doesn't happen by accident — it requires structuring content so that pieces can be recombined without breaking.
Topics should be self-contained
A topic that says "as described in the previous section" only makes sense in one specific context. A topic that stands on its own — covering one concept, one procedure, or one reference entry — can appear in any Create and organize a map, in any order.
Write each Create and manage topics as if the reader might arrive there directly from search, a cross-reference, or a different map. Don't assume they've read anything else.
The "self-contained topic" principle is the most impactful structural decision you can make. Relative references like "as mentioned above" or "in the next section" break the moment a topic appears in a different map or at a different position in the hierarchy. Use explicit Link between topics instead.
When to extract a component
How component reuse works are for content that is **identical** across locations. The test is simple:
The text is the same everywhere (not just similar).
You'd need to change it in every location if the information changed.
It appears in three or more topics.
Good candidates: support contact blocks, security disclaimers, prerequisite lists, authentication setup steps, standard warnings.
If content is similar but varies by audience or context, use Conditions vs. variables instead. Components and conditions solve different problems — components share identical content, while conditions and variables adapt content per output.
When NOT to use a component
Content that appears in only two places — the indirection of a component may not be worth it.
Content that's similar but not identical — you'll end up fighting the component to make it work in every context. Use Create conditional content blocks for content that varies by audience, and Create variable sets for values that change per target.
Content that's unlikely to change — static content that never needs updating doesn't benefit from single-sourcing.
The "three or more places" guideline is a starting point, not a strict rule. A complex component that's used in only two places can still be worth extracting if the content changes frequently and accuracy is critical (e.g., pricing information or compliance language).
Structure topics for map flexibility
Create and organize a map control which topics appear and in what order. To get the most out of this:
One concept per topic. If a topic covers "Authentication" and "Authorization," split it. You might need them in different maps or different positions in the hierarchy.
Use descriptive titles. "Configure SSO with Okta" is better than "Configuration" — it's clear in any map context and useful when the topic appears in search results.
Avoid deep nesting in topic content. If a topic has five levels of headings, it's probably covering too much ground. Split it into multiple topics and let the map hierarchy provide the structure.
Naming conventions that scale
As your project grows past 50 topics, naming matters:
Content type | Naming pattern | Examples |
|---|---|---|
How-to | Start with a verb | "Create," "Configure," "Import," "Manage" |
Concept | Start with the subject | "How component reuse works," "The publishing pipeline" |
Reference | Start with the noun | "Editor slash commands," "Keyboard shortcuts" |
Consistent naming helps you find topics in the sidebar and helps readers predict what they'll find.
Use Classify content with tags alongside naming conventions to categorize topics by type (concept, how-to, reference), audience, or product area. Tags make it easier to find and organize content as your project scales beyond what naming alone can handle.
The reuse mindset
Reuse is iterative. You won't get the structure right on the first pass. A practical approach:
Write topics to cover your content needs.
Publish a web site and review.
When you spot identical content in multiple topics, extract it into a Create reusable components.
When you spot content that varies by audience, wrap it in a Create conditional content blocks.
When you spot values that differ per target, replace them with Use variable tokens in content.
Don't try to plan every component and condition upfront. Let usage patterns reveal the right abstractions.
See also
How component reuse works — the conceptual model behind components and references
Create and organize a map — build maps that take advantage of self-contained topics
Conditions vs. variables — choosing the right tool when content varies rather than repeats
Content health and governance — strategies for maintaining reuse quality as your project grows
Track content freshness — identify stale content that may need restructuring