Product Taxonomy Design: A Practical Guide for Ecommerce Teams

Catalog specialist categorizing a jacket

Product taxonomy design is the work of deciding how every product in your catalog is named, grouped and described, so shoppers can find items, your systems can use the data, and your team can keep it consistent as the catalog grows. A good design keeps the category tree shallow, moves specifics like color and size into controlled attributes, uses tags for flexible groupings, and assigns an owner and a change process to all of it. This guide walks through the parts, the decisions, a worked example and the governance that keeps it from decaying.

Quicktoimpress
quicktoimpress.com
Build a Catalog That Scales
Quick To Impress builds commerce platforms and connected systems that help teams manage complex technology stacks as their catalogs grow.
Explore growth engineering

TL;DR

  • A taxonomy is the framework (categories, subcategories, attributes, tags). Categorization is the act of placing one product into it.
  • Keep the browse tree to roughly three or four levels. Put color, size, material and other specifics in attributes, not in category levels.
  • Validate the structure with real shoppers using card sorting and tree testing before you migrate thousands of SKUs.
  • Treat the taxonomy as shared infrastructure: written naming rules, one owner per field, versioned changes, and periodic audits.
  • Design the data model first and the navigation second. They are related but not the same thing.

Table of Contents

What a product taxonomy is, and what it is not

A product taxonomy is the hierarchical structure that organizes a company’s product data, including categories, subcategories and the relationships between them (inriver). Shopify’s guide breaks it into three working parts: categories support browsing, attributes support filtering and comparison, and tags create flexible groupings that cut across categories (Shopify).

The difference between taxonomy and categorization trips up many teams. The taxonomy is the framework. Categorization is the assignment process: taking a specific product and placing it at the right node (Hypotenuse). You design the first once and revisit it deliberately. You do the second every time a product is added.

There is a second distinction worth drawing early. The taxonomy is the data model behind the catalog, while site navigation is only one way of showing that data to shoppers (WisePIM). Teams that skip this distinction end up bending the data model to fit whatever the menu needs this quarter, and then wonder why feeds, search and reports disagree.

In a marketing context, “taxonomy” means the same thing at a different scale: a controlled set of labels that lets you group things consistently. For a commerce team, those labels decide what appears in navigation, in filters, in ad feeds, in analytics and in site search.

What a product taxonomy is, and what it is not

The four building blocks

Categories

Categories are the hierarchical backbone. WooCommerce’s documentation describes them as hierarchical, in contrast to tags, which are non-hierarchical descriptors (WooCommerce). A product usually has one primary category, which is its home in the tree, even if it appears elsewhere through collections or tags.

Attributes

Attributes are reusable properties such as size, color, fabric or voltage. They power filters and comparison tables, and in platforms like WooCommerce they also support variable products (WooCommerce). The key discipline is that attribute values come from a controlled list, not free text. “Navy,” “navy blue” and “Navy Blue” should not coexist.

Tags

Tags are the loose, flexible layer: “new-arrival,” “summer-edit,” “gift-under-50.” They are useful for merchandising and campaigns because they can be added and removed without touching the tree. They are a poor place for anything the business must report on reliably.

Relationships and IDs

Names change often. Stable internal IDs let you rename a category without breaking feeds, redirects, reports or integrations. This is the least glamorous part of the design and the one teams most regret skipping.

Types of taxonomy structures

Taxonomies may be hierarchical or faceted, and a faceted one combines distinct hierarchies to describe different aspects of the same item (Nielsen Norman Group). In ecommerce you almost always want both: a hierarchy for browsing and facets for narrowing.

It also helps to know that “taxonomy” can mean several different structures serving different jobs. Bloomreach lists navigation, attribute, reporting, syndication and search taxonomies as widely cited types (Bloomreach). A mid-sized catalog often needs at least three of them, and they do not have to be identical.

Structure Main job Who it serves Risk if misused
Navigation taxonomy Browsing and menus Shoppers Becomes a dumping ground for marketing-driven categories
Attribute taxonomy Filters, comparison, variants Shoppers and search Free-text values create duplicate filters
Reporting taxonomy Merchandise and margin analysis Finance and merchandising Drifts away from what shoppers see
Syndication taxonomy Marketplace and feed mapping Channel teams Breaks when external category lists change
Search taxonomy Synonyms and query mapping Site search Ignored until zero-result queries pile up

There are also external standards. GS1’s Global Product Classification is a common language for grouping products worldwide, built from segments, families, classes, bricks and brick attributes (GS1). Its implementation guide describes a rules-based four-tier system of segment, family, class and brick, with attributes and values attached to bricks (GS1 guide). Standards like UNSPSC serve procurement and spend management (AtroPIM).

Here is the practical takeaway: a webshop category tree is designed for browsing, and a classification structure is designed for data integrity. Building one structure to do both usually means it does neither well (AtroPIM). Keep one internal master taxonomy, then map it to external standards and channels rather than adopting someone else’s tree as your storefront.

