Content Audit for Documentation: Find and Fix Stale Docs

Most documentation sites are not short of content. They are short of trustworthy content. Topics written for a release two years ago still rank in search. Three pages explain the same setting in three slightly different ways. A support agent finds the right answer, but only after skipping two wrong ones.

A content audit is how you fix that on purpose instead of by accident. This guide walks you through a practical content audit built for documentation teams: what to collect, how to judge each topic, what to do with the results, and how to keep your docs from drifting out of date again.

What is a content audit?

A content audit is a structured review of every piece of content you publish, judged against clear criteria, so you can decide what to keep, update, merge, or retire. It starts from a content inventory, which is a list of everything you have. The audit is where you judge the quality of each item on that list.

Think of the two this way. The inventory is a living list you keep up to date. The audit is the review you run against it, again and again. Together they shift your team's focus from how much documentation you have to how good it is.

Why documentation needs a content audit now

Outdated docs used to cost you a frustrated reader and maybe a support ticket. Today they also feed the tools your customers ask for answers.

In a June 2026 survey of 109 technical communicators by the UK consultancy Cherryleaf, 39% said AI systems already draw on their user documentation. Another 36% said such systems were planned or in development. An AI assistant can only be as accurate as the pages it reads. If a topic describes a menu that no longer exists, the assistant will describe it too, with full confidence.

Search works the same way. Google's guidance for its AI features says there are no special optimizations needed to appear in them. The same fundamentals apply: helpful, reliable, people-first content that is easy to find. For documentation, "reliable" mostly means "current." A content audit is the most direct way to get there.

How to do a content audit, step by step

Step 1: Set a goal and a scope

Decide what you want the audit to change before you open a spreadsheet. Common goals for documentation teams:

• Cut support tickets on a specific product area
• Remove duplicate and conflicting answers
• Prepare docs for a redesign, migration, or a new AI answer feature
• Bring older topics up to your current style guide

Then limit the scope. You don't need to audit everything at once. Public-sector content teams in the UK advise auditing all the content in one user journey, such as "set up an account" or "connect an integration," rather than one random section. Start with the journey that drives the most traffic or the most tickets.

Step 2: Build your content inventory

Your inventory is a spreadsheet with one row per topic. Pull as much of it automatically as you can, from your documentation platform's export, your sitemap, or a crawler. Capture at least:

• Topic title and URL
• Section or manual it belongs to
• Owner (the person responsible for accuracy, not just the original author)
• Last updated date
• Product version or variant it applies to
• Page views and top search queries
• Reader feedback (ratings or comments), if you collect it
• Readability score, if your tool reports one

Don't wait for a perfect inventory. A good-enough list you can act on this month beats a flawless one you finish next quarter.

Step 3: Score each topic against clear criteria

This is the audit itself. Go topic by topic and answer the same questions every time, so two reviewers reach the same verdict. A simple content audit checklist for documentation:

1. Accurate: Do the steps still match the current product? Try them.
2. Current: Do the screenshots, button labels, and limits match what users see today?
3. Unique: Is this the only topic that answers this question?
4. Needed: Does anyone read it, search for it, or get sent to it by support?
5. Clear: Does it use plain language, clear headings, short sections, and numbered steps for procedures?
6. Findable: Does it have a descriptive title, a useful meta description, and links from related topics?

A quick way to summarize the results is the ROT test. Mark each topic as redundant (it repeats another topic), outdated (it is wrong or stale), or trivial (it no longer matters to readers or the business). Anything that isn't ROT is a candidate to keep.

Let data set your priorities, not your gut. The practitioners Digital.gov interviewed shared a useful warning: metrics often surprise you, for example when a page with incorrect information turns out to get a lot of traffic. Fix that page first.

Automated checks help, but they don't replace reading. Broken links and old dates are easy to flag automatically. Only a person who knows the product can tell you whether step 4 is still true.

Step 4: Decide what happens to each topic

Give every row exactly one decision. The UK Ministry of Defence's content guidance uses six outcomes that work well for docs:

Start with redundant content. It's the easiest win, and few readers will miss a duplicate. When you merge or delete a topic, redirect its URL to the surviving page so bookmarks, search results, and in-product links still land somewhere useful.

Don't be afraid of how much you remove. In one widely cited cleanup, the European Commission removed about 80% of its online content, and users benefited from the smaller, clearer site. Fewer, better topics are easier to search, translate, and keep accurate.

Step 5: Assign the work and share the results

An audit that ends as a spreadsheet changes nothing. Turn each "update," "merge," and "move" into a task with an owner and a due date. Share the findings in layers: a short summary of what you found and why it matters, then the detail for the people doing the fixes.

Keep a log of what you changed. After a few months, compare views, search success, feedback, and related ticket volume on the topics you touched. That record shows whether the audit worked, and it gives you the case for the next one.

Your documentation maintenance plan: stopping content decay

Content decay is the slow slide from "accurate" to "almost right" to "wrong." Every product release, renamed setting, and new pricing tier pushes some topics down that slope. A one-off audit resets the clock. A maintenance plan keeps it from running out again.

Give every topic an owner and a review date

Ownership is the single biggest lever. An owner doesn't have to write every word, but they are accountable for the topic staying accurate. Add a review date to each topic, for example every 6 or 12 months, and review high-traffic and critical topics more often.

Run rolling audits instead of big-bang projects

Big audits get scheduled around redesigns and migrations, and then nothing happens for years. A rolling audit covers one section or user journey every month or quarter, on a fixed schedule. It is smaller and less disruptive, and your docs never get very far out of date.

Build a documentation review process into releases

The best time to update a topic is when the product changes. Add a "docs updated?" check to your release checklist. Route changes through a documentation review process, where a subject-matter expert confirms accuracy before a topic goes live. This matters most for policies, procedures, and anything with compliance weight.

Listen to the signals your readers send

Readers tell you when a topic is wrong, if you give them a way to. Topic-level feedback, failed searches, and "this didn't help" votes are all early warnings of content decay. Review them as part of every rolling audit.

A content audit template you can copy

Use these columns as your starting content audit template:

Sort by views, filter by ROT flag, and you have a prioritized to-do list.

How Sonat helps you keep docs audit-ready

Sonat is built so that the maintenance side of this work doesn't depend on heroics. Every topic keeps an unlimited version archive, so you can see what changed and restore an older version if an update goes wrong. Approval workflows put a reviewer between a draft and your readers. Variants let you keep documentation for different product versions side by side, so older content can stay correct for older customers instead of confusing new ones.

On the reader side, feedback on every topic, automated readability checks, and a Google Analytics integration give you the signals a rolling audit needs. Because authors can draft in Google Docs, the subject-matter experts who know when something has changed can update it without learning a new tool. You can start free on Sonat and run your first audit on a real manual.

Conclusion

A content audit isn't a spring clean you do once and forget. It is how a documentation team decides, on purpose, what deserves a reader's trust. Build a good-enough inventory, judge every topic by the same criteria, give each one a clear decision, then keep the cycle going with owners, review dates, and rolling audits. Your readers, your support team, and every AI assistant reading your docs will get better answers for it.