How to Design a Website Navigation Menu That People Actually Use

Your website navigation menu is the first map a visitor reads on your site. In this guide I skip information architecture theory and stay on the interface itself: mega menus, mobile menus, labels, item count, utility links and the footer. I have built and repaired menus since 2012, so these are working rules, not trends.

What is a website navigation menu and how do you design one?

A website navigation menu is the interface layer that decides where links to your key pages appear, in what order, under which labels and with what interaction. A good design lets the main menu, utility menu, mobile menu and footer work as one system, so visitors know where they are and where to go next.

I run the design in four steps. First, I write down the three jobs visitors come to do most often. Next, I place the pages that serve those jobs in the main menu. Then I rewrite every label in the visitor's own words. Finally, I test desktop and mobile behavior separately.

This article covers the visible surface only. How you group pages and how deep your category tree goes is a separate job. For example, I covered large catalog trees in my post on category structure for large websites. Here we look at how to show that tree on screen.

What job does a good menu actually do?

A good menu answers three questions at once. What does this site offer? Where am I right now? How do I get to what I need? If a visitor stalls on any of them, the back button wins. So I treat the menu as the first sentence of your sales team, not as decoration.

A menu is also a promise. Visitors scan it and guess the scope of your business within seconds. For example, an architecture studio that shows "Projects", "Services" and "Contact" tells people they are in the right place. On the other hand, a menu led by "Our Vision", "Values" and "Careers" makes them work harder.

The third job is orientation. Many visitors land on an inner page from an ad or a search result. They never see your homepage. Therefore the menu on that inner page must summarize the whole site. A highlighted current page, a logo that links home and a consistent layout build that sense of place. I check these first whenever I work on reducing bounce rate on a business website.

How many items should a navigation menu have?

There is no magic number. In my field experience, five to seven top-level items read comfortably on most business sites. Treat that as a starting range, not a guarantee. What matters more is that each item answers a different need.

You have probably heard the "seven plus or minus two" rule. However, George Miller's observation was about short-term memory, not menus. Visitors do not memorize a menu; they scan it. In other words, ten well-grouped items can beat five vague ones.

Still, extra items have a cost. Each one reduces the visibility of the others and can break the line on smaller laptops. I trim menus with these questions:

• How many people clicked this item in the last three months?
• Is this page close to a sales or contact step?
• Would the content make sense under another item?
• If I remove it, can visitors still reach it another way?

The answers usually show that pages like "About" can move to the utility menu or the footer without harm.

How should you write menu labels?

Use the words your visitors use, not internal jargon. For example, "Services" usually beats "Solutions", and "Blog" or "Guides" beats "Resources". People decide while scanning, not while reading.

I pull label ideas from three sources. First, I read the site search log, because what people type is a label candidate. Second, I check search query data. Third, I ask the sales team which words they hear on the phone most often.

These rules help me write labels:

1. Keep labels to one or two words, because long labels break the line.
2. Use a clear noun or action, such as "Pricing" or "Get a Quote".
3. Avoid two near synonyms side by side, like "Services" and "Solutions".
4. Protect your brand voice, but skip clever labels that hide meaning.
5. Put the distinctive word first, since the eye reads it first.

These rules close the most common source of confusion I described in UX mistakes that kill sales.

Why does the order of menu items matter?

In a horizontal menu, the eye notices the start and the end most. Therefore I put the most important item first and the strongest action last. Items in the middle get less attention, so supporting pages go there.

In practice, a business site often runs like this: "Services" first, then "Work" or "Case Studies", then "Blog" and "About", and finally a styled "Contact" or "Get a Quote" button. That way the visitor moves through a small decision path from left to right.

Do not set the order once and forget it. If a seasonal service needs attention, moving it to second place for a while can make sense. That said, reshuffling too often breaks the muscle memory of returning visitors. I make big order changes once or twice a year, based on data.

Also, separate the action button visually from plain links. A "Contact" link in the same color and weight as everything else simply disappears. A small outlined or filled button tells people where the next step is.

When do you really need a mega menu?

A mega menu helps when one top-level item holds many child pages and those pages fall into clear groups. Online stores, multi-service companies and manufacturers with large catalogs are typical cases.

So does a consultancy with five services need one? Usually not. A simple dropdown does the job with less maintenance. Using a mega menu only because it looks modern forces visitors to open a big panel for nothing.

My simple threshold is this. If one top-level item has eight or more child pages and they split into at least two meaningful groups, I consider a mega menu. This threshold comes from field experience; it is not a law.

The strength of a mega menu is visual hierarchy. Group headings, short descriptions and small icons show the whole range at a glance. Above all, a new visitor who does not know your product groups finds this map far faster than opening category pages one by one. In store projects, we usually make this call early in ecommerce consulting.

Which mega menu mistakes should you avoid?

The most common mistake I see is turning the mega menu into a sitemap. A panel with a hundred links gives visitors a burden, not a choice. Instead, show the five or six most wanted links per group and add a "View all" link for the rest.

The second mistake is a panel that opens and closes by accident. If the panel opens the moment the pointer crosses the bar, the top of the page flickers constantly. So I add a short opening delay and a small grace period before closing. As a result, the panel stays open when the pointer moves diagonally.

