Designing a website navigation structure for business

Site navigation breaks at scale: where visitors are lost

The failure does not appear immediately, but at scale. The catalog grows from dozens of items to thousands, new directions and content types are added, while the section and menu structure remains as it was assembled at launch.

The top level holds all categories at once, drop-down lists extend beyond the screen, and some items lead to intermediate pages where there is nothing but a further link.

Deeper in, dead-end transitions begin. A product card does not link to neighboring items and analogues, a section has no subsections, filters generate URLs that lead nowhere, and the thank-you page remains without an exit.

A visitor who lands deep in the site directly from search cannot continue the journey and returns to search results — there are fewer transitions into the catalog, and fewer pages viewed per visit.

The cost of this state is measurable. The share of deeper transitions falls, bounce rates on internal pages grow, some sections receive no inbound links at all and drop out of crawling by search engines.

At the same time, the volume of same-type URLs that have to be crawled again grows, and weight is diluted among duplicates instead of real entry points.

A tangled section structure and overloaded menu are not cosmetic; they are the reason demand goes to a competitor with a shorter path to the desired page.

We break down how this is addressed at the project level: how the section tree is rebuilt around demand, what goes into the top-level menu and what moves into contextual navigation, and how it is verified that there is a meaningful exit from any point.

Effect of restructuring: search speed and view depth

Reworking navigation delivers an effect that is recorded in metrics, not debated by taste.

The first thing that changes is the time to find a section: when the top level of the menu reflects user tasks rather than the company's internal structure, the path to the target page is reduced from four or five clicks to one or two.

We count steps to the goal explicitly — menu item, refinement, transition to the card: every extra step cuts off part of the audience before it even sees the content.

View depth also grows: connected sections with cross-links keep a person within the subject area instead of returning to search.

The bounce rate decreases not by itself, but on those landing pages where the visitor immediately understands where to go next and does not leave to check the wording of the task again.

We take measurements before and after on comparable periods: transition map, view depth, and the share of abandoned scenarios in Yandex Metrica, separately for mobile traffic and search transitions.

Site-wide averages are useless here — they mix different behavior patterns and hide what exactly the new structure delivered.

A mandatory condition for a fair comparison is redirects and preservation of previous section URLs. Otherwise, a drop in view depth will be a consequence of broken links rather than the rework, and the measurement will have to be repeated on a clean base.

Ways to build section structure: what fits and when

A section scheme is a compromise between click depth and URL predictability.

The choice is dictated not by taste, but by the number of real axes of difference in the catalog: if items differ simultaneously by type, size, and purpose, menu levels begin to duplicate filters, and navigation starts to contradict itself.

What to check before choosing

Flat and multi-level schemes differ in the cost of internal linking: flat gives short URLs and simple crawling, but holds only with a small number of sections.

The combined one preserves pages for high-frequency queries and does not increase depth, because clarifying attributes go into filters.

Any option should be run through a click map: how many clicks to the card, whether there are dead-end sections, whether duplicates with identical content and different URLs have appeared.

Canonical URLs, breadcrumbs, and a sitemap lock in the chosen scheme — without them, in six months the structure will sprawl from point edits.

Work stages: from analyzing the current structure to handing over guidelines

We work in stages, where each next one relies on an artifact from the previous one — this way navigation decisions remain verifiable rather than taste-based. Below is the sequence we follow on projects where the section tree has stopped coping with the volume of content.

1. Structure audit. We collect the current section tree, exports from analytics systems, search queries, and support requests. We record sections without traffic, duplicates, pages without inbound links, and click depth to key materials.
2. Click map. We build a transition map: where users come from, where they stop, at which step they leave. It shows which sections exist for the visitor and which exist only for internal logic.
3. Section scheme. We design a new tree: levels, item wording, grouping rules, cross-cutting blocks. We separately describe URL changes and what goes into redirects.
4. Navigation prototype. We assemble a clickable prototype of the menu, footer, and breadcrumbs. It is cheaper than edits in templates: contentious decisions are filtered out before development.
5. Scenario testing. We run typical tasks — finding a service, comparing options, returning to a section, mobile transition. We count steps and transitions on each path, and mark places where context is lost.
6. Implementation. We transfer the scheme into templates, configure redirects, update the sitemap and markup. We roll it out in parts to track drops in individual sections.
7. Handover of guidelines. We provide the development rules: how many levels are allowed, how to name items, where to place new material. The structure then grows without us and does not sprawl.

What you keep: schemes, rules, and working materials

Navigation stops depending on specific people when the rules live in project documentation rather than in chat.

You receive a set of materials by which an editor can add a section without looking into the code, and a new contractor can restore the logic of the structure without an introduction from us.

