Structuring content for reuse
The main promise of a What is a CCMS? is write once, publish everywhere. But reuse does not happen by accident. It requires structuring content so that pieces can be recombined without breaking.
Reusable How component reuse works require the Business Plans and limits. The topic-structuring advice on this page applies on every plan; component extraction is the Business-tier part.
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. Do not assume they have 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. 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 would need to change it in every location if the information changed.
It appears in 3 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 versus variables instead. Components and conditions solve different problems: components share identical content, while conditions and variables adapt content for each output.
When not to use a component
Content that appears in only 2 places. The indirection of a component may not be worth it.
Content that is similar but not identical. You will 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 for each target.
Content that is unlikely to change. Static content that never needs updating does not benefit from single-sourcing.
The "3 or more places" guideline is a starting point, not a strict rule. A complex component that is used in only 2 places can still be worth extracting if the content changes frequently and accuracy is critical (for example, 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 for each 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 is clear in any map context and useful when the topic appears in search results.
Avoid deep nesting in topic content. If a topic has 5 levels of headings, it is 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 will 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 will not 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 for each target, replace them with Use variable tokens in content.
Do not 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 versus 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