The principles of navigation design are simple and widely known. Keep the menu short and consistently positioned, use names that make sense without context, and offer one path to the most important action. The problem is that you can follow all of these guidelines and still have a website where people wander without achieving anything. A rule tells you how to design a menu. It does not tell you whether your menu works.

This article is about the second part. We assume you already have some form of navigation and want to find out whether it gets in the way. Instead of repeating best practices, we show you where the evidence is and how to read it.

We do not give an ‘optimal number of menu items’ or thresholds beyond which navigation supposedly breaks. Such figures circulate through guides without sources and do not transfer from one website to another. A shop with a thousand products and a service website with five pages operate by different rules—the point of reference is behaviour on your website, not somebody else’s rule.

Symptoms that show the problem lies in navigation

The most common diagnostic mistake is: ‘conversion is poor, so we need to improve the content’. Yet the content may be perfectly fine—nobody is reaching it. A navigation problem leaves a different signature in the data than a problem with the offer or price.

  • Traffic circles without going deeperVisits contain several page views, return to the home page and end without reaching the destination page.
  • Returns to the same pageThe same URL appears two or three times in a single session. This signals that someone could not find the way forward and returned to the starting point.
  • Exits from intermediate pagesPeople disappear not from an offer page or form, but from listings and category pages that were only meant to lead them onwards.
  • Questions about information that is on the websitePeople ask about prices, directions or return terms in chat even though everything is published. The answer exists; the path to it does not.
  • Good content with no trafficA page you are counting on receives hardly any visits from within the website—people simply do not see it in the menu.

The opposite signature looks like this: people arrive exactly where they were meant to go, spend a reasonable amount of time there, read to the end and leave. The navigation has then done its job, and the problem lies elsewhere—in the offer, price, trust or the form itself. There is no point rebuilding the menu when the symptoms indicate this second scenario.

If people do not even know what you do, the problem occurs before the menu. We explain how to examine the area visible without scrolling in our article on the above-the-fold section of a website.

Four sources of navigation evidence

Navigation leaves traces in four places at once. Each reveals a different part, and only together do they form a complete picture. Work through them in order—it is an afternoon’s work, not a quarter-long project.

  1. Menu clicks.A click map of the header answers two questions: which items people choose most often and which are dead. Also look for clicks on things that are not links—a category name, a logo in an unusual place or a list heading. Repeated taps on a non-clickable element are a request for a link that is missing.
  2. Exit pages.List the pages where visits most often end and divide them into two groups: destination pages, where an exit is natural, and intermediate pages. Exits from the second group provide a list of potential navigation dead ends.
  3. Paths between pages.The sequence of URLs in one session says more than aggregated page views. Look for three patterns: a return to the home page between every step, a loop between the same two URLs and a long series of page views that ends in an exit with no action.
  4. Questions asked in chat.The cheapest and most frequently overlooked source. If conversations repeatedly include ‘where can I find…’, ‘do you offer…’ or ‘how much does it cost…’, and the answer is already published, you have a ready-made list of navigation gaps written in your customers’ own words.
  1. 0:00

    Arrival from a search engine on a blog post about a service

  2. 0:26

    A menu click followed by a visit to the ‘Services’ page

  3. 0:41

    Return to the home page and scroll to the footer

  4. 1:04

    Another visit to ‘Services’, the same list, no click

  5. 1:18

    Exit without making contact or reaching the service page

In a page-view report, this visit looks engaged: five page views and more than a minute. In reality, the visitor is circling a page they cannot find their way to.

We describe techniques for reading maps and selecting recordings separately, in our guides to reading heatmaps and analysing session recordings. Here, the sole purpose is to use them to answer one question: did the person know where to click?

Menu-item labels: the customer’s words versus company vocabulary

A menu label is a promise. A person reads it in a fraction of a second and decides whether it leads to what they need. When the promise is phrased in the company’s language rather than the customer’s, the click simply never happens—and you will not see an error, only a lack of traffic.

You already have the best source of the right words: the search queries that bring people to you and the content of chat conversations. If customers write ‘how much does it cost?’, ‘Pricing’ will work better than ‘Engagement model’. The same customer words help when naming options on a product list, as shown in the guide to product filters on category pages.

Scroll the table sideways to see all columns.

Instead ofWriteWhy
SolutionsWhat we do‘Solutions’ says nothing about the content and fits every industry.
Engagement modelPricingPrice is one of the most common questions, and the answer should be named directly.
ServicesNames of specific servicesOne collective item postpones the entire choice by another step and lengthens the path.
Knowledge baseHelp and answersA customer is not looking for a knowledge base; they are looking for an answer to their question.
Our workImplementation examplesIndustry language is replaced with a description of what the person will actually see.
Customer areaLog inThe action is unambiguous; the name of an area requires interpretation.