• Section map — a navigation tree down to the third level: which nodes exist, what is nested, where the entry points are, and where the visitor hits a dead end.
• Naming rules — how menu item headings, page names, and their URLs are formed so that the structure remains predictable regardless of who makes the edit.
• Internal linking scheme — mandatory and recommended links between sections: what links to the parent level, what links to an adjacent one, and what works only as a cross-link.
• Menu priority matrix — which items go into the main navigation, which go into the footer, and which are available only from site search.
• Editor instructions — a step-by-step scenario: create a page, place it in the right location, fill in required fields, check the result.
• Content replenishment guidelines — who is responsible for a section, how often the structure is reviewed, and by what criterion a menu item is removed.
• Edit acceptance checklist and change log — checks before publication (nesting depth, URL duplicates, broken links) and the history of restructures with reasons, so you can return to a previous navigation option.

The materials describe not “how we do it” but “how to maintain it”: any item can be handed over to a new editor or contractor, and the structure continues to develop by the same rules.

Case study: how rebuilding sections restored catalog search

The client is an industrial fasteners supplier: a catalog of tens of thousands of items was assembled over years, and the navigation had never been rebuilt. Products lay in one flat list of seven sections that did not match how the buyer searches.

According to Yandex Metrica, view depth stayed at 1.4 pages, 62% of sessions ended on the catalog entry page, and every third internal search query returned no result — synonyms had not been configured.

First, we analyzed demand: based on search logs and questions from the sales department, we assembled real product groups.

The sections were rebuilt into three levels — direction, subcategory, group by key parameter — and linked with cross-links and a “frequently bought with this” block.

Old URLs were closed with redirects, the sitemap was rebuilt, and section names were tied to buyer wording rather than to the internal reference book.

After a quarter, view depth grew from 1.4 to 3.6 pages, the share of sessions with three or more pages — from 12% to 41%, exits from the first catalog page fell from 62% to 34%, and empty search results — from 30% to 9%.

The structure stopped hindering growth: a new section is added in hours and immediately receives internal links instead of remaining an orphan.

What site navigation suits a catalog with thousands of items?

For a catalog with thousands of items, a multi-level menu stops scaling: the menu limit is three levels; beyond that, the visitor cannot retain the path and goes to search.

The working scheme is different: the top level is responsible for major sections, while everything deeper is covered by the catalog with filters and curated collections.

We build nesting levels according to the attributes by which the buyer describes the product: category, purpose, compatibility.

If a branch appeared because of warehouse accounting, it has no place in the menu — such attributes go into filter attributes, where they combine freely and do not break the tree.

Curated collections cover what is described neither by the tree nor by attributes: purchase scenarios, seasonal queries, comparison.

Search engines, including Yandex, index them as independent entry points — that is why they are included in the catalog project from the start rather than added on top.

We test the solution on live traffic: the share of sessions where the visitor reached a card without search, depth of filter use, number of dead-end result pages, time to first transition into a product.

If filters do not shorten the path, the cause is usually not the menu, but the set and order of attributes.

Technical doubts worth resolving before work starts

Doubts at this stage are usually not about “is it right” — but about what you will have to pay for changing the scheme.

Three questions are asked most often: how many sections to leave in the top level, what to do with already indexed URLs, and how much editing will be required in existing templates. Below is how this is resolved on a project before anything goes to production.

What will happen to current page URLs?

URLs that already collect traffic and links are preserved or transferred to the new scheme with a permanent one-to-one redirect — without chains of two or three hops, which lose weight and confuse crawlers.

The redirect map is compiled before release and checked with a script: every old link returns a single response to an existing page, not a 404 and not a redirect to the root.

How much rework does this entail?

The structure and templates change: menu, breadcrumbs, internal linking within sections, sitemap. Page content remains — it is not rewritten because of a navigation change.

The main work falls on the template layer and internal links, so the scope of edits is predictable and estimated before the start, not “as we go.”

Will positions drop during the transition to the new scheme?

The transition is planned in stages: first the new scheme is assembled in a test environment, then released together with the redirect map in a single release.

After rollout, we look at 404 logs, the crawl map, and queries — the new URL appears in search results within days, not weeks. Rollback to the previous structure is possible as long as the redirect map is preserved: this is the insurance against a sharp traffic drop.

Let's discuss the task and come back with an estimate and work plan

To come back with a task estimate and work plan rather than general wording, we need project inputs. The more specific the source data, the more accurate the timelines and the fewer reworks at the stage of layout and transition setup.

• current section map: top-level URLs, nesting depth, orphan pages that are not in any menu;
• list of entities and relationships between them — product or service, category, brand, region, article — to understand which navigation axes are actually needed;
• an export from search analytics for several months: queries, entry pages, bounce rate — this shows where demand does not match the menu;
• technical constraints: website management system, access to editing the menu and redirect rules, who makes changes after launch;
• external entry points: mobile app, marketplace, separate pages for advertising campaigns, subdomains, old URLs with external links;
• requirements for language and regional versions, if sections must differ by country or language;
• approval guidelines: who makes the final decision on the structure and within what timeframe provides feedback.

Then we will clarify what cannot be read from the data: which scenarios should lead to a request, what goes into the footer, and what deserves the top level, how many nesting levels the content team can sustain during population.

In response, we will send a section tree with justification for each node, URL formation rules, a redirect map from old pages, and a stage-by-stage work plan with timelines and acceptance points. Describe the task — we will come back with an estimate and plan.