Knowledge base content audit: evidence, scoring, and action workflow

A knowledge base content audit is a repeatable decision process for finding inaccurate, duplicated, unsupported, poorly routed, and missing answers. Its output is not a spreadsheet of page views. It is an evidence-backed action queue: keep, review, update, merge, redirect, retire, or create.

What a content audit should answer

• Accuracy: Does the answer still match the product, policy, interface, and approved source?
• Uniqueness: Does another page satisfy the same intent more completely?
• Coverage: Are users searching or asking for an answer that does not exist?
• Findability: Can readers reach the right answer through search, navigation, and contextual links?
• Governance: Is there an owner, review trigger, risk tier, and evidence trail?
• Action: What should happen, who decides, and how will the change be verified?

Do not make one metric answer all six questions. A highly viewed article can be wrong. Two similar pages can serve different audiences. A failed search can reflect vocabulary, ranking, access, or coverage. An audit works by combining signals and then assigning human review.

How we tested

We created a controlled local fixture with 20 fictional articles and eight fictional demand signals. Each article received separate outdated, demand, and duplicate scores. The rules prioritized known factual defects, source-version gaps, broken steps, stale screenshots, review age, traffic, assisted-contact volume, and declared similarity clusters.

Duplicate candidates were non-primary members of an authored cluster; the script did not infer similarity. Missing-content candidates required an uncovered query plus at least ten failed searches or five assisted contacts in the fictional 30-day window.

Action	Result	Rule outcome
Keep	8	No outdated or duplicate rule fired
Review	3	Aging or screenshot evidence required human validation
Update	5	Factual, source-version, or broken-step risk crossed the threshold
Merge	4	Page was a non-primary member of a declared similarity cluster
Create candidate	3 of 8 demand signals	Uncovered demand crossed the fictional threshold

Limitations

The fixture is not a crawl of this website or a customer help center. It includes no real traffic, searches, tickets, rankings, or subject-matter review. The authored similarity clusters cannot prove duplication, and the missing-content thresholds cannot prove that publishing a page will improve task completion. The method and CSV files make the logic inspectable; editors still make every consequential decision.

Build the audit inventory

Export one canonical row per article. Include drafts or private content when they can collide with public answers, but label visibility. A useful minimum inventory contains:

Field group	Fields
Identity	Article ID, canonical URL, title, locale, audience, product area, article type
Governance	Owner, reviewer, risk tier, source of truth, last verified, next review, status
Technical	HTTP status, canonical, redirect target, indexability, internal links, broken assets
Content	Product version, policy version, screenshots, structured fields, related intent
Demand	Views, searches, failed searches, support topics, feedback, task-success event
Decision	Evidence, action, priority, approver, due date, destination URL

Keep observed data separate from derived scores. Preserve the date range, filters, query definition, and source system for every metric. “Search failures: 40” is not reproducible unless the audit defines the window and what counted as a failure.

Add a source ledger for claims that can change. A row should identify the approved release note, policy, contract, product owner, tested interface, or other authority used to verify the article. Record the source version and verification date separately from the page’s publication date. For procedures, store the tested role, plan, device, locale, starting state, and expected result so another reviewer can repeat the check.

Use the UDM framework as three queues

Outdated: verify facts before freshness

Start with release notes, policy changes, interface changes, broken procedures, expired offers, renamed features, old screenshots, and source-version gaps. “Last updated” is a triage signal, not proof. A two-year-old conceptual article may be accurate; yesterday’s edit can still repeat an obsolete fact.

• Prioritize known defects and high-risk procedures.
• Compare claims with an approved primary source.
• Run the steps in a safe test environment when the article is procedural.
• Record the product, plan, role, locale, date, and result.
• Trigger review from releases rather than relying only on a calendar.

Connect verified pages to the knowledge base content lifecycle so the audit does not become a one-time rescue project.

Duplicate: compare intent and destination

Similarity tools find candidates; they do not make the decision. Compare audience, task, scope, product version, locale, search intent, backlinks, and downstream links. Pages with similar language may need separation when one is a troubleshooting procedure and the other is a policy explanation.

When one page can fully satisfy both intents, choose a canonical destination, merge unique useful material, update internal links, and apply a server-side redirect. Google documents redirects and canonical annotations as strong canonicalization signals in its duplicate URL guidance. Keep a rollback record and verify the old URL, destination, canonical, sitemap, and important inbound links.

Missing: combine demand and task evidence

Review failed searches, search reformulations, support topics, chat transcripts, product releases, onboarding tasks, sales objections, and internal escalation notes. Normalize synonyms before declaring a gap. A zero-result query may need a synonym, a better title, permission correction, or ranking change rather than a new page.

For each candidate, define the audience, task, evidence source, existing alternatives, owner, and acceptance test. The ticket-to-article workflow can turn repeated support evidence into governed content without copying private ticket text.

Prioritize with gates and scores

Use mandatory gates before weighted scores. A known harmful instruction, exposed secret, broken safety step, or legally required correction should enter an urgent queue regardless of traffic.

Dimension	Example evidence	Use
Risk	Known factual defect, safety, privacy, financial or contractual impact	Mandatory gate and severity
Demand	Qualified views, failed searches, assisted contacts, key journeys	Sequence work among similarly risky items
Confidence	Primary source, reproducible test, SME verification	Decide whether to act or investigate
Effort	Rewrite, screenshot, localization, legal review, redirect work	Plan delivery; never erase risk

