Structured authoring writes content as semantically typed, reusable blocks that are separated from presentation; unstructured authoring writes free-form documents where content and formatting live together in one file. The difference shows up the moment something changes. In a structured system, you edit one component or one variable and every reference updates. In an unstructured system, you find and replace across every affected document by hand, and you hope you caught them all.
This guide defines both approaches with a concrete example of each, gives you a decision framework you can actually score against your own team, and is honest about what migration costs. The information gain over a typical definition page is the migration section: what transfers cleanly, what is manual editorial work no importer can do for you, and where the "supports DITA import" checkbox stops mattering.
The core difference
Structured authoring separates what content means from how it looks, and stores the meaning. A warning is marked as a warning, a procedure step is marked as a step, a cross-reference is a typed link to another topic. Presentation is applied at publish time, so the same source can render as a styled callout on a web page, a boxed note in a PDF, and a blockquote in Markdown. Reuse, conditions, and variables all become possible because the system understands the parts, not just the paragraphs.
Unstructured authoring stores appearance directly. A warning in a Google Doc is a paragraph with a yellow background that you applied by hand. Rename your product and you edit every document that mentions it. Change a procedure that appears in three guides and you edit it in three places, or you forget the third and it drifts. The document is the unit of work, and each document is a standalone artifact with no knowledge of the others.
What each looks like in practice
Unstructured: one document, everything inline
A "Getting started" guide written in Confluence or Google Docs is a single page. Installation steps for Windows, macOS, and Linux sit inline, one after another, with a note above each telling readers to skip the ones that do not apply. The product name is typed literally in 30 places. The supported-versions table is copied from the release-notes page and is already one version out of date. When the product is renamed, someone runs find-and-replace across 40 pages, misses the ones in image captions and table cells, and the old name survives in the corners of the docs for a year.
This is fast to start and cheap to learn. Anyone can write a Confluence page. The cost is deferred, and it arrives as drift: the same information in multiple places, slowly disagreeing with itself.
Structured: topics, components, conditions, variables
The same content, authored structurally, is a set of topics arranged in a map. The system-requirements block is a single component referenced by five topics; edit it once and all five update. The platform-specific installation steps are tagged with an os condition, so the published Windows guide shows only Windows steps and the PDF for macOS shows only macOS steps. The product name is a {product_name} variable. Renaming the product is one edit followed by a republish, and the new name appears everywhere, including the captions and the table cells.
The setup cost is real. You decide what becomes a component, what gets a condition, and what becomes a variable, and that takes editorial judgment. The payoff scales with reuse and channels: the more places a piece of content appears, the more a single source saves you. Modern tools, including structured authoring without XML, keep this model under the hood and give writers an ordinary block editor on top.
Structured vs unstructured - a comparison
| Dimension | Unstructured authoring | Structured authoring |
|---|---|---|
| Unit of work | The document | The topic and the component |
| Reuse | Copy and paste; copies drift independently | Reference a component; edit once, every use updates |
| Audience or platform variants | Separate documents, or inline notes telling readers what to skip | Conditions tag blocks and filter at publish time |
| Changing values (names, versions, URLs) | Find and replace across every file | Variables resolve at publish; change once |
| Output channels | One document per output; reformat by hand for each | One source renders to web, PDF, and Markdown |
| Consistency | Depends on author discipline | Enforced by the publishing pipeline |
| Setup cost | Near zero; anyone can start today | Days to weeks, plus a learning curve |
| Best fit | 1-2 authors, under ~100 pages, one channel, low reuse | Reuse-heavy, multi-channel, multi-audience, or localized content |
Structured authoring is a spectrum, not a switch
The common mistake is treating structured authoring as binary: either you write DITA XML in an enterprise CCMS or you write free-form docs, with nothing in between. There is a spectrum of depth, and most small teams belong somewhere in the middle.
At the shallow end is plain Markdown in a Git repository: formatting semantics, but no reuse, conditions, or variables. One step deeper is docs-as-code with a static-site generator that adds includes and build-time conditionals, such as AsciiDoc with Antora or reStructuredText with Sphinx. This gives real reuse and single-sourcing to teams comfortable with a build pipeline. Deeper still is a lightweight CCMS with topic-based authoring, component reuse, conditions, and variables in a visual editor. At the far end is full DITA with a specialization model and an open toolchain, which pays off at org scale and is heavier than a small team needs.
Choosing an approach is really choosing a point on this spectrum. The question is not "structured or not" but "how much structure earns its keep for the content I actually maintain."
When unstructured authoring is the right call
Unstructured authoring wins when your content is narrative, one-off, or single-channel. A blog. A README. An internal wiki that one team reads. Release announcements. Marketing pages. In these cases each output is a distinct work product rather than one source rendered to multiple channels, so there is nothing to single-source and no reuse to capture. The overhead of components, conditions, and a publishing pipeline buys you nothing, and it slows down writers who just need to publish a page.
It also wins early, before scale. A two-person team maintaining 40 pages that publish to one help center will move faster in Confluence or Notion or Markdown than in any structured tool, because manual coordination across 40 pages is cheaper than learning and setting up a structured system. The break-even arrives later, and paying the structured-authoring tax before you hit it is a common way to slow a small team down for no return.
When to move to structured authoring
Move to structured authoring when reuse, audience variants, or output channels start multiplying your maintenance work faster than your content grows. Score your situation against this checklist. Three or more strong yeses means the manual cost is already exceeding the tool cost.
- Reuse: Is the same passage (a warning, a prerequisite, a setup step) copied into more than five topics? Each copy is a future drift.
- Audience or platform variants: Do you maintain separate documents for platforms, plans, editions, or regions that share most of their content?
- Multiple output channels: Do you publish the same content to more than one place, such as a help center and a downloadable PDF and in-app help?
- Changing values: Do product names, version numbers, or URLs appear literally in dozens of places, so a rename is a manual sweep?
- Localization: Do you translate into other languages? Duplication multiplies the translation bill, because every copy is a separate string to translate.
- Team and volume: Do you have more than two writers or more than 100 topics, where coordination by discipline alone starts to fail?
Content reuse and single source publishing are the two capabilities that pay for the switch. If neither applies to your content, stay unstructured.
The migration cost nobody quotes
Import moves the raw content. Structuring is manual editorial work that no importer can do for you, and this is the line most tool comparisons skip. Understanding it is the difference between a two-day migration and a two-month one.
From unstructured sources, the text transfers and the structure does not. Word, Confluence, and Markdown importers bring across headings, lists, tables, images, and basic links with hierarchy preserved. What they cannot bring across is judgment: which repeated passages should become shared components, which blocks should carry conditions, which literal values should become variables, and how to split a 4,000-word monolithic page into discrete topics. Those are human decisions, made block by block, after the import lands.
From structured sources, the structure survives the move. DITA import maps conrefs to components and preserves conditions and map hierarchy. A MadCap Flare migration brings topics, snippets as reusable components, the TOC as a map, plus variables and conditions. Moving between structured systems is a genuine content transfer; moving from an unstructured system is a transfer plus a re-authoring project.
A realistic migration follows this order:
- Inventory and deduplicate. List your pages and find the passages that repeat. These are your component candidates.
- Import the raw content. Bring the text, headings, tables, and images into topics.
- Split monoliths into topics. Break long pages into topics that each cover one concept, task, or reference.
- Extract components. Turn the repeated passages from step 1 into shared components and reference them.
- Tag conditions. Mark platform-, plan-, or audience-specific blocks so the pipeline can filter them.
- Replace literals with variables. Swap hardcoded product names, versions, and URLs for variables.
- Rebuild cross-references. Convert bare links into typed topic links that resolve per channel at publish.
- Publish and diff. Render every channel and compare against the old output to catch anything lost in translation.
Steps 1 and 3 through 6 are the expensive ones, and they scale with how messy the source content is, not with page count alone. Budget for editorial time, not just an import button.
Non-product alternatives
If you decide structured authoring fits, you have real choices that are not Topicary, and an honest guide should name them. For the XML route, DITA with Oxygen XML Editor and the DITA Open Toolkit is the mature, open, industry-standard stack; it is powerful and heavier than most small teams need. For docs-as-code teams, AsciiDoc with Antora or reStructuredText with Sphinx delivers reuse and single-sourcing through a build pipeline. Among hosted CCMS tools, Paligo and Heretto target structured authoring for larger documentation teams, and MadCap Flare is the long-standing desktop option. If you conclude unstructured is right, Confluence, Notion, Google Docs, and plain Markdown in a repo all do that job well.
Where Topicary fits
Topicary is a structured authoring tool built for solo writers and small teams that want the model without the XML. It gives you topic-based authoring in a block editor, block-level and paragraph-level component reuse with where-used tracking, conditional content with an in-editor preview, variable sets, and single-source publishing to web, PDF, and Markdown from one source. It imports seven formats (Markdown, HTML, Word, DITA, Confluence, Flare, and OpenAPI), so testing migration with your real content is cheap.
Being honest about the edges: Topicary does not do git-style content branching, component forking to an editable copy, per-instance variable overrides, or release management, and there is no glossary or back-of-book index. If your team needs those, a heavier DITA-based CCMS is a better fit. Pricing is Free (1 author, 10 topics, 1 site), Pro at $79/month (3 authors, unlimited topics, 3 sites, AI, PDF, import), and Team at $149/month (10 authors, 10 sites, plus branding and analytics), which sits below the enterprise CCMS tier by design.
Frequently asked questions
What is the difference between structured and unstructured authoring? Structured authoring writes content as semantically typed, reusable blocks separated from presentation, so one source renders to every channel and one block can appear across topics. Unstructured authoring writes free-form documents where content and formatting live together and each document stands alone. The practical test is a product rename: one variable edit in a structured system versus a find-and-replace sweep in an unstructured one.
Is Markdown structured or unstructured authoring? Plain Markdown is closer to unstructured. It carries formatting semantics but has no components, conditions, or variables, so each file is a standalone document. Teams that build structured workflows on Markdown extend it with frontmatter, build-time includes, and custom directives, which makes it a lightweight structured system rather than raw Markdown.
When should a small team switch to structured authoring? When a countable cost is hurting: the same block copied into more than five topics, separate platform or plan variants drifting apart, publishing the same content to more than one channel, or localizing into other languages. Below roughly 100 topics with one channel and one or two writers, unstructured authoring is usually faster.
What does it cost to migrate from unstructured to structured authoring? Import moves the text, headings, tables, and images; extracting components, tagging conditions, adding variables, and splitting monolithic pages into topics is manual editorial work. Migrating from DITA or MadCap Flare is easier because conrefs, snippets, and conditions map across, so the structure survives rather than being rebuilt.
Do I need DITA to do structured authoring? No. DITA is one implementation of structured authoring, not a prerequisite. Typed topics, reuse, conditions, and variables can all be authored in a block editor with no XML. DITA still wins when you need its specialization model or org-scale single-sourcing.
Can you mix structured and unstructured authoring? Yes, and most teams do. Structured authoring suits reference and procedural docs that reuse heavily and publish to multiple channels; unstructured tools suit one-off narrative content like blog posts and internal wiki pages. Structure is a spectrum of depth, not an all-or-nothing switch.