If you want to test labels before implementing them, card sorting is useful: ask a dozen or so people from outside the company to group topics written on cards and name the resulting groups themselves. This is a separate research practice, not a Meetlead feature—all you need are some cards and an hour. A short live test works similarly: ask someone to find a specific piece of information and observe where they look. We describe how to run such sessions in our article on website usability testing.

Check it on your website

Chat questions are a ready-made glossary of labels for your menu—written by customers every day, for free. See what Meetlead collects from conversations and visits.

Navigation works differently on a phone

On a computer, the menu is always visible and acts as a map—a person can see where they are and what else exists. On a phone, the menu is usually hidden behind an icon, so it stops being a map and becomes a drawer that must be opened deliberately. This changes the entire logic: what matters is what can be seen without opening the drawer.

  • Check how many people open the hidden menu at all—if almost nobody does, the entire navigation depends on links in the content.
  • Set the item order for phones: the most important options at the top, with no scrolling inside the expanded menu.
  • Keep the most important action outside the drawer and permanently visible in the header.
  • Provide a clear way back through the website—on phones, people overwhelmingly use the back button rather than breadcrumbs.
  • Add contextual links at the end of long pages, because that is where scrolling ends and decisions are made.
  • Check whether the chat launcher or a promotion bar covers any menu items when the menu is expanded.

All four sources of evidence work in the same way here, on one condition: the data must be filtered to mobile traffic only. Mixing devices obscures the very pattern you are looking for. We discuss this more broadly in our guide to conversion on mobile devices.

The most common navigation traps

A menu rarely breaks at a single moment. It is usually a slow decline over two or three years in which every individual decision seemed reasonable.

  • A menu that grows with the companyEvery new service gets its own item because that is easiest. Two years later, the header contains twelve items and no hierarchy, and nobody wants to remove their own.
  • Categories that mirror departmental structureThe menu is organised around who is responsible for what inside the company. This division means nothing to a customer—they search by their own need, not by your organisational chart.
  • ‘Services’ as a catch-allOne item collects everything that can be sold. It adds a step to every path and forces people to browse a list instead of choosing their need immediately.
  • Names understood only internallyA proprietary product name or an abbreviation used inside the company. The team reads it without hesitation; the customer has no way to guess what lies behind it.
  • Navigation that depends on the entry pageThe menu on a blog post differs from the one on the home page, so search traffic does not see the same paths as direct traffic.

The last point is often the costliest because it usually affects the largest group of visitors. Check it directly: open one of your blog posts from a search engine and count how many clicks separate you from contact. If there are more than two, content traffic is probably not reaching the goal—we describe how to analyse the full path in our article on the customer journey through a website.

A repair plan with verification

Rebuilding the entire menu at once has one serious drawback: if the results change, you do not know which change worked. It is better to proceed step by step, with a clearly stated hypothesis before each one.

  1. Choose one path that matters.For example: from a blog post to a service page, or from the home page to contact. One path, one goal.
  2. Collect evidence from four sources.Menu clicks, exit pages, session paths and chat questions. Write down exactly what you observed before you begin to interpret it.
  3. State the hypothesis in one sentence.‘People from the blog do not reach the pricing page because it is absent from the menu and there is no link in the content’—that is a testable hypothesis.
  4. Make one change.Rename an item, move a service out of a submenu or add a permanent link to the header. One thing, not a package.
  5. Decide what should change in the data.Write this down before deployment: more visits to the destination page from within the website, fewer exits from an intermediate page and fewer ‘where can I find’ questions in chat.
  6. Wait for a full cycle and compare.At least two weeks, and longer for low-traffic websites. Compare with the period before the change using the same type of traffic.
  7. Watch several recordings after the change.The figures will tell you whether things improved. The recordings will tell you whether they improved for the reason you expected.

If you accumulate a dozen such hypotheses and struggle to prioritise them, place them in a broader framework instead of patching the website point by point. We describe the framework for this process—from collecting observations to setting priorities—in our article on a website conversion audit.

  • Navigation is a hypothesis about how customers think—and hypotheses must be tested.
  • Design principles help you begin, but they cannot replace evidence from your own traffic.
  • One change with a recorded expectation creates knowledge; a complete rebuild creates only a new state.
  • Customer questions are the cheapest and most up-to-date menu audit.

If the site search returns no results, use the guide: Website search with no results: missing content or the wrong words?.