Research question
Can a customer or support agent find the information needed to complete a defined task, and does the article actually answer that task? This report separates findability from popularity. A frequently viewed page may be popular because it is useful, or because customers keep returning after it fails. A search result with many clicks may reflect confusion rather than success.
The research unit is a task-intent pair. Examples include understanding an order status, changing account information, or preparing the evidence needed for a return. The article is successful only if the reader can identify the next permitted action without guessing. The audit should not disclose internal claims or assume that self-service is suitable for every issue.
What external guidance contributes
The W3C Web Content Accessibility Guidelines emphasize that information must be perceivable, operable, understandable, and robust. Findability is therefore not only a search ranking problem. A result that cannot be read with a keyboard or assistive technology is not findable for that user in a meaningful sense.
The Information Architecture Institute describes information architecture as organizing and labeling content so people can find and understand it. The US Government Digital Service content guidance similarly recommends writing around user needs and testing content with users. These sources support a task-based audit, not a dashboard that treats page views as outcomes.
Build an intent set
Collect anonymized search terms, contact reasons, failed searches, and agent questions. Group them by customer goal rather than by the words used. Write a test question for each group and define what a correct answer must contain. Avoid using the article's own title as the test prompt; that overstates findability.
For each intent, record first result position, result label, click path, time to answer, whether the article is current, and whether the reader can complete the next step. Mark not applicable when a human route is the correct design. A customer who reaches a safe escalation path has not necessarily failed self-service.
| Signal | What it can show | What it cannot show alone |
|---|---|---|
| Zero-result search | Vocabulary or coverage gap | That no answer exists elsewhere |
| Result click | A page was selected | That the page answered the task |
| Search reformulation | Possible uncertainty | The reason for uncertainty |
| Article exit | A navigation event | Whether the customer completed the task |
Methodology
Use a mixed audit. First inspect logs for coverage and vocabulary. Then test a stratified sample of intents with people who resemble the intended readers. Ask them to complete the task using the normal interface and record where they hesitate. Keep the exact prompt, device, language, and accessibility settings because those conditions change the result.
Have reviewers judge answer fitness against a prewritten rubric. Does the article identify eligibility, required information, exceptions, and escalation? Does it link to the next action? Does it contain an effective date or review owner when policy can change? A reviewer should not reward a page for confident wording when the supporting source is absent.
Test content maintenance. Select articles with recent policy changes and articles with high search traffic. Check whether titles, links, examples, and screenshots remain accurate. A stale article can be highly findable and still create customer effort. The National Archives records principles are useful for thinking about version and provenance, while the NIST Privacy Framework helps govern search logs that may contain personal data.
Interpreting results
Separate discovery failure from answer failure. If a user finds the wrong article, fix labels, synonyms, and ranking. If the right article lacks a condition, fix content. If the task requires account-specific action, a generic article may be doing the right work by explaining the next human route.
Compare findings by intent and audience. Do not publish a single self-service success figure when the denominator mixes successful completion, article view, and contact avoidance. Report the task definition and the number of people who could complete it. Small usability studies identify problems but do not estimate a whole customer population without a sampling design.
Accessibility and language findings should not be averaged away. A page that works for one device may fail for another. Translation can change search terms and policy meaning. If logs are not representative of all users, state that limitation.
Review the search experience as a service boundary. A result may be relevant while still asking the customer to interpret an internal term, choose between conflicting versions, or take an action that requires a separate authenticated route. Record those dependencies. If an article sends a customer to contact support, the handoff should retain the search intent where the system permits it. Otherwise the customer may have to repeat the question, and the search log will falsely look like successful discovery.
Content owners should define what happens when no article is suitable. A visible escalation path is better evidence than a forced answer. Monitor newly introduced zero-result terms after product or policy changes, but treat a spike as a prompt for investigation rather than an automatic content gap. The term may reflect an incident, a malicious query, or language that the taxonomy does not capture.
Conclusion
Knowledge article findability is best evaluated through real support intents, accessible task tests, answer-fitness review, and careful interpretation of search events. Views and clicks are useful diagnostic signals, but they are not evidence of resolution. A reliable audit tells the team whether the problem is vocabulary, navigation, content, maintenance, or an intentionally human task.
Sources
- W3C, Web Content Accessibility Guidelines, perceivable, operable, understandable, and robust content.
- US Government Digital Service, Content Design, user needs and usable content guidance.
- NIST Privacy Framework, privacy considerations for search and support data.
- National Archives and Records Administration, Records Management, trustworthy information and record context.
- Pew Research Center, Writing Survey Questions, task wording and measurement effects.
Do article views prove self-service success?
No. A view proves that a page loaded. Task completion requires a separate, defined test.
Should every issue be self-service?
No. Some issues need account context, discretion, or a human accommodation. A useful knowledge system makes that boundary clear.