Publish the formula, thresholds, and tie-breaking rule. Do not label a score “quality” when it measures only age or traffic. The Consortium for Service Innovation warned against focusing on a single article-quality number in legacy KCS v6 guidance, published when KCS meant Knowledge-Centered Service.

Separate evidence confidence from priority

A high-priority signal with weak evidence should trigger rapid investigation, not an automatic rewrite. Score confidence independently:

• Confirmed: a primary source, repeatable test, or accountable subject-matter expert verifies the issue.
• Corroborated: two or more independent signals point to the same problem, but final verification remains.
• Candidate: one analytic, similarity, or feedback signal needs investigation.
• Rejected: review found the signal inapplicable, misconfigured, or already resolved.

Keep the supporting excerpt, test result, screenshot, query definition, or source link with the decision. This prevents a future editor from reopening the same question without context and makes false positives visible.

Execute each action safely

• Keep: record the evidence, owner, and next trigger.
• Review: assign the unresolved claim to a qualified reviewer.
• Update: correct the source, rerun the procedure, update screenshots and translations, and log the material change.
• Merge: choose the destination, preserve unique value, redirect alternatives, and repair links.
• Retire: confirm that the task no longer exists; redirect when a relevant successor exists, otherwise return an appropriate removal response.
• Create: write to a defined task, link it into the architecture, and test retrieval before launch.

Use the knowledge base deprecation strategy for retirement and the migration guide when a platform move changes URLs or metadata.

Run an owned action queue

Every queue item needs an editorial owner, subject-matter approver, technical owner when URLs change, due date, evidence state, destination, and acceptance test. Separate the person who drafts the correction from the person who confirms a high-risk factual or policy change when practical.

Limit work in progress. Complete a small batch through verification before opening hundreds of items. For a merge, the batch is not done when the copy is pasted: it is done when the destination covers the intended tasks, the old URL redirects directly, internal links point to the final URL, the canonical and sitemap agree, locale variants are handled, and monitoring shows no unexpected error.

Record “no change” decisions too. A rare emergency article may stay despite low traffic; two similar pages may remain separate because their permissions or audiences differ. The reason is part of the audit evidence.

Measure the audit outcome

Measure completion and downstream behavior separately:

• high-risk defects corrected and independently verified;
• merge redirects, canonicals, sitemaps, and internal links passing;
• owner and review-trigger coverage;
• translation and screenshot freshness;
• failed-search and reformulation changes for affected tasks;
• explicit task-completion or solved events where available;
• assisted-contact signals under a stated event rule and window.

A journey that does not open a ticket is not proven solved. Do not convert an assisted-contact signal into “prevented tickets” without an explicit success event or a causal comparison. Use the knowledge base performance benchmarking guide to define denominators and observation windows.

Validate with a re-crawl and sample review

After publishing, rerun the inventory rather than assuming the edit propagated. Check status codes, redirect chains, canonicals, indexability, sitemaps, structured data, internal links, images, locale relationships, and restricted-content behavior. Compare the output with the approved action list and investigate any mismatch.

Draw a risk-based sample for human review. Include every critical correction, a sample of lower-risk updates, merge destinations, redirects, newly created articles, localized variants, and pages that automation marked Keep. Record false positives and false negatives, then adjust the scoring rules before the next batch.

Measure affected tasks before and after under comparable windows, but state external changes such as releases, seasonality, campaign traffic, or support-channel changes. The audit can show that errors were corrected and technical changes worked; observational trends alone do not prove that the audit caused a business outcome.

A repeatable audit cadence

1. Monitor critical sources, releases, errors, and feedback continuously.
2. Triage known defects and high-risk pages weekly.
3. Review demand and missing-content evidence monthly.
4. Review duplication and information architecture quarterly or after major releases.
5. Audit owners, permissions, retention, and lifecycle controls at least annually.
6. Rerun affected checks after every material change.

KCS’s current flag it or fix it guidance supports addressing knowledge problems in the flow of work. A scheduled audit remains useful, but it should not become permission to leave a known error until the next quarter.

Frequently asked questions

How often should a knowledge base be audited?

Use continuous triggers for material changes, a frequent triage cycle for high-risk content, and periodic portfolio reviews. One annual sweep is too slow for fast-changing product or policy documentation.

Should old articles be deleted?

Only after confirming the task, legal retention need, traffic, links, and successor. Merge and redirect when another page satisfies the intent. Do not redirect every retired page to the homepage.

Can AI run the audit?

AI can cluster candidates, extract claims, and flag inconsistencies. It cannot verify product behavior, policy authority, private context, or final intent without evidence and qualified human review.

Does low traffic mean an article should be retired?

No. Low traffic may be appropriate for a rare but critical task, or may reveal poor findability. Combine demand with risk, audience, contractual need, and retrieval evidence.

Official and primary guidance

• Google Search Central: creating helpful content
• Google Search Central: canonicalization and duplicate URLs
• Google Search Central: redirects and Google Search
• Consortium for Service Innovation: flag it or fix it
• Consortium for Service Innovation: legacy KCS v6 content health indicators