A company has several service lines, and the team wants each one in the header. Yet a long list does not explain what to choose, while a broad label such as “Solutions” may hide exactly what someone needs. The navigation needs to make sense without a team member explaining it.
This guide covers navigation between services you have already identified. Deciding which services need separate pages belongs to planning the website structure. The homepage’s role and routes from its content are covered in the business homepage guide.
Start with customer tasks, not departments
List the services you currently offer and the situations that bring people to the business. Where real enquiries are available, use their wording without personal data. Otherwise, mark your assumptions and ask someone outside the team what they expect to find behind each label.
Each item needs a label, a destination and a short explanation of what visitors will find there. Internal department, technology or package names do not become clear to customers simply because the team knows them well.
Make the label match its destination
Compare the menu label with the heading and offer on the destination page. People should recognise their choice after following the link. If “Office cleaning” opens only a general company introduction, change the route or content rather than merely shortening the label.
Instead of repeating “Learn more” everywhere, name the service where that helps people choose. Google recommends descriptive link text; this clarifies the destination but does not guarantee search rankings.
Do not impose a universal item limit. Check label length in every language, on a narrow screen and with enlarged text. Shortening a label must preserve its meaning: an unfamiliar abbreviation only moves the problem.
Group services around the visitor’s question
A group helps when its name brings services together predictably. Compare grouping by the object of the work, customer need or customer type. Choose one main principle for the menu and explain other distinctions on an overview page. Visitors should not have to guess which department owns their task.
| Situation | Possible route | What to check |
|---|---|---|
| A few distinct services | Direct links named after the services | Whether labels distinguish the offers |
| Many related services | Services → overview → specific service | Whether the overview helps people compare and continue |
| One service for different customers | One main item with an explanation on the page | Whether identical routes are being duplicated |
| An urgent enquiry with a known task | An accessible contact item alongside services | Whether the business actually handles that channel |
These are options to test, not rules based on page counts. Services can appear again in relevant contexts, but the same label should lead to the same expected result.
A learning example: a service company’s menu
Imagine a company offering apartment cleaning, office cleaning and cleaning after renovation. This is a learning example, not a client case or a claim about a particular business’s actual structure.
Instead of “Private / Corporate / Special solutions”, try a “Services” group containing “Apartment cleaning”, “Office cleaning” and “After renovation”. An overview page explains the differences and repeats those links. “Contact” remains a separate, recognisable route.
Test these tasks: find the terms for cleaning an office; work out where to enquire after renovating an apartment; find a way to discuss an unusual job. The last situation may cross two categories. That is a reason to add an explanation or a relevant link, not automatically another menu level.
Avoid making one interaction the only route
For a submenu, check that people can open it by pressing a control and using a keyboard, understand its state and close it. W3C explains the difficulties with fly-out menus and recommends another way to reach submenu items, such as links on the parent category page. Mouse hover alone is insufficient.
On a phone, check full labels, scrolling in a long menu and navigation to the destination. With a keyboard, check focus order and visibility. W3C describes semantic navigation structure; ask the developer to verify its implementation. An informal owner check does not establish conformance to an accessibility standard.
Check the whole enquiry journey using the mobile checklist, rather than stopping when the menu opens.
Hand over a map and accept specific routes
Prepare a table covering the label in every language, group, destination, parent-item behaviour and a test task. If “Services” both opens a list and leads to an overview, agree on separate, understandable controls. One action should not unpredictably substitute for another.
- Every item leads to a working page or agreed section without a dead end.
- Labels in the menu, overview and destination pages agree in every language.
- People can find the service without hovering a mouse or help from the map’s author.
- Changing the menu does not silently rename URLs; address migrations are planned separately.
Check the destination’s content against the service page structure guide. To plan navigation for your business, send a service list and describe the task; the scope of changes is agreed after reviewing it.
Questions about menus for multiple services
Does every service belong in the header?
No. Predictable routes matter. Some services can sit within a clear group and on an overview page.
Is there a correct number of menu items?
There is no universal number for every business. Test the actual labels, groups, languages and tasks.
Can a fly-out menu be the only option?
Mouse hover should not be the only route. Check keyboard and phone use and provide alternative links to nested services.
Do menu changes require new page addresses?
Not necessarily. You can change a label or its position while keeping the address. URL changes need a separate migration map and checks.