Other mistakes I avoid:

• Group headings that cannot be clicked, even though people try.
• Panels taller than the viewport, so the bottom stays out of reach.
• Heavy images that slow the panel down.
• No keyboard access, and an Escape key that does nothing.
• Shrinking the same panel for mobile.

The last point matters most. A mega menu is a desktop pattern. On mobile, you need a different layout for the same content.

Should dropdowns open on hover or on click?

In most projects I prefer click to open. A click works the same on touch screens, keyboards and mice. Hover, by contrast, relies on a behavior that touch devices do not have.

On desktop, however, hover can feel faster. When I am unsure, I combine both. The panel opens on hover, and a click on the parent item also toggles it. As a result, no group of users gets locked out.

Watch out for one trap. If the parent item is both a link to a page and the button that opens the panel, touch users cannot predict the first tap. So I either make the parent a pure button and add an "All services" link inside the panel, or I place a separate arrow button next to the label.

The W3C accessibility team shows this disclosure pattern for site navigation. The disclosure navigation example in the WAI-ARIA Authoring Practices uses simple buttons and lists instead of the application menu role. I share it with developers as a starting point.

How should a website navigation menu work on mobile?

On mobile, a website navigation menu should not be a shrunken copy of the desktop version. The screen is narrow, a thumb is wider than a pointer and patience runs shorter. Therefore I treat the mobile menu as its own design task.

My first rule is to pull the key action out of the menu. A call button, a WhatsApp link or "Get a Quote" should stay on screen while the menu is closed. Visitors should not have to open the hamburger to take that step.

My second rule is comfortable tap targets. The WCAG 2.2 target size criterion asks for at least 24 by 24 CSS pixels or enough spacing. I keep menu rows well above that, because a minimum is not the same as comfort.

My third rule is to open sub-items as an accordion. When someone taps a parent, the children open right below it. If a new screen is needed, include a clear "Back" button. Also, lock the page behind an open menu so it does not scroll. For the rest of the mobile experience, see my post on mobile first design.

Hamburger menu or bottom tab bar: which is better?

A hamburger menu saves space but hides content. Hidden things get noticed less, which means key pages get fewer clicks. Research on hidden navigation by Nielsen Norman Group also found that visible menus are easier to discover.

A bottom tab bar keeps three to five key destinations visible at all times. It sits where the thumb reaches easily, so frequent tasks get faster. However, it does not suit every site. On a small brochure site, a tab bar just takes up room.

My practical rule: for content sites and stores that people revisit often, I consider a bottom bar. For company brochure sites, I use a hamburger plus a visible contact button in the header. Sometimes I also spell out two or three critical items next to the icon.

Do not underestimate the icon either. Adding the word "Menu" next to the three lines helps discovery, especially for less tech savvy audiences. That tiny label has never hurt any project of mine.

What belongs in a utility menu?

A utility menu is the small group of links above the main menu or in the top right corner. It carries tools like language switching, customer login, phone number, cart and search. In other words, it offers functions, not content.

This split is the easiest way to simplify the main menu. For example, "Careers", "Press" or "Become a Dealer" are rarely priorities for your main audience. Still, people who look for them find them quickly in the utility area. The main menu can then focus on the buying decision.

What I watch in utility menus:

• Give it less visual weight than the main menu, with smaller type and calmer color.
• Show languages by name, not by flag, since a flag means a country.
• Make the phone number a tappable link on mobile.
• Keep it to four or five items; otherwise a second main menu appears.

On multilingual sites, placement of the language switcher matters a lot. I cover it in my multilingual website SEO guide.

How should you plan the footer menu?

The footer is the last stop for a visitor who scrolled all the way down. That person usually has not found what they wanted, or is looking for the next step. So I plan the footer as a second navigation layer, not a dump for leftover links.

A good footer usually holds these groups: services or product categories, company pages, support and legal pages, and contact details. Each group gets a short heading. Legal pages such as the privacy policy and terms belong here naturally.

The most useful thing a footer does is open doors to valuable pages that did not fit the main menu. FAQs, case studies and free tools sit well here. These links help visitors and also strengthen your internal link structure, which I explain in my internal linking strategy post.

That said, do not stuff the footer with hundreds of keyword links. They tell visitors nothing and look messy. On mobile, collapsing footer groups into accordions also prevents endless scrolling.

Menu types compared

The table below sums up when I use each menu type in the field. The notes rest on field experience, so validate each project with its own data.

Do not read these types as alternatives. Most sites run four or five of them together. What matters is that each one has its own job.

Which rules make a menu accessible?

An accessible menu works with a keyboard, a screen reader and a zoomed screen. This is a legal risk and a real user issue at the same time. Moreover, good accessibility usually produces a clearer interface for everyone.

The core checklist I share with developers:

1. Wrap the menu in a nav element with a meaningful label.
2. Make the panel trigger a real button that reports its open or closed state.
3. Let Tab reach every item in order, with a visible focus ring.
4. Let Escape close an open panel and return focus to its button.
5. Keep focus inside the open mobile menu, then return it to the button on close.
6. Ensure enough contrast between text and background.