A worked example: a clothing catalog

Take a linen button-up shirt. In Shopify’s example, it sits at Women > Tops > Shirts. Size, color, fabric and sleeve length are attributes, and tags such as new-arrival and summer-edit give flexible cross-category groupings (Shopify).

Here is how that looks as a record:

Field Value Type
Category path Women > Tops > Shirts Hierarchy
Fabric Linen Controlled attribute
Sleeve length Long Controlled attribute
Color Sage Controlled attribute (variant-level)
Size M Controlled attribute (variant-level)
Tag summer-edit Flexible tag

Notice what is absent. There is no “Women > Tops > Shirts > Linen > Long Sleeve > Sage” branch. Encoding every variant in the tree multiplies categories, creates near-duplicate pages and makes the menu unusable. A better rule is to keep the category tree relatively thin and model specifics like material, color, size and technical properties as controlled attributes (Anglera).

The same logic holds in B2B. For an industrial supplier, “Fasteners > Bolts” is a category. Thread pitch, material grade and head type are attributes with normalized units. A buyer filtering for stainless steel M8 bolts should never have to guess which of three differently spelled categories holds them.

How to design a product taxonomy, step by step

1. Audit what you have

Export every product with its current category, tags and attributes. Count distinct values per field. Most catalogs reveal the same issues: duplicate categories, one-product categories, attributes stuffed into titles and a long tail of values that differ only by capitalization. This audit also gives you the real size of the migration.

2. Define the jobs the taxonomy must do

List who consumes it: shoppers, site search, ad feeds, marketplaces, ERP, analytics, sales reps. Each consumer needs something slightly different. Decide which taxonomy serves which job, using the table above, before you draw a single tree.

3. Draft the top level

Aim for three to four category levels, with top-level categories that are mutually exclusive and collectively exhaustive (WisePIM). Mutually exclusive means a product has an obvious home. Collectively exhaustive means nothing falls into “Other.” When you cannot decide where a product belongs, the tree is telling you the boundaries are unclear.

GS1 offers a useful test for any classification attribute: it should be globally applicable, relevant and understandable, objective, mutually exclusive and unambiguous, with comprehensive code lists behind it (GS1 guide). Those criteria work just as well for deciding whether something deserves to be a category or an attribute.

4. Decide what is a category, an attribute or a tag

Use this rule of thumb:

  • Category if it changes what the product fundamentally is, and a shopper would browse for it.
  • Attribute if it describes a product and a shopper would filter or compare by it.
  • Tag if it is temporary, promotional or editorial.

If you need to report on it reliably, it is almost never a tag.

5. Use the language shoppers use

Your internal names and your customers’ words often differ. Site search queries, support tickets and customer questions are the cheapest research you have. Reading the questions shoppers ask on product pages, for example through product Q&A on Shopify, shows which terms people actually use for your products, and those terms should shape category labels and filter names.

6. Test before you migrate

No single method is enough. UXmatters recommends combining user research, open or modified-Delphi card sorting, tree testing and usability testing rather than relying on one (UXmatters). Card sorting shows how people group things. Tree testing then checks whether they can find items in your proposed hierarchy, and it isolates organization and labels from visual design effects (UXmatters).

A tool like Treejack evaluates the full depth of a hierarchy through finding tasks and reports correct choices and the paths people took (UXmatters review). Write ten to fifteen realistic tasks (“find a waterproof jacket for hiking”), run them against the draft tree, and fix the nodes where people go wrong before any product moves.

7. Write the rules down

A taxonomy that lives only in someone’s head will fragment within a year. Document naming conventions, required attributes per category, accepted values and units, and how to handle products that fit two places. Use controlled vocabularies, normalized units, category-specific required attributes and stable IDs (Anglera).

8. Map to channels and standards

Once the internal master exists, map it to marketplace categories, ad feed categories and any industry standard you need. Keep those mappings versioned, because external category lists change on their own schedule.

Where taxonomy meets SEO and structured data

Category design is also search design. Every node in your tree can become an indexable landing page, and every filter combination can create URLs that either earn traffic or waste crawl budget. If your attributes generate crawlable filter URLs, the structure of your facets matters as much as the tree. We cover the technical fixes in our guide to faceted navigation SEO.

Clean attributes also feed structured data. When brand, material, color and availability come from controlled fields rather than free text, product markup becomes accurate almost automatically, which is the subject of our practical guide to schema markup for ecommerce. The reverse is painful: marking up inconsistent data just spreads the inconsistency to search engines and AI answer systems.

