Audit your app
Website Navigation Best Practices: A 10-Minute Menu Check
Website navigation best practices for founders: plain labels, a short menu, a findable phone menu, and a 10-minute check. Run it on your own site today.
The website navigation best practices that matter most are simple. Name each menu item in the words a visitor would use, keep the top level short enough to scan, and make sure the menu is easy to see and use on a phone. Then test it by asking a first-time visitor to find one thing, without hints.
By the end of this guide you will have a short routine for checking your menu. On a fast build, a menu often gets generated in one prompt, and nobody stops to ask whether a first-time visitor can find what they came for. We take only the navigation slice here: what to name things, how much to show, and how to check it yourself.
What is website navigation, and what counts as a best practice?
Navigation is everything that helps a visitor get from where they are to where they want to be: the main menu, the footer links, breadcrumbs (the small "Home > Section > Page" trail), a site map page, and search. The W3C's web accessibility curriculum lists 4 of those tools (menus, breadcrumbs, site maps, and search) and notes that different people rely on different ones.
For us, a "best practice" is a habit that helps a visitor finish a task. It is not a rule about how many items a menu may hold, and it is not a look. Pick one thing a visitor wants, and watch where they hesitate.
Source: W3C WAI, page last updated 9 February 2022, [read 8 October 2026](https://www.w3.org/WAI/curricula/designer-modules/navigation-design).
How many menu items is too many?
We would be wary of any guide that hands you a magic number without a source, so we won't. What we can do is tie the count to the screen. Nielsen Norman Group (NN/g), a long-running usability research firm, says a phone site with only about 4 to 5 top-level options can simply show them all. With more, it suggests a combination: show a few links and collapse the rest.
Here is how we would sort. Start from what visitors came to do, not from how your site is organized inside. Say you have 9 items and 3 of them are things you want to say about yourself. Those 3 can probably move under "About" or into the footer.
Source: NN/g, 24 July 2016, [read 8 October 2026](https://www.nngroup.com/articles/find-navigation-mobile-even-hamburger/).
What should you call each menu item?
Use the word your visitor would use, and make it say what is behind it. NN/g's desktop article recommends clear, information-scent-heavy labels: words that hint at what a click will bring. The W3C curriculum likewise asks for clear, descriptive names on navigation components and page titles.
Try this with a friend: cover everything but the menu and ask what they expect behind each word. Words like "Solutions" and "Offerings" can draw a shrug, while "Pricing" and "How it works" are plainer. That is our view, not a study.
A menu is also part of what your page promises, so this touches our first rubric area, Clarity and Promise. A vague label is a small broken promise. For the words on the page itself, see Website Content Audit: Does Your Copy Do Its Job?.
Sources: NN/g desktop article, 24 July 2016, [read 8 October 2026](https://www.nngroup.com/articles/find-navigation-desktop-not-hamburger/); W3C WAI as above.
How deep should the menu go?
Every extra layer is another guess. We won't give you a limit of 2 or 3 levels, because we can't source one. We would ask a different question: when a visitor starts at the home page, do they know where to begin for each of your 3 most common tasks? If not, the structure is the problem, whatever the number of levels.
When a site has more pages than a top menu can hold, 2 things help. One is a second way to get there: search, a footer list, or a breadcrumb trail, which the W3C curriculum says is especially useful when pages are nested several levels deep. The other is a clear signal of where you are, covered below.
Should the menu be visible or hidden behind a hamburger menu on a phone?
Show it if you can. In NN/g's 2016 study of hidden navigation, hiding it hurt use on phones, though less than on desktop, and the result varied by site. The sites that did best mixed visible and hidden links. When a menu has to be hidden, the advice was to give it more presence, set it apart from the logo, make it look tappable, and add a text label, because not everyone recognizes the 3-line icon.
That study is a decade old, tested a small set of sites, and says itself that the right answer depends on context. We use it as a direction, not a verdict, and the real answer lives on your own phone.
Our Mobile and Access question comes at the same thing: is the primary action visible on a real phone screen, without scrolling, pinching, or guessing? A menu that fills the screen, or anything that hides it, fails that question.
Source: NN/g, 24 July 2016, [read 8 October 2026](https://www.nngroup.com/articles/find-navigation-mobile-even-hamburger/).
Can people tell where they are and use the menu without a mouse?
Yes, if you get 3 small things right, and we like them because they cost almost nothing.
- Mark the current page. The W3C developer module says the current item should be marked in a way assistive technology can read, and that states such as hover, focus, and visited should be told apart by more than color.
- Keep it consistent. Same menu, same place, every page.
- Try the keyboard. Press Tab. Can you reach every item, and does a fly-out menu open without a mouse? The W3C module says fly-outs should work with both.
A keyboard pass is not an accessibility audit, and we don't claim it is. It does catch the worst menus.
Source: W3C WAI, page updated 4 March 2021, [read 8 October 2026](https://www.w3.org/WAI/curricula/developer-modules/menus).
Are your menu items real links?
Short answer: they should be. Google's documentation says it generally follows standard links (an anchor tag with a web address) and may miss links built other ways. To check on your own site, right-click a menu item. If your browser offers "Open link in new tab", it is probably a real link. If a menu item fails that test, tell your builder tool: "Make every menu item a standard link to its own page."
Source: Google Search Central, last updated 10 December 2025, [read 8 October 2026](https://developers.google.com/search/docs/crawling-indexing/links-crawlable).
What does a 10-minute menu check look like?
Here is the routine we would run. Steps 1 to 5 take about 10 minutes on your own; step 6 is an extra.
- Write down 3 tasks. The things a first-time visitor most likely came to do.
- Click through each one from the home page. Keep a diary: where did you hesitate, and which label made you guess?
- Read each label aloud with no context. Would a first-time visitor know what is behind it?
- Open the site on a phone. Can you see the menu, the main action, and the current page?
- Press Tab 10 times. Does the focus show, and does it move in a sensible order?
- Optional, if you have a friend nearby: ask one person to try one task, and say nothing. Our guide Website Usability Testing: A 3-Task Script You Can Run This Week shows how, and How to Get Honest Website Feedback Before You Launch covers who to ask.
Hypothetical example: a volunteer-matching site for animal shelters. The most common visitor task is to find a Saturday dog-walking shift nearby. The founder runs the check and writes down 4 notes. "Get Involved" opens 5 submenus, and the founder hesitated on every one. "Programs" and "Solutions" meant nothing without context. On a phone, the menu items sat so close together that a thumb kept hitting "Donate" instead of "Find shifts". And the "Events" item opened the home page again instead of an events list.
What do good and weak website navigation examples look like? Here is the before and after from that site.
| Note | Change | Reasoning |
|---|---|---|
| Get Involved with 5 submenus | A "Find shifts" button | Names the task and puts it 1 click away |
| Programs, Solutions | "How it works" and "For shelters" | Each says who it is for or what it does |
| Phone menu items too close together | More space between items, "Find shifts" first | A thumb can hit the right one |
| "Events" loops back to the home page | Point it at the real events list | A menu item should go somewhere |
Nothing here is clever. Each change removes a guess.
What does our audit record about your navigation?
Our audit is AI-scored against a fixed rubric of six areas, and no person reads your app. It has no separate navigation score. It does click through your public pages, and its Recorded evidence block counts pages crawled, links checked, broken links, buttons clicked, and dead buttons, with anything it could not finish marked "Not fully clicked" or "Not confirmed".
For menus, that means a link that fails or a button that does nothing can show up there, if the audit clicked it. 2 rubric areas are closest to this guide. Flow and Usability asks what happens after someone signs up, clicks buy, or hits a dead end. Mobile and Access asks whether the primary action is visible on a real phone screen, and the report looks at a phone-sized screenshot next to a desktop one. Fixes come ranked, so you know what to change first.
The audit reads public pages only, so a menu behind a login is out of reach. It is also not a security review or a full accessibility audit.