Navigation and architecture
Give readers clear routes through a topic.
Website architecture assigns pages understandable roles and relationships. Navigation exposes useful routes through those pages with descriptive labels, menus, breadcrumbs and contextual links. Plan for a first visit and for someone returning to a specific task.
Begin with the task and the page role.
List the decisions readers come to complete before choosing a menu layout. A beginner may need a definition and a simple example. A specialist may need a particular specification, exception or troubleshooting answer. Both can use the same subject collection without following the same sequence.
Assign a role to each destination: introduction, comparison, procedure, reference, troubleshooting or service enquiry. The role explains what the page promises and what it should link to next. A page can support more than one closely related question, but its opening needs a clear governing task.
Separate the URL, the page title and the navigation label. A stable historical URL can remain useful after a clearer title is written. A short menu label can differ from a fuller page title while still naming the same subject. Changing all three at once creates more routing work than changing an unclear label alone.
Use labels people can predict.
A label should give a reasonable expectation of the destination without requiring the reader to know your internal department names. Compare a label such as “Resources” with a more precise “Equipment setup” when the destination concerns setup instructions. Broad labels can work for a genuinely broad collection, provided the next menu offers a meaningful choice.
Use the language of the task rather than adding search phrases to every menu item. Keep similar destinations distinguishable. If two links both say “Support” but one opens documentation and the other starts an enquiry, revise their labels or add short descriptions so the choice is clear before selection.
Check labels outside the visual layout. Read a list of links aloud or review the link names on their own. Avoid empty links and generic text that forces readers to inspect surrounding decoration to identify the destination. Meaningful text should remain ordinary HTML rather than a label baked into an image.
Assign different jobs to menus, breadcrumbs and content links.
A main menu exposes the stable, widely useful areas of the site. A local menu helps readers move within a subject collection. Keep these choices focused enough to scan, and place occasional or highly specialized routes in context rather than expanding every global menu into a complete sitemap.
Breadcrumbs describe a page’s location in a chosen hierarchy. They are not a transcript of every page a person visited. A person arriving from search should be able to use the breadcrumb to identify the surrounding collection. A page with more than one plausible parent needs a deliberate ownership decision; do not manufacture a false hierarchy solely to fit a breadcrumb component.
A contextual content link supplies a next explanation at the point it is needed. Use a descriptive anchor and a real destination in an HTML link. A breadcrumb cannot replace a link explaining a prerequisite in a difficult paragraph, and a dense menu cannot replace useful relationships between the answers themselves.
Hypothetical routes for a beginner and a specialist.
Imagine a fictional organization documenting a document retrieval system. Its beginner wants to learn what passage retrieval means. Its specialist wants to investigate why one known document is absent from a test result. These are invented audience tasks, not measured visitor journeys.
The beginner enters through a retrieval introduction, reads a small worked example, then follows a link to a controlled evaluation explanation. The specialist enters through a troubleshooting index, checks the relevant access and indexing conditions, and opens the same evaluation explanation when it supplies the needed test context. Neither reader is forced through an enquiry form to reach the promised answer.
The shared evaluation page can belong to one collection while receiving links from both routes. Its opening should state the test’s scope and prerequisites. A short reminder links back to the introduction for new readers; a specific troubleshooting link offers a return path for the specialist. Those cross-links support different tasks without creating duplicate copies of the evaluation page.
For this fictional collection, the main menu label is “Documentation.” Its local choices are “Start with retrieval,” “Assess passages” and “Troubleshoot retrieval.” The beginner selects the first; the specialist selects the third. On the shared evaluation page, a breadcrumb reads “Documentation / Retrieval / Assess passages.” It describes the chosen parent collection even if the specialist arrived through troubleshooting. A nearby content link named “Check document access before testing retrieval” serves the immediate condition rather than changing the breadcrumb to imitate browsing history.
| Reader | Entry route | Useful next destinations |
|---|---|---|
| Beginner | Retrieval introduction | Definition, worked example, evaluation explanation |
| Specialist | Troubleshooting index | Access conditions, indexing checks, evaluation explanation |
| Both | Evaluation explanation | Relevant prerequisite and specific return route |
Make the hierarchy useful without making it rigid.
Group pages under a parent that matches their main purpose, then allow contextual links across collections when the relationship helps the reader. A strict tree is convenient for a menu, but a useful answer can have relationships outside that tree. Record a canonical owner so cross-linking does not turn into duplicate page creation.
Avoid adding an extra level that merely repeats the parent’s title without helping someone choose. A large collection may need a topic index that divides a long list into recognizable tasks. The right depth depends on the size and nature of the content; there is no universal number of menu levels or clicks that proves a good architecture.
Treat a hub as an answer and a directory. It should explain the collection, distinguish the available tasks and identify useful starting points. A blank title above dozens of unrelated links leaves the organizing work to the reader.
Check findability with realistic tasks.
Give a suitable reviewer a concrete starting point and a question. Ask them to locate the answer and explain why they chose each route. Record the labels they misunderstood, dead ends, missing context and useful shortcuts. Do not report a success percentage or a preferred route without an observed study and its sample details.
Check more than the homepage route. Inspect direct entry from a bookmarked article, an internal link, a site search result and a narrow layout. Search can complement navigation, but it should not be the only way to find a necessary page. A page that can be found only through an exact query may still need a sensible collection route.
For keyboard and assistive technology use, confirm meaningful link names, clear focus, usable menu controls, logical reading order and a way to identify the current location. Review the finished page behavior with the relevant accessibility criteria; a planning diagram or attractive screenshot does not establish those behaviors.
For a breadcrumb, W3C’s ARIA pattern describes a named navigation landmark and a list of links to parent pages. The current page can be plain text; if it is a link, identify it with aria-current="page". Label the navigation so it can be distinguished from the main menu. Keep visual separators out of the spoken link names. These markup choices support the intended meaning, but the finished page still needs keyboard and assistive technology review.
Maintain routes as content changes.
Before removing or merging a page, list its incoming links, local menu entries, breadcrumbs and references from other resources. Choose the destination that continues the task, update those routes, and preserve a reasoned record. A redirect can address a retired URL, but it does not repair an inaccurate anchor or a breadcrumb that describes the wrong hierarchy.
Revisit labels when terminology changes or when observed reader tasks reveal a different distinction. Keep stable IDs for the pages and record the decision behind reparenting. Test the revised routes and explain any limitation that remains. Clear architecture supports interpretation and discovery; it cannot guarantee crawling, indexing, ranking or a particular search presentation.
Sources and related learning
Google navigation and discovery documentation. Google link documentation. WCAG 2.2. W3C breadcrumb pattern.
The worked examples are fictional. They explain planning decisions and do not represent measured search or client outcomes.
Continue with semantic SEO learning and topical map planning. internal linking principles.