Navigation menu of a website: organize the pages

9 min read

The navigation menu of a website should help your visitor choose a destination, not expose your internal organization. For a service site, start with requests: identify a service, check an area of ​​intervention, understand a concept or apply. You can then select the menu pages, name the sections and check the route on mobile as well as on the keyboard.

A useful menu combines understandable titles, a coherent tree structure and usable commands. Validate destinations with concrete tasks, without imposing a universal rule on the number of clicks.

Start with requests, not the organization chart

Before designing the menu, make an inventory of the pages and needs. For each destination, note its address if it exists, its real content, the demand to which it responds, the public concerned and the person capable of validating its description. Spot duplicates, obsolete pages and destinations that are still missing.

Then gather the questions addressed to the sales, technical and recruiting teams, without transforming them into statistics. The wording used by your visitors is more useful in naming a section than internal abbreviations. Distinguish between a request for a service, a documentary search and an application: they do not require the same process.

Finally classify the pages according to their role: main entry, section page, detail or additional resource. An important page does not necessarily have its place in the global menu. However, it must be accessible from a relevant page: Google recommends that each page deemed important receives a link from at least one other page of the site ^[17].

Organize the website navigation menu

The following example is fictitious: an engineering office presents its services, its sectors, its resources and its recruitment possibilities. This is not a client of 4SYSTEM. We propose this tree structure as a working hypothesis:

• Services : structural diagnosis, reinforcement studies, project management assistance.
• Sectors : tertiary buildings, industrial sites, public facilities.
• Resources : technical guides, structure glossary.
• The office : working method, team.
• Recruitment : job offers, unsolicited application.
• Contact : present a project or ask a question.

Taxonomy is the logic of classification: the services describe an intervention; the sectors describe the context in which it takes place. “Solutions” would blur this distinction. A section page should explain what it brings together and direct you to its details, rather than reproducing the submenu without context.

Add a level only when it corresponds to a distinction useful to the visitor. If a branch becomes difficult to understand, examine its groupings before rolling everything back to the first level. Good arbitration is about understanding the choices, not about a universal threshold of clicks.

Titles that announce a destination

A title must make it possible to anticipate the next page. Google recommends link text that is descriptive, reasonably concise, and relevant for both the start and destination pages ^[17]. Read your wordings alone: ​​if their meaning disappears outside the model, rephrase them.

Here is a completed diagnostic grid for the fictitious office. Proposals are to be tested, not observed results.

Keep the same grammatical form between comparable sections. Avoid acronyms without explanation and titles that are so long that they become difficult to navigate on mobile. The content must keep the promise of the wording: renaming “Documentation” to “Technical Guides” requires checking the documents actually offered.

Separate links from submenu commands

For this mockup, let's separate the destinations and the commands. “Services” may be a link to the section page; a nearby button, named “Show services”, controls the submenu. Its accessible name and its state should make it possible to understand whether it is open or closed. We are considering link navigation here, not application menu behavior.

Destinations use HTML links a with an attribute href containing a real address. This is the format that Google can generally explore; a script step alone does not override this link ^[17].

The WAI requires that drop-down submenus be usable by mouse and keyboard ^[14]. Our control scenario therefore verifies, in this order:

• navigate to each link and button with Tab, seeing focus;
• open the submenu using the keyboard and access its destinations;
• close it with Esc or its close command;
• find the trigger button after closing, without losing focus;
• return to previous page without inconsistent menu state.

On mobile, also test touch opening, scrolling and closing. No destination should depend on the flyover. Check that hidden links do not remain navigable by keyboard. If the moving panel hides the page, also check that the focus does not move to invisible elements behind it. On mouse, the submenu should not disappear immediately when the pointer leaves its clickable area ^[14].

Locate the page and allow you to return

The main menu is used to choose a large destination. The breadcrumbs locate the page in a hierarchy: for example “Home > Services > Reinforcement studies”. It does not necessarily reproduce previously visited pages. The browser's back button fulfills this other function.

