Good website navigation helps a visitor recognise the right starting point, choose a useful page and understand what to do next. Begin with the questions people bring to your business, give those questions clear destinations, and test the routes on a phone and with a keyboard. A smaller menu only helps if the important routes remain easy to find.
This checklist is for business owners planning a new website or reviewing an existing one. Use it to make decisions with your designer before approving a polished header. The useful deliverable is a short, agreed map of visitor tasks, pages and links.
Start with the visitor’s task
Write three to five situations in your customers’ words: “I need to know whether you cover my area”, “I want to compare your services”, or “I already work with you and need help”. These are examples to adapt, not a fixed limit. Review actual enquiry questions and ask the people who answer them where visitors get stuck.
For each situation, record the audience, their question, the page that answers it and the next useful action. A prospective customer might need a service explanation before an enquiry; an existing customer may need a support route immediately. Making both people start with the same sales form creates an avoidable detour.
Separate the visitor’s task from your internal organisation. A department name belongs in navigation only when customers understand it. If two teams both suggest “Solutions”, ask what a visitor expects behind each link. Record the agreed labels and destinations in your website project brief.
Decide where each route belongs
The header is one part of navigation. Links inside the content can connect a question to its answer at the moment it arises. Use this decision table to decide where a route earns its place.
| Visitor need | Useful starting choice |
|---|---|
| A main reason to visit the business | A clearly named main navigation link |
| Several related services to compare | An overview page; add a submenu if it helps selection |
| A detail needed while reading | A descriptive link within the relevant page |
| Policies or company reference information | A footer link, with contextual links where needed |
| Many items people know by name | Consider search alongside a browsable structure |
There is no universal correct number of menu items. Judge the actual labels, available space and competing tasks. A contact route may deserve a prominent position even if another item receives more visits. Do not bury an essential destination just to satisfy a visual limit.
Make the label match the destination
Replace vague labels such as “Discover” with words that explain the choice: “Maintenance services”, “Service areas” or “About our team”. These examples suit some businesses, not every website. Ask someone outside the project what they expect to find after selecting each label, without showing them the destination first.
WAI’s link-purpose guidance explains how link text or its associated context should make the purpose understandable. Prefer labels that make sense on their own.
After arrival, the page heading should confirm the choice. “Office maintenance” should not open an unexplained page titled “Our expertise”. On deeper pages, consider a breadcrumb when it usefully explains the hierarchy. Keep it separate from a visitor’s browsing history.
Repeated navigation should retain its relative order across pages, as explained in WAI’s consistent-navigation guidance. Agree one set of labels, including translated versions, rather than editing each header independently.
Check the mobile menu and keyboard route
Review the working menu on a narrow screen using its longest translated labels. Open it from an article, a service page and the enquiry page. Can visitors still distinguish the choices and close the menu without losing their place? A desktop screenshot cannot answer those questions.
WAI’s menu-styling guidance covers visible focus, room for enlarged text and states distinguishable beyond colour. Check these in the implemented design.
Put the mouse aside. Use Tab and Shift+Tab to move through the route, activate links with Enter, and check that menu buttons work with Enter and Space. The focus must not disappear behind a closed panel. If a menu opens as a modal overlay, ask the developer to demonstrate its focus handling and dismissal.
For submenus, require keyboard and touch operation and an alternative route through the parent page; see WAI’s fly-out menu tutorial. If the parent also opens a page, make its link and the submenu control unambiguous. Have the developer demonstrate what happens when each is activated.
WAI’s menu-structure tutorial explains labelled navigation regions and a programmatically identifiable current page. These help make the visible structure understandable to assistive technology.
A worked example you can reuse
Imagine a facilities-maintenance company; this is a hypothetical example, not a client result. Its proposed header says “Solutions”, “Expertise”, “Resources” and “Connect”. A new office manager wants to check whether the company handles routine maintenance in their town before requesting a conversation.
Map that task as: service overview → office maintenance → service areas → enquiry. A revised header could expose “Services”, “Service areas”, “About” and “Contact”. The office-maintenance page would link directly to coverage information and then offer an enquiry. Existing customers would have a separately named support route.
Test the map before arguing about colours. Give a reviewer the office manager’s situation without naming the intended menu choice. Note the first link they choose, any labels they question and whether the destination answers the task. If they look under “About” for coverage, investigate that expectation before adding another menu level.
Keep a compact decision log rather than a general note that “navigation needs work”. Use one line per task: starting page, expected destination, actual choice, reason for hesitation, proposed change and person responsible. A wrong first choice could indicate confusing words, a missing link or a page that fails to answer the question. Do not assume the menu alone is at fault. Repeat the same task after the change and record what remains unclear. Also start from a shared link to a service page: visitors should be able to orient themselves without first seeing the homepage.
Make important pages reachable by meaningful links
Ask your developer to verify real <a href="…"> links with descriptive text. Google’s link guidance explains crawlable links and useful anchor text.
For search and AI discovery, our practical starting point is the same understandable page structure: explicit topics, meaningful links and useful destination content. This is an editorial approach, not a promise of indexing, ranking or inclusion in an AI answer. A readable route cannot control another service’s selection decisions.
Owner acceptance checklist
- Each priority visitor task has an agreed destination and next step.
- Menu labels describe the pages they open, including in every published language.
- A reviewer can attempt the priority tasks without coaching; uncertainties are recorded.
- The mobile and keyboard routes have been demonstrated on working pages.
- Submenus, current-page cues and menu closing behaviour have been checked.
- Important pages have working internal links; changed URLs have a redirect plan.
- Someone owns the navigation map and reviews it when services or pages change.
This is a focused acceptance review, not an accessibility certification. The WAI menus tutorial provides further implementation guidance. If the project also changes page structure, use the website redesign checklist to plan the wider work.
Bring your visitor tasks and current page list to a website project discussion. Explore Digital Studio’s website service or start your website brief with the routes your customers need most.
