Why Your Ecommerce Category Navigation Confuses Customers

Everyone who works at your company can find any product on your site in about three clicks. That sounds like a good sign, and mostly it tells you who the navigation was built for. They can do it because they know which team buys the product, which supplier it comes from and what the business calls it internally, and your category tree is built on exactly those distinctions. Your customers know none of it.

This post is for ecommerce managers and heads of digital who have looked at their navigation, felt that something is off, and not been able to name it. The pattern behind most of it is the same: the category structure came out of the system that manages stock, and it still organises products the way that system needs them organised.

Where your category tree actually came from

Almost nobody sits down and designs an ecommerce taxonomy. When a store gets built or replatformed, the category list has to come from somewhere, and the fastest source is the one that already exists. That is usually the ERP or merchandise management system, sometimes a PIM, and often a mix of both with supplier-supplied categorisation stirred through it.

Those systems classify products for good reasons that have nothing to do with browsing. They group by buying department, because that is how purchasing is organised and how budgets are set. They group by supplier or brand agreement, because that is how terms are negotiated and margin is tracked. They carry season codes, warehouse zones and general ledger mappings. Every one of those distinctions matters to somebody in your business.

None of them describe how a customer thinks about what they want. A shopper arrives with a task and scans your navigation for a label that sounds like it.

What an inherited taxonomy looks like to a customer

Attributes that became categories

The most common symptom is a tree where brand, style or product subtype has been promoted into its own category. Separate categories for each brand of running shoe. “Skinny fit” and “slim fit” as sibling categories rather than a filter on jeans. “Corner desks” and “L-shaped desks” sitting apart from each other.

This is almost always an inheritance. Buying teams are frequently organised by brand or supplier, so brand is a real level in the source system’s hierarchy, and it comes across as a category because that is what a category is in the export.

The cost is that customers cannot compare across the split. Baymard Institute’s benchmark finds 75% of sites fall into some form of over-categorisation, and their testing recorded users abandoning sites because they could not view two styles at the same time. Worse, when a shopper does not find something in the category they expected, they often conclude you do not stock it at all. That is a lost sale now and a customer who does not come back.

If two categories hold the same kind of product and differ only by an attribute, the attribute belongs in a filter.

The whole catalogue behind one link

Plenty of sites put every product category behind a single top-level item called “Shop”, “Products” or “Departments”. On desktop it is a mild irritation. On mobile it is a wall: the customer opens the menu expecting to see what you sell and instead sees a menu about your website.

Baymard’s testing found 33% of mobile sites make product finding through the main navigation harder than it needs to be by nesting categories this way, with participants abandoning the menu for search or saying outright that they did not know how to use the site. Again this is structural: the frontend renders the root of the source hierarchy as one entry point, because that is what the root is.

Departments that match your org chart

Look at your top-level labels and count how many correspond to an internal team. A hardware retailer with “Building” and “Garden” as separate departments has two buying groups, and a customer building a retaining wall needs products from both. An apparel retailer with “Accessories” as a top-level item has an accessories buyer, while the customer looking for a belt is looking under menswear.

The tell is a label that only makes sense once you know the business. “Consumables”, “Hardgoods”, “General merchandise” and anything with a supplier’s trading name in it all fall into this bucket.

Products that can only live in one place

Most operational systems assign a product a single primary category, because for stock, replenishment and reporting a product needs exactly one home. Customers expect the opposite. A camping stove belongs in camping, in outdoor cooking, and quite reasonably in gifts for someone at the right time of year.

When the frontend mirrors the one-home constraint, products become findable through exactly one path, and every customer who takes a different path concludes you do not have it. It also raises the value of lateral movement, which most sites leave out. Baymard reports that 47% of top sites give customers no way to move sideways between categories, offering only the product list, its filters and breadcrumbs back up the hierarchy, so a customer who lands in the wrong category has to reverse out of it to reach the neighbouring one.

Depth that costs nothing internally

Adding another level to a hierarchy in an ERP costs nothing and often solves a real reporting problem, so operational trees grow deep and wide without anyone deciding they should. Rendered as navigation, that shows up as menus with thirty or forty subcategories in a single column, and as leaf categories holding three products or none at all, because they exist to satisfy a reporting need somewhere else in the business.

