Your Documentation Gets Plenty of Traffic, and You Still Can't Tell If It Works

Every documentation budget review I've sat through eventually reaches the same question: what are we getting for this? The answer usually arrives as a traffic chart. Page views are up. Unique visitors are up. The upgrade guide is the most-visited page on the site.

None of that tells you whether the docs work. Your most-visited page might be your most-visited page because it's failing: readers land on it, don't find the answer, come back the next day, and then open a ticket that links to it. A traffic chart can't tell that page apart from one that solved the problem in thirty seconds.

That's a real business problem. If you can't show which pages succeed and which ones fail, you can't justify the documentation budget, you can't decide where to spend the next writing hour, and you can't prove that last quarter's rewrite did anything.

Why the usual numbers mislead

The metrics that come for free with a docs site measure attention, not outcomes:

• Page views measure demand. High traffic on a troubleshooting page can mean the product is confusing, the page is unclear, or both.
• Time on page cuts both ways. A long visit might be careful reading, or it might be someone lost halfway through a procedure.
• Bounce rate punishes success. A reader who searched, found the exact command, copied it, and left looks identical to one who gave up.
• "Was this page helpful?" buttons tell you that someone was unhappy, but not why. A thumbs-down on a 3,000-word configuration reference gives a writer nothing to fix.

Documentation exists so that someone can finish a task without asking a person for help. You can't observe that directly, but you can observe the moments when it didn't happen. Those failure signals are far more useful than any success metric, because each one points at a specific page and a specific gap.

Five signals that a page isn't working

1. Searches that return nothing. A zero-result search is a reader telling you, in their own words, what they expected to find. Many docs search tools can record this. Algolia's analytics dashboard, for example, reports a no-results rate and lists the individual searches without results. If you use Google Analytics 4, its enhanced measurement can record a view_search_results event, with the query in a search_term parameter, whenever a results page URL contains a parameter such as q, s, or query. Read the list every month. Some of it will be missing content. The rest will usually be vocabulary: your docs say "workspace" and your customers search for "project."

2. Searches that get rewritten. A reader who searches, clicks a result, comes back, and searches again with different words didn't find what they needed. Sessions with three or four reformulated queries point straight at the topics your information architecture is hiding.

3. A docs page followed by a support request. This is the strongest signal you can collect, and most teams don't collect it. If you know which page a reader was on when they clicked "Contact support," you know which page failed them.

Don't rely on the browser's Referer header for this. If your docs and your support portal live on different domains, the default referrer policy in modern browsers (strict-origin-when-cross-origin) sends only the origin, so you'll see https://docs.example.com/ and not the page. Pass the page explicitly instead:

<a href="https://support.example.com/new?from_doc=/guides/upgrade-to-v5">
  Still stuck? Contact support
</a>

Then have your support form store that value in a hidden field on the ticket. Now every ticket carries the page that came before it.

4. Tickets the docs should have answered. Add one triage tag, with three values: docs missing, docs wrong, and docs couldn't be found. It takes an agent two seconds per ticket, and within a month it tells you more about your documentation than any analytics tool. It also feeds the approach I described in Your Support Team Has Already Written the Documentation You're Missing: once you know which tickets are documentation failures, the answers your agents already wrote are your first drafts.

5. Feedback that says what went wrong. Keep the feedback widget, but replace the bare thumbs-down with a short follow-up: The steps didn't work, Something is missing, It's out of date, I couldn't find what I needed, plus an optional "What were you trying to do?" box. One sentence of context is worth a hundred anonymous downvotes.

Turn signals into a short, ranked list

Collecting signals is the easy part. The value comes from a routine that turns them into work:

1. Once a month, pull the top ten zero-result searches, the top ten pages that precede support tickets, and the counts for each docs triage tag.
2. Rank the pages by how many failure signals point at them, not by traffic.
3. Fix the top three. Rewrite the procedure, add the missing topic, or add the customer's vocabulary to the page so search can find it.
4. Watch the same signal next month. If the upgrade guide preceded a steady stream of tickets before the rewrite and noticeably fewer after it, that's a result you can put in front of the person who approves the budget.

That last step changes the budget conversation. Instead of "traffic is up," you can say "these three pages were generating tickets, we fixed them, and the tickets dropped." That's language finance and engineering leadership both understand, and it's grounded in your own data rather than an industry benchmark.

What not to do

• Don't set traffic targets for documentation. The moment page views become a goal, someone will split one useful page into five thin ones.
• Don't measure everything at once. Two signals you actually review beat ten dashboards nobody opens.
• Don't treat a quiet page as a good page. A page with no tickets and no searches might be perfect, or it might describe a feature nobody can find. Check it against what the product actually does.

Where to start this week

You can have the first signals flowing in a few days:

1. Check whether your docs search logs queries, and whether it records searches with no results. If it doesn't, that's your first fix.
2. Add the page path to every "Contact support" link on your docs site, and capture it on the ticket.
3. Add the docs triage tag in your help desk and ask the support team to use it for a month.
4. Pick the single page with the most signals at the end of that month and rewrite it.

Most of this is small engineering work: a query parameter, a hidden form field, a tag. That's why it so often doesn't get done. Writers don't have access to the code, and engineers don't see it as their job.

Need help with yours?

Measuring documentation well sits right between writing and engineering: someone has to wire up the instrumentation, read the search logs and the ticket data, and then write the page that fixes what they show. That's the work I do. If you're being asked to justify your documentation and all you have is a traffic chart, get in touch. I'm happy to look at what you're collecting today and tell you where I'd start.