In short: Website navigation testing checks whether intended visitors can find the information they need through a site’s menu and hierarchy. Use card sorting to discover possible groupings; use tree testing to evaluate a proposed structure before investing in a visual redesign.
Why navigation needs a different test from page conversion
Analytics can show that visitors opened a menu, clicked a link, or landed on a service page. Those events do not explain whether people understood the labels, expected a different route, or used search because the menu felt unclear. A navigation test isolates the findability question before changes to layout, copy, or calls to action make the result harder to interpret.
This distinction matters on B2B sites, where a prospective buyer may need to compare an approach, assess fit, review evidence, or find a technical detail before contacting sales. A menu organized around internal departments can look tidy and still make those jobs difficult. Start with the task a visitor is trying to complete, then check whether the hierarchy supports it.
Choose the method that matches the question
An open card sort helps you discover how people group a set of representative pages or resources and what they call those groups. It is useful when the current categories are unclear or the site is being reorganized. Treat the output as design input: participants may use different mental models, and a sort does not produce a finished menu by itself.
A tree test evaluates whether people can find a target item in a proposed hierarchy. Participants see the category structure without the visual page design and try to complete realistic tasks. This makes it useful for comparing menu labels, page locations, and alternative information architectures before building new layouts. If you already have a menu and need to test findability, a tree test answers that question more directly than asking people to sort cards into categories.
Nielsen Norman Group describes card sorting as a way to generate possible groupings and tree testing as a way to evaluate a hierarchy. It also cautions that card sorts omit the wider context of images, links, and page structure. Use the methods as complementary stages, not interchangeable names for the same exercise.
Build the test around buyer tasks
Begin with a focused inventory of pages people use to make a decision: service descriptions, process details, pricing or scope information, case evidence, integrations, security material, and contact paths. Use internal search terms, search queries, sales questions, support requests, and page analytics to choose representative destinations. Do not put every URL into a test simply because it exists.
For each task, write the situation in the visitor’s language and define the correct destination before recruiting participants. A neutral task might say, “Your team is comparing providers and needs to understand what happens after kickoff. Find the information that would help you evaluate that.” Avoid naming the menu label or page title you want them to select; otherwise the prompt gives away the answer.
Include tasks from more than one meaningful buyer context when the site serves different audiences. A marketing leader and a technical evaluator may need different information even when they are reviewing the same service. Keep the task set short enough that participants can stay attentive, and check that each task has a defensible answer. If several destinations could reasonably satisfy a task, record those acceptable paths in advance rather than scoring one arbitrary click as the only success.
Read success, first clicks, and detours together
For each task, review whether people reached an acceptable destination, which category they chose first, how directly they got there, where they backtracked, and how confident they felt. A correct final answer reached through several wrong turns is different from a clear first choice. Comments and short follow-up questions help explain whether the friction came from a vague label, a surprising parent category, or an unfamiliar term.
Start with a small qualitative pilot to catch confusing task wording and learn why people choose a route. Use a larger, planned sample if you need a quantitative benchmark between menu versions; a handful of sessions can uncover problems but should not be presented as a precise population success rate. NN/g makes the same distinction between formative qualitative testing and quantitative comparisons.
Look for patterns, not a single unusual route. If participants consistently start under the wrong category but recover, revisit the label or parent grouping. If they cannot find a page because it is absent from the hierarchy, that is an architecture gap. If they reach the right page and still cannot understand the offer, the menu has done its job and the page itself needs review.
Validate the revised menu in the full experience
A tree test deliberately removes visual cues, related links, and page content. Passing it does not prove that the implemented navigation is usable on mobile, keyboard, or screen-reader workflows. After revising the hierarchy, test important tasks on the actual site at representative viewport sizes. Check that the page title, breadcrumbs, links, and next step reinforce the route rather than contradict it.
For more on the relationship between page roles and search intent, see B2B service-site architecture around search intent. The guide to breadcrumb navigation covers orientation once a visitor reaches a deeper page, and landing-page usability testing addresses the full page experience.
Sources and further reading
- Nielsen Norman Group: Tree Testing — Evaluate Menu Labels and Categories
- Nielsen Norman Group: Card Sorting — Uncover Users’ Mental Models
- Nielsen Norman Group: 3 Common Information Architecture Mistakes
These methods evaluate findability and hierarchy. They do not replace testing the live page, verifying accessibility, or measuring downstream lead quality.
How did this article land?
Choose one reaction. You can change it anytime.