Knowledge Base Audit Checklist: Find Stale, Duplicate and Missing Articles

A knowledge base audit answers five questions about every article: who owns it, is it still true, is it the only article on its topic, does it answer a question customers actually ask, and do its links and labels still work. Run the audit as an inventory spreadsheet with one row per article, test the riskiest articles (prices, refunds, eligibility) against the current policy, merge duplicates, then add articles for the questions your inbox and chatbot could not answer.

This guide gives the checklist, a worked example with the arithmetic, and how often to repeat it. It draws on the Consortium for Service Innovation's KCS content-health guidance, checked November 12, 2026. Chatsy publishes this blog and sells a help center; the Chatsy-specific notes are in one marked section.

The checklist at a glance

Use these columns in your inventory. Each one maps to a check later in this guide.

The Consortium for Service Innovation's Content Standard Checklist (formerly the Article Quality Index) checks a sample of articles for six things: the article is unique and not a duplicate, its content is complete, statements are clear, the title describes the main environment and issue, hyperlinks remain available to the intended audience, and metadata such as article state and audience is set correctly. It also notes that "a duplicate article is a more serious error than an article that is too wordy" (KCS v6 Practices Guide, Technique 5.10: Content Health Indicators).

Step 1: Build the inventory and assign owners

Export every article with its title, URL, category, status and last-updated date. Most help-center tools can list articles in a table; if yours cannot, a crawl of the public help center gives you URLs and titles.

Then add the columns above by hand. The owner column matters most. An article with no owner will not be reviewed next time either. Assign owners by the source of truth: billing articles to whoever owns pricing, setup articles to the product team, shipping articles to operations.

Separate "last updated" from "last reviewed". Help-center tools record the last edit, and fixing a typo resets it. Keep your own review date in the inventory.

Step 2: Test high-risk articles against current policy

Do not just reread a risky article. Test it. For each high-risk article:

1. Open the source of truth: the pricing page, refund policy, terms or product setting.
2. Write down every number, time limit, plan name and condition in the article.
3. Compare each one with the source. Mark the row "fail" on any mismatch, even a small one.
4. Ask the question as a customer would, in your help-center search and your chatbot if you have one. Check that the answer matches the source too.

Typical failures are an old price in a table, a refund window that changed from 30 to 14 days, a plan that was renamed, or a screenshot showing a menu that moved. If a chatbot is trained on the help center, it repeats these errors to customers, so a stale article does double damage.

Step 3: Find and merge duplicates

Duplicates are the most common audit finding and the one KCS treats as most serious, because two articles drift apart and customers get two different answers.

To find them:

• Sort the inventory by title and scan for near-identical titles ("Cancel your plan", "How to cancel a subscription").
• Search your help center for the top 20 customer questions and note every question that returns two or more articles with overlapping answers.
• Check old migration leftovers: articles imported from a previous tool often duplicate newer ones.

To merge, keep the article with more demand or the better URL, move any unique detail into it, archive the other and redirect its URL to the survivor. Update internal links that pointed at the archived article.

Step 4: Find gaps from real questions

An article nobody needs is clutter; a question nobody answered is a gap. Pull questions from three places for the last 90 days:

Add each recurring question as a row with no article yet and a proposed owner. Write the article only if the answer is stable; a question whose answer changes weekly belongs in a status page or a pinned announcement.

Step 5: Check links, titles and labels

Mechanical checks catch the errors readers notice first:

• Links: run a link checker over the public help center. Fix every broken link and replace redirected ones with the final URL.
• Titles: the KCS checklist asks whether the title describes the main environment and issue. "Billing" fails; "Change the card on your monthly plan" passes.
• Labels: confirm category, audience and status. A draft that customers need should be published; an article for a retired feature should be archived, not left live.
• Images: check that screenshots match the current interface, or remove them if the text stands alone.

A worked example: a 120-article help center

This example is illustrative, not data from a customer. A software company has 120 published articles and two people who can spend part of a week on the audit.

