A storefront rebuild often begins with a new menu. Categories are renamed, products are regrouped and the navigation becomes visually cleaner. The difficulty appears later: filters no longer line up with product data, reporting compares different groups under the same name, and customers follow familiar links into pages that no longer answer the same need.
A durable taxonomy separates the meaning of the catalogue from the way a particular theme presents it. Navigation can change without forcing every underlying classification to change. Categories can evolve while their history remains understandable. The aim is not to freeze a business in its current structure, but to make changes deliberate and traceable.
I use this article to set out a practical design and migration method. Its examples are hypothetical and do not describe a completed client project. Use the framework to ask better questions about your own catalogue rather than treating the example structure as a universal template.
Distinguish four things that often share a label
A product type describes what an item is. An attribute describes a property such as size, material or compatibility. A collection groups products for a purpose. A navigation item provides a route through the storefront. These concepts can overlap in the interface, but treating them as identical makes future changes harder.
For an illustrative accessories catalogue, “phone case” is a product type, “compatible device” is an attribute, “travel essentials” is a merchandising collection and “shop by device” is a navigation route. One product can participate in all four without becoming four different products. The data model should make those relationships explicit.
When a seasonal campaign ends, its navigation item may disappear while its products and attributes remain. When a new device is released, compatibility values may expand without requiring a new top-level menu section. When a product type becomes large enough to deserve its own category, that change should follow customer need and catalogue depth rather than the available space in a theme.
Start with customer tasks and actual inventory
Inventory alone does not tell you how customers think. Internal purchasing categories may reflect suppliers, margins or warehouse organisation. Customers may instead begin with the object they own, the problem they want to solve or the occasion they are shopping for. A useful taxonomy connects those needs to a structure the business can maintain.
Review available evidence such as on-site search terms, support questions, category traffic and product assortment. Keep each source's limitations visible. Search data reflects what visitors typed into the existing interface, while support data reflects those who asked for help. Neither is a complete picture of demand. Look for agreement across sources rather than treating one export as a final answer.
Baymard's navigation research examines the relationship between homepage navigation, category structure and product finding. It supports treating taxonomy as part of the shopping journey rather than an isolated menu exercise. The practical implication here is to test whether people can reach an appropriate product set, not merely whether they prefer a category name. Baymard research overview
Create a category contract
For each durable category, record an identifier, customer-facing label, definition, inclusion rule, exclusion rule, owner and destination URL. The identifier should remain stable when the label changes. That allows reports and migration records to distinguish a renamed category from a newly created one. A label is communication; an identifier is continuity.
| Field | Illustrative entry | Purpose |
|---|---|---|
| Stable identifier | accessory-phone-case | Survives a label change |
| Customer label | Phone cases | Makes the scope understandable |
| Inclusion rule | Protective cases for phones | Defines what belongs |
| Exclusion rule | Screen protectors and pouches | Prevents ambiguous grouping |
| Key attribute | Compatible device | Supports refinement |
| Owner | Catalogue operations | Assigns maintenance responsibility |
| URL decision | Preserve existing equivalent route | Protects continuity |
Write definitions that another colleague can apply without guessing. “Premium accessories” is difficult to maintain unless premium has an agreed meaning. “Accessories for a named device family” is more testable, but still needs a compatibility source. If products routinely fit several categories, define whether that is intentional and how the primary reporting category is selected.
Use attributes to reduce unnecessary category growth
A catalogue can become difficult to navigate when every product property becomes a category. Colour, material, connector type and compatibility may be better handled as attributes and filters. But a filter is only useful when the underlying data is complete and consistent. A polished filtering interface cannot repair contradictory values.
Normalise values before rebuilding the storefront. Decide whether two spellings represent the same property, whether a missing value means unknown or not applicable, and who approves new values. Keep a mapping from old values to new ones. Do not silently merge terms because they look similar; some differences may matter to compatibility or product use.
Inspect the long tail of the catalogue. Popular items may be carefully maintained while older products carry inconsistent attributes. If your launch test only covers bestsellers, customers can still encounter broken filters elsewhere. Include a sample of sparse, unusual and multi-purpose products in the acceptance test.
Test a category mapping sheet with representative products
I would keep more than old and new category labels in the mapping file. This small example connects a proposed rule to a product-level acceptance check. The rows are hypothetical, not results from a store.
| Sample record | Current ambiguity | Proposed decision | Acceptance check |
|---|---|---|---|
| A: phone case | Product type and colour share a category label | Keep case as the type and colour as an attribute | A colour change does not change the product type |
| B: screen protector | Included in the phone-case group | Apply the contract's exclusion rule | Absent from cases, discoverable in its own group |
| C: case with unknown compatibility | Device field is empty | Mark the information for verification | Not presented as compatible with a specific device |
I would add the product identifier, decision evidence, owner and review date to each row. If another colleague cannot reach the same conclusion from the category contract, I would revise the rule before applying it to the whole catalogue. Unknown information should remain distinguishable from a verified match.
Keep merchandising flexible without making classification unstable
Campaign collections need room to change. A summer edit, gift guide or promotion should not require redefining the core product hierarchy. Give merchandising collections their own purpose, owner and lifecycle. That makes it possible to remove a campaign from navigation without losing track of the underlying products or the links that reached it.
Not every collection deserves an indexable landing page. Some exist only to support a temporary interface or a narrow filter combination. Decide which destinations have a distinct, useful purpose and enough relevant content. This is a content and discovery decision, not a rule that every automatically generated group should become a search landing page.
When a temporary collection has acquired meaningful links or recurring demand, review its future individually. It may become a durable guide, be redirected to a genuinely equivalent page or be retired. Do not send every expired campaign to the homepage. Preserve the customer's reason for following the link wherever a relevant alternative exists.
Map URLs before changing the menu
Create a legacy URL inventory before the rebuild removes access to the old structure. Combine the sources available to you and note gaps. For each destination, record the previous purpose, proposed purpose and action. A matching word in two URLs is not enough to establish equivalence; compare the products, content and customer task.
Preserving an address is often the simplest option when the meaning remains the same. If two categories are merged, document why the new destination serves both previous intents. If a category splits, an intermediate page may be more appropriate than choosing one child arbitrarily. The mapping should be explainable without reference to the new theme's layout.
For Shopify implementations, I check the current platform rules for redirects and test the actual old address after configuration. An old URL that still serves a valid page cannot be redirected this way; reserved and fixed paths also have restrictions. A row in an import file is not proof that the browser receives the intended response. Shopify redirect documentation
Test the taxonomy without relying on visual polish
Begin with simple tasks: find an item compatible with a particular device, compare two product types, locate a replacement part or identify an option within a constraint. Ask participants to explain what they expect behind a label. Record where they hesitate and whether they reach an appropriate set of products. Do not coach them toward the intended path.
Then test the implementation on mobile. Navigation may expose fewer levels, filters may be hidden behind a control, and category descriptions may push products far down the page. Check the full journey from entry point to product selection. A structure that makes sense in a spreadsheet can still be awkward when only a few options are visible at once.
Include keyboard navigation and readable labels in the review. Avoid interactions that depend solely on hovering. Ensure that expanding a category does not unexpectedly navigate away and that the current location is understandable. These checks improve usability for a wider range of people while also revealing unclear interaction design.
Define launch acceptance criteria
The category owner should be able to confirm which products belong in each important group and why. The implementation team should show that relevant filters work with real data. The migration owner should show that mapped legacy URLs reach the intended final pages. The measurement owner should explain how pre- and post-launch reporting will remain interpretable.
Use a coverage matrix rather than a screenshot gallery. Include large and small categories, missing-attribute cases, translated labels, empty results and products appearing in multiple collections. A successful category screenshot demonstrates one state. A coverage matrix helps show which important states were actually checked and which remain unresolved.
Keep launch blockers distinct from later improvements. Incorrect product membership, broken navigation and misleading compatibility information may block release. A proposed alternative label may remain an experiment. Explicitly separating these decisions prevents the team from debating minor presentation changes while a material data problem stays hidden.
Maintain the structure after launch
Assign ownership for adding categories, attributes and navigation routes. A lightweight change request should state the customer need, expected product coverage, data requirements and effect on existing URLs. This does not need to become a committee for every label edit. It should stop structural changes from happening invisibly through unrelated campaign work.
Review empty or sparse categories, frequently combined filters and recurring support questions. Those signals can suggest that the structure needs attention, but they do not dictate a single answer. A sparse category may be strategically important; an apparently popular filter may compensate for a weak default grouping. Inspect the context before changing the model.
A storefront will change again. The durable asset is a documented relationship between customer intent, product data and meaningful destinations. With that relationship in place, a new theme can improve presentation without erasing the catalogue's logic. For help connecting taxonomy, migration and implementation decisions, explore working together.