Contextual links accompany a question arising during reading: from a service, consult a guide on preliminary investigations or open the contact form. To organize these passages, consult our guide to internal linking between useful pages.

Also report the active page in the navigation. The WAI highlights the benefit of distinct menus and easily identifiable states, notably the current page ^[14]. The breadcrumbs therefore do not replace either the menu or the links placed in the content.

In the tests, watch how a person returns from a detail to their section, then changes sector. A short but ambiguous path deserves correction; a clearly named additional step may remain relevant.

A task-based testing protocol

Prepare an identifiable version of the tree structure, then an interactive model. Define before the session the expected destination and what will prove that it meets the demand. Choose people corresponding to the target audiences; vary the conditions between computer, mobile and keyboard, without assuming that one test covers all uses.

Here are instructions that can be used for the fictitious office:

• “You are preparing the reinforcement of an existing building. Find the right intervention and explain what it covers. » Target: Reinforcement studies.
• “You represent an industrial operator. Where to check that the office intervenes in your context? » Target: Industrial sites.
• “You are looking for the definition of a structural term. Where to consult it? » Target: Structure glossary.
• “You would like to apply without a corresponding offer. Where can I find the instructions? » Target: Spontaneous application.

Read only the instruction, not the target. Ask the person to say what they expect behind their first choice. Then observe the route without indicating the correct section. Record the chosen title, hesitations, feedback, the destination reached and a short formulation of your reasoning.

Upon arrival, ask to show the information that meets the need. A click on the intended page is not enough if its content does not confirm the choice. End with a return to the section, then a change of destination. Note technical incidents separately from classification misunderstandings.

Decide on corrections and keep the proof

Fix broken destinations and unusable commands first. Then deal with naming ambiguities, then groupings. If a wording is understood but leads to inappropriate content, fix the page rather than the menu. Do not change all parameters simultaneously: you will lose the ability to interpret the new test.

Validation sheet prepared, not tested: task “reinforcement of a building”; target “Reinforcement studies”; proposed entry “Services”; risk of examining “confusion with Sectors”; expected proof “route noted and relevant information designated on the page”.

After correction, replay the task and technical checks. Keep the version of the model, the anonymized notes, the reasoned decision and a capture of the corrected state. Validation requires an understood destination and usable feedback, not a favorable overall impression.

This scope does not constitute a regulatory audit of the site. The WAI tutorial provides best practices ^[14] ; forms, documents and other components remain to be examined according to the standards applicable to your organization.

Frequently asked questions

Can a service appear in several sectors?

Yes, if each link leads to the same service page and if the sectoral context remains explicit. On the “Industrial sites” page, present why this intervention may be relevant, then link to its description. Keep a stable main attachment for the breadcrumbs. Avoid creating multiple identical pages just to replicate all menu branches.

How to process recruitment hosted on another platform?

Keep a “Recruitment” entry that explains the professions and application procedures on your site. From this page, name the external link according to its use, for example “Consult the offers on the recruitment platform”. Report the site change. Also check the return to your site and the solution proposed if the platform becomes unavailable.

Is a menu generated in JavaScript acceptable?

Yes: Google indicates that dynamically inserted links remain crawlable when they use the expected markup, including an element a with an attribute href ^[17]. This does not guarantee their indexing or usability. Check their presence in the rendered HTML, then separately test the opening, closing and keyboard navigation on the version actually served to visitors.

Switch from tree to control

Take a priority task and prepare its form: expected destination, proposed title, test conditions and proof of validation. Then walk through the model without explaining its classification. Correct the first obstacle identified, then replay the scenario.

To have your tree structure and the constraints of its implementation examined, consult our web services, SEO and digital marketing and discuss with 4SYSTEM the scope of your project.

Sources

• Menus Tutorial | Web Accessibility Initiative (WAI) | W3C (accessed 2026-10-08)
• SEO Link Best Practices for Google | Google Search Central | Documentation | Google for Developers (accessed 2026-10-08)