After the audit, the published count is 120 − 7 archived duplicates − 12 archived low-demand articles + 9 new articles = 110 articles, each with an owner and a review date.

Time budget: testing 18 high-risk articles at about 20 minutes each is 360 minutes, or 6 hours. Reading and labeling the other 102 at about 5 minutes each is 510 minutes, or 8.5 hours. That is roughly 14.5 hours before any rewriting. Measure your own minutes per article on the first 10 rows and redo the estimate.

How often to repeat the audit

Match the interval to how fast the source of truth changes, not to the calendar.

Between audits, add one habit: whenever a support agent sends a customer an article that turns out to be wrong, they flag it in the inventory the same day. The KCS Practices Guide names this habit "Reuse Is Review" (Technique 4.1): the people using articles are the ones who catch errors.

Auditing a Chatsy help center

Chatsy's knowledge base module (Hobby plan and above) gives each article a status of Draft ("Only you can see it"), Published or Archived, so archived articles stay available for reference without being live. Articles have a title, summary, category and URL slug, categories can be nested, and the help center supports URL redirects, which you need after merging duplicates. Chatsy does not store an owner or a review date on an article, so keep those in your inventory spreadsheet.

For the gap step, use the agent's knowledge gaps, described in the next section.

Help-center search in Chatsy is keyword search on titles, excerpts and article text, not AI search, so test the exact words customers use. If an agent was trained on help-center articles, it does not update on a schedule: after you fix or merge articles, import or refresh them in the agent's knowledge so it stops repeating old answers. See publish a knowledge base and train your AI agent, and the knowledge base feature page for what the module includes.

Using Chatsy's knowledge gaps in step 4

If a Chatsy agent answers from your help center, its misses are a ready-made gap list. Chatsy groups them by question, so the same question asked in ten chats is one row with a count of ten. Two places show them: the agent's Knowledge page lists up to three open "Questions it struggled with" from the last 30 days, and Analytics lists every knowledge gap for the last 7, 30 or 90 days.

A question becomes a gap in three ways. There is no confidence score behind it; each one is a visible event in a conversation.

Each row has a Write the answer action. It saves your answer as a written source in the agent, and the gap shows as answered until the question comes up again. Two cautions for an audit:

• An answer written there is not a help-center article. If customers should be able to read it, publish an article and import it into the agent instead.
• Fixing the help center does not close the gap row. Only answers saved with Write the answer mark a gap as answered. If you fixed the article instead, check that the question stops appearing in the next period.

The lists are built from the newest 200 rated answers and the newest 200 conversations in the period, so on a busy agent use a shorter range and run the check weekly. See train your AI agent for the Knowledge page and the features page for what Analytics reports.

When a full audit is not worth it

Skip the full audit in some cases:

• Under about 20 articles. Read them all in one sitting instead of building a spreadsheet.
• You are about to migrate tools. Audit during the migration, so you do not move stale articles twice.
• Nobody will own the fixes. An audit that produces a list nobody acts on wastes the hours above. Assign owners first, or audit only the high-risk articles.

Frequently asked questions

What should a knowledge base audit include?

An inventory with an owner and review date per article, a policy test of high-risk articles, a duplicate search, a gap list from real customer questions, and a link and label check. The KCS Content Standard Checklist covers uniqueness, completeness, clarity, title, links and metadata.

How many articles should I review each time?

Review every high-risk article each cycle. For the rest, KCS describes sampling a handful of articles per contributor per period rather than reading everything, which works once the inventory and owners exist.

Should I delete or archive outdated articles?

Archive and redirect when the URL has links or traffic, so customers and search engines reach the current answer. Delete only articles with no links, no traffic and no reference value.

How does a chatbot change the audit?

A chatbot trained on the help center repeats whatever the articles say, so wrong articles reach more customers. Its unanswered and handed-off questions also become your best gap list. Re-import fixed articles into the bot after each audit; see how to train a chatbot on documentation.