Baymard’s 2025 benchmark finds 60% of sites do not divide categories into manageable chunks, with their testing showing customers start to feel overwhelmed somewhere past around ten options.

Alongside all of this sits the vocabulary problem. Category labels taken from supplier feeds use supplier language, which is the same failure that shows up in site search when your catalogue says “flashlight” and your customer says “torch”.

Two different problems, two different owners

Baymard’s current benchmark rates 58% of desktop sites and 67% of mobile sites as mediocre to poor on homepage and category navigation, built on more than 16,000 performance scores, with its best and worst practice examples drawn from 180+ leading US and European sites. No site in it performs exceptionally well overall. Their published findings cover both presentation and structure, and the distinction is worth holding onto because the two have different owners.

Some of these are presentation defects. Baymard finds 33% of sites with dropdown headers that cannot be clicked, 61% with no hover delay so the panel flickers as the pointer crosses it, and 95% giving no indication of which section the customer is currently in. A competent frontend developer can fix all three in a sprint, on any platform, and you should.

Structural problems are the ones no frontend developer can reach. If your categories are wrong because your source hierarchy is wrong, no amount of menu design will help, and rebuilding the menu is the most expensive way to discover that.

Two taxonomies, one catalogue

The fix is to stop treating one hierarchy as capable of serving both jobs. Your ERP or merchandise system keeps its structure, because finance, purchasing and replenishment depend on it and there is no version of this where you rewrite it to suit the website. Alongside it, you maintain a customer-facing taxonomy that your merchandisers own.

What makes that maintainable is defining the customer-facing categories by product attributes rather than by parent-child position. A category becomes a rule (“everything with product type = stove and use = camping”) rather than a fixed slot, which means products can appear in as many places as they belong, seasonal and occasion categories become possible at all, and adding a category does not require anyone to touch the ERP.

Every major platform supports some version of this. Shopify has automated collections, Adobe Commerce has rule-based categories, and BigCommerce and WooCommerce have equivalents. Setting the rules up is the straightforward half.

The expensive part is your product data. Attribute-driven categories only work if the attributes are populated across the catalogue and reach the storefront intact. That means consistent values for every field the rules depend on, which is one of the clearer arguments for a PIM if you do not have one, and an integration from the ERP that carries those fields on every sync instead of dropping them. Teams that skip the data work end up with rules that stop matching as the catalogue turns over, leaving them worse off than the tree they started with.

Diagnosing your own navigation

None of these need a researcher or a budget. Work through them on your own store.

• Open your site on a phone and tap the menu. Can you see actual product categories, or a list of links about the website?
• Count the subcategories under your largest department. Past about ten with no visual grouping, customers are scanning rather than reading.
• List your top-level labels beside your internal team names. Count the matches.
• Find three categories that differ from a sibling only by brand, colour, size or style. Those are filters.
• Pick a product that legitimately belongs in two categories and check whether it appears in both.
• Sort your category list by product count and look at the bottom of it.
• Pull your internal search log and look for queries that are category names. A customer searching for a category they should have been able to click is telling you the navigation failed.
• Ask someone who does not work in your industry to find a specific product using only the menu, and watch without helping.

That last one is uncomfortable and worth more than the rest combined.

What to fix first

In rough order of return on effort: expose real product categories at the top level of the mobile menu, collapse attribute-based categories into filters, chunk any menu running past ten items, then fix the presentation defects in the theme. Those are all achievable inside the frontend and your platform’s category tools.

Retiring the inherited structure underneath comes last, because it is the largest job and it reaches back into your product data. It is also the one that stops the problem coming back, since a navigation rebuilt on top of the same source hierarchy drifts straight back to where it started within a couple of catalogue cycles.

If you would rather have your navigation scored against the research than work through it yourself, our UX audit is led by a Baymard-certified UX Professional and covers homepage and category navigation as one of its areas. If the problem turns out to be your product data rather than your menu, that is the part we spend most of our time on, so get in touch and we can look at it with you.