Documentation rots quietly. A feature gets renamed, a step changes, an owner leaves, and the page that described it keeps sitting there, looking authoritative, slowly 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 isn't a vague "the docs need work" feeling. It's a structured pass that ends with a prioritized triage list: what to fix, what to merge, what to archive, ranked by 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 distinction, because 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 and decaying the day after, because the product never stops changing. By the next quarter, a fresh crop of stale pages and broken references has accumulated, invisibly, until the next scheduled review digs them up. Continuous checks — the living documentation model — close that gap.
Content decay isn't caused by negligence. It's a structural consequence of how software evolves: a feature updates but its page doesn't, a teammate leaves and their section goes unowned, a new version ships and the old docs aren't revisited, a component gets deleted but 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, and by then trust is already gone.
So the audit splits in two. The judgment-heavy checks (accuracy, coverage, tone) still warrant a periodic deep pass, ideally per release. The mechanical checks should run continuously, surfacing 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 whether you're auditing 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 can't prioritize what you haven't 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 they're satisfying. 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, and it's 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 and you've reproduced the highest-priority slice of the audit in one click instead of a spreadsheet.
- Structure → orphan and validation checks. Orphan detection finds topics that aren't in any map: unreachable content that's been 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, so the gaps never reach the published site.
- Consistency → duplicate detection. Near-duplicate passages are surfaced from content embeddings, so 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: the integrity checks that would otherwise rot between manual audits.
In Topicary these surface in three places: per-topic indicators on the Topics list (13 distinct checks across freshness, completeness, structure, integrity, accessibility, and style), an on-demand Validation panel that runs every check across a map, and dashboard health cards that 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 them 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, which is why getting real SME feedback is 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 can't tell you which one to keep, or that a whole section is obsolete because the feature was sunset.
- 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: as products move faster and AI drafts more 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).
- Don't 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.
If you're moving toward continuous auditing rather than periodic cleanups, the underlying capability is structured content with a health model on top, the short version of which is what a CCMS is.