Best practices that hold up at scale

  • Keep browse categories understandable. Do not encode every variant in the tree. Shoppers think in products and needs, not in data fields (Anglera).
  • Keep one source of truth. Shopify’s catalog-management guidance recommends a single source of truth, standardized names and accepted values, explicit ownership for each field and channel mappings (Shopify).
  • Name an owner for each field. Merchandising owns categories. Product data owns attributes. Marketing owns tags. Without owners, every team edits and nobody maintains.
  • Version your changes. When a category is renamed, merged or split, record it, and update redirects, feeds and reports in the same release.
  • Check for drift. Run checks after major updates or launches to catch products landing in the wrong place or attributes appearing without approved values (Shopify).
  • Avoid “Other” and “Miscellaneous.” They become the largest category within a year.
  • Limit depth, not breadth. A wider top level with clear boundaries usually beats a narrow top with deep branches nobody explores.

Governing the taxonomy over time

No initial rollout will be perfect. A sensible stance is to treat the taxonomy as a long-term investment, focus on maintenance and evolution, and set up mechanisms for ongoing user feedback (Enterprise Knowledge).

For larger catalogs, particularly when people or models assign categories at volume, a governance routine looks like this. Define a scope and a version. Write definitions with tie-breakers for borderline cases. Keep gold examples that show the correct answer. Measure agreement between reviewers, and control changes formally (Sama). Validate with representative pilots, monitor production, sample for quality and analyze errors, then update versions and mappings as the taxonomy changes (Sama).

A lightweight version for a mid-market team:

  1. Intake: a simple request form for new categories or attributes, reviewed on a fixed cadence.
  2. Review: a named owner checks whether the request is a category, an attribute or a tag, and whether an existing node already fits.
  3. Release: changes ship in batches with a version note and updated mappings.
  4. Audit: a quarterly check for orphan categories, duplicate values, empty required fields and zero-result searches.

Our perspective: treat taxonomy as infrastructure

We see the same pattern in scaling commerce teams. The taxonomy was set up when the catalog had a few hundred products, then three platforms, two agencies and four marketing campaigns later, it has become a layer of patches. Navigation says one thing, the ERP says another, and analytics says a third.

Our view is that taxonomy is not a navigation project. It is a decision about how the business describes what it sells, and that description feeds your storefront, search, feeds, CRM segments and reporting. That is why we design it alongside the platform and the data flows rather than after them, and why the people who shape the structure stay involved when it is implemented. A design that is handed off to a separate build team tends to lose the reasoning behind its rules, and the rules are what keep it consistent.

For multi-location brands, the stakes rise further. Each location, region or market may need its own assortment and naming while still rolling up to one reporting structure. A single master taxonomy with controlled local variations is far easier to run than many local ones reconciled by spreadsheet.

— Quick To Impress

How we can help

If your catalog has outgrown its structure, we can audit it, design the master taxonomy, implement it on your commerce platform and connect it to your search, feeds and reporting. Our growth platforms service covers the build, and the same team stays accountable for what ships. Engagements run as monthly capacity, from Core at $3,500 to $5,999 per month, through Growth at $6,000 to $9,999, to Scale from $10,000 per month. You can see what each includes on our pricing page.

Quicktoimpress

We work with enterprise commerce teams and multi-location brands where catalog complexity is the daily reality. Tell us about your catalog and we will tell you where the structure is costing you.

Common mistakes to avoid

Designing from the org chart. Categories named after internal teams or supplier lines make sense inside the company and nowhere else.

Letting the menu drive the data. A homepage campaign should not create a permanent category. Use a tag or a collection and keep the tree stable.

Multiplying categories for SEO. Thin category pages for every color and size combination dilute the structure. Use attributes, and decide deliberately which filtered views deserve indexable pages.

Skipping the migration plan. Moving a category without redirects, feed updates and reporting changes loses traffic and breaks history. Map old to new nodes before launch.

Never retiring anything. Categories with a handful of products, or none, should be merged or removed during every audit.

FAQ

What is the difference between a product taxonomy and product categorization?

The taxonomy is the framework: the departments, categories, subcategories and attributes that organize your products. Categorization is the act of assigning a particular product to a place within that framework. You design the taxonomy deliberately and categorize every time you add or change a product.

How many category levels should an ecommerce site have?

Three to four levels is a sound target for most catalogs (WisePIM). Deeper trees tend to hide products and push specifics like color or size into the hierarchy, where attributes handle them better. If you need more depth, test it with tree testing first.

What is the difference between categories, attributes and tags?

Categories form the browsing hierarchy. Attributes are controlled properties used for filtering and comparison, such as size or fabric. Tags are flexible, non-hierarchical labels for temporary or editorial groupings like seasonal edits (Shopify).

Should I adopt an industry standard like GS1 GPC for my storefront?

Usually not as your storefront tree. Standards are built for data integrity and trade between partners, while shoppers need a browse structure in their own language. Keep your own master taxonomy and map it to the standard where partners or channels require it.

How often should a taxonomy be reviewed?

Run a light audit every quarter and a deeper review after major launches, replatforming or assortment changes. Between reviews, an intake process keeps new categories and attributes from appearing ad hoc.

Sources