Documentation rots quietly. A feature gets renamed. A step changes, and the owner who wrote it leaves. The page that described it sits there looking authoritative. It is also becoming wrong. Nobody gets an alert. The first signal is usually a support ticket, or a reader who stops trusting the docs. A documentation audit is how you find the rot before your readers do.
Done well, an audit is not a vague feeling that the docs need work. It is a structured pass ending in a prioritized triage list: what to fix, what to merge, what to archive. The ranking comes from how much harm each problem is doing right now. This guide is that process: the checklist, how to prioritize, and which parts you should never do by hand.
What a documentation audit checks
Most of what goes wrong with docs falls into six dimensions. Audit each page against all six:
| Dimension | What you're checking | Red flag |
|---|---|---|
| Accuracy | Does it match the current product? | Steps that no longer work; renamed features |
| Freshness | When was it last updated? | Untouched for months while the product shipped |
| Coverage | Is anything missing or asked-about but undocumented? | Repeated support questions with no page |
| Consistency | Duplicated, contradictory, or drifting wording | The same procedure in three places, slightly different |
| Structure | Heading hierarchy, empty stubs, reachability | Orphaned pages, skipped heading levels, empty topics |
| Integrity | Links and references that still resolve | Dead links; references to deleted components or variables |
Accessibility belongs here too. Missing image alt text is a real defect, not a nicety. The useful split: accuracy and coverage need human judgment; freshness, consistency, structure, and integrity can be detected mechanically. Hold onto that split. It decides what you automate.
Why the once-a-year audit fails
The instinct is to schedule a big annual audit, grind through every page, and declare the docs clean. The problem is timing. A point-in-time audit is accurate the day you finish it. The day after, it starts decaying, because the product never stops changing. By the next quarter, a fresh crop of stale pages and broken references has accumulated. Nobody sees it until the next scheduled review digs it up. Continuous checks — the living documentation model — close that gap.
Content decay is not caused by negligence. It is a structural consequence of how software evolves. A feature updates and its page does not. A teammate leaves, and their section goes unowned. A new version ships and the old docs are never revisited. A component gets deleted and references to it remain. The challenge was never fixing these. It is knowing they exist. Most tools give you no signal until a reader complains. By then trust is already gone.
That splits the audit in two. The judgment-heavy checks (accuracy, coverage, tone) still warrant a periodic deep pass, ideally per release. The mechanical checks should run continuously. They surface problems the moment they appear instead of letting them pile up for a year.
The audit checklist: how to actually run one
This part is tool-agnostic. Run it the same way in a wiki, a docs-as-code repo, or a CCMS:
- Scope it. Audit one product area, not the entire library. "Everything" never gets finished; "the install and onboarding docs" does.
- Pull a content inventory. List every page in scope with its last-updated date, owner, and (if you have analytics) its traffic. The inventory is the audit's backbone. You cannot prioritize what you have not listed.
- Score each page against the six dimensions. Mark pass/fail per dimension. Be blunt: "accurate?" means would this get a reader into trouble if they followed it today?
- Triage by impact, not by ease. This is where most audits go wrong. People fix the easy, low-traffic pages first, because finishing them feels good. Sort the failures by harm instead.
- Decide fix / merge / archive per page. Not everything broken deserves a rewrite. Duplicated pages get merged to one source. Genuinely dead pages get archived, not left to confuse search.
Automate the parts a human shouldn't do by hand
4 of the 6 dimensions (freshness, consistency, structure, integrity) are mechanical. Hunting them by eye across hundreds of pages is exactly the work software should own. It is also the half that has to run continuously to stay true. This is what a CCMS with a content-health system automates, and how each maps to the manual checklist:
- Freshness → staleness flags. Every topic carries a last-updated signal: amber after 30 days untouched, red after 90. Filter to stale + published. That one click reproduces the highest-priority slice of the audit, with no spreadsheet.
- Structure → orphan and validation checks. Orphan detection finds topics that sit in no map. That is unreachable content, already forgotten. Structural validation catches skipped heading levels (H1 straight to H3), empty stubs, multiple H1s, and missing image alt text.
- Integrity → reference checks. Broken component references, links to deleted topics, and undefined variable tokens are flagged automatically. The gaps never reach the published site.
- Consistency → duplicate detection. Near-duplicate passages surface from content embeddings. The "same procedure in three slightly different places" problem becomes a list instead of a memory.
- Broken links and code → docs-as-tests. Outbound links get checked and code samples validated, on a schedule. These are the integrity checks that would otherwise rot between manual audits.
In Topicary these surface in three places. The Topics list carries per-topic indicators: 13 distinct checks across freshness, completeness, structure, integrity, accessibility, and style. An on-demand Validation panel runs every check across a map. Dashboard health cards count stale topics, empty topics, broken references, and undefined variables at a glance.
What still needs a human
Automation handles the mechanical half. It does not replace the auditor. It frees the auditor for the calls that need expertise:
- Is it actually correct? A page can be fresh, well-structured, and fully linked while describing a workflow that changed last week. Only a subject-matter expert can confirm accuracy. That makes getting real SME feedback the audit step no tool can do for you.
- Should this page exist at all? Coverage and redundancy are judgment calls. Software can tell you two pages are similar. It cannot tell you which one to keep. It cannot know the feature was sunset and the whole section is obsolete.
- Does it read well for this audience? Tone, framing, and whether a procedure is genuinely usable are human assessments.
This is the shift underway in the field. Products move faster, and AI drafts more of the first passes. The technical writer's job tilts from producing pages toward auditing, curating, and validating them. The mechanical findings are table stakes. The judgment is the value. Tooling earns its keep by making decay visible automatically. See why structured content is what makes this work.
The short version
- A documentation audit produces a prioritized triage list, not a vague sense that the docs need work.
- Check six dimensions: accuracy, freshness, coverage, consistency, structure, integrity (plus accessibility).
- Do not rely on the annual audit. A point-in-time pass is stale the next day. Run the mechanical checks continuously.
- Automate freshness, structure, integrity, and duplication; reserve human time for accuracy, redundancy, and whether a page should exist.
- Prioritize by impact: stale, published, high-traffic pages first.
Moving from periodic cleanups to continuous auditing needs one underlying capability: structured content with a health model on top. The short version of that is what a CCMS is.