The fastest test is to put the mouse aside and move through the menu with the keyboard only. That five minute check finds at least one broken spot in most projects. You can also check overall performance and accessibility scores with the page experience factors I describe elsewhere.

How does a website navigation menu affect SEO?

A website navigation menu shapes how search engines find your key pages and how important they seem. Pages in the menu get a link from almost every page on the site. So the pages you choose for the menu directly set your internal link distribution.

On the technical side, the critical point is crawlable links. The Google Search Central guide on crawlable links says Google can reliably follow only a elements that carry an href attribute. Menu items that work only through a JavaScript click event are therefore risky.

Anchor text matters as well. You would never use "click here" in a menu. However, vague labels like "Solutions" also tell search engines very little. Clear, descriptive labels tell both visitors and crawlers what they will find.

On the other hand, adding hundreds of links to a mega menu can dilute the weight of each page. I keep only true priority pages in the menu and support secondary pages through category pages and in-content links. We usually balance menu and SEO together in SEO consulting projects.

How should you use current page indicators and site search?

A current page indicator says "you are here". An underline, bold weight or different color on the matching item is enough. However, do not rely on color alone. Add a second cue for color blind users.

The indicator helps most when people land directly on an inner page. Someone who arrives on a service page from an ad sees "Services" highlighted and knows which part of the site they are in. As a result, they move to nearby pages instead of leaving.

Site search is not necessary for every site. On a ten page company site, the search box mostly stays empty. In contrast, on sites with hundreds of products or articles, search takes real load off the menu.

If you add search, do not hide it completely behind a magnifier icon, especially in stores. Also read your search logs regularly. Every word visitors search for because they could not find it in the menu is a free suggestion for improving it.

When does a sticky header help, and when does it annoy?

A sticky header stays fixed at the top while the page scrolls. On long pages, it lets visitors jump elsewhere without scrolling back up. This is handy on long service and product pages in particular.

The price is screen space. On mobile, a tall sticky header eats a big share of the visible content. So on mobile I keep it slim, or I hide it on scroll down and bring it back on scroll up.

I also make sure the header does not shift the layout when it becomes fixed. If content jumps the moment the header sticks, readers lose their place. That shift can also hurt layout stability, one of the Core Web Vitals. I discuss the balance in how to balance UX and SEO.

In short, a sticky header is a tool, not a default. A site made of short pages rarely needs one.

How do you test your menu before launch?

The most reliable test is giving real people real tasks. Ask five people to "find the price of a company website" or "send us a quote request", then watch what they do. Note every place where they hesitate.

A faster method is tree testing with labels only. Participants see no design, just the label list, and pick where they expect to find something. That way you measure label clarity without visual polish getting in the way.

After launch, I look at data. I track menu clicks as events in analytics and see which items never get clicked and which get more clicks than expected. Then I add heatmaps and session recordings to complete the picture. Keep menu links clean and tag only campaign links; the UTM builder makes that easy.

Do not judge results by a single metric. A rarely clicked item may not be useless. It may simply have the wrong name.

What are the most common menu design mistakes?

The same mistakes keep coming back in the menus I fix. Most are not technical; they are decision mistakes. They come from adding items without asking the right questions first.

The ones I see most:

• Every department wants its page in the main menu, so the menu becomes an org chart.
• Home appears both on the logo and as a separate "Home" item, wasting space.
• Desktop and mobile menus hold different items and confuse people.
• The action button looks like every other link.
• Menu labels do not match the page titles they lead to.
• The menu grows without a plan as new pages go live.

The fix for the last one is a simple governance rule. If an item goes in, another item goes out or moves under an existing group. That rule stops the menu from bloating over time.

Website navigation menu checklist

Use this list when you build a new site or clean up an existing menu. Each point looks small on its own. Together, they make the menu clearly sharper.

1. Did you write down the three most common visitor jobs?
2. Does each main item answer a different need?
3. Are labels written in the visitor's words?
4. Does the key action stand out as a separate button?
5. Do you really need a mega menu, or will a dropdown do?
6. On mobile, is the key action visible while the menu is closed?
7. Does the menu work the same by keyboard and by touch?
8. Are links real a elements with an href?
9. Does the footer open tidy doors to secondary and legal pages?
10. Have you set up tracking for menu clicks?

If you want menu design handled as part of a new site, take a look at my web design service. A menu works best when you plan it together with the rest of the site.

In what order should you make menu decisions?

Finally, let me tie these decisions into one sequence. First, define visitor tasks. Next, pick the pages that serve them. Then write labels, set the order and choose the menu type. Visual design comes last.

The order matters because most teams start at the other end. They design a slick mega menu first and only then think about what goes in it. In those projects, the template shapes the menu instead of the content. The result is usually needless panels and vague labels.

To sum up, a good website navigation menu comes down to few but right items, labels in the visitor's language, device-appropriate interaction and regular measurement. Get those four right and the menu stays out of the way while doing its job. As a next step, my post on setting website conversion goals helps you define what each page should achieve.