StoreBuilt reviewed Shopify’s product field documentation against our existing catalogue-architecture guide for this comparison. The central distinction is straightforward: a standard product category and a merchant-defined product type solve different classification problems. A storefront collection or menu then adds another layer. Giving all three the same name does not make them interchangeable.
For UK ecommerce teams comparing Shopify product category vs product type, the useful question is which field should carry which business meaning. This guide helps catalogue managers choose, migrate and maintain the fields without turning a tidy-up into an uncontrolled change to collections or connected systems. The worked homeware example is illustrative, with no invented client outcome or search-volume claim.
In this guide
- Understand the two fields before renaming anything
- Keep categories separate from customer navigation
- Choose the standard category by product function
- Decide whether a custom type earns its place
- Inventory dependencies before the first bulk edit
- Create a mapping sheet that can be reversed
- Work through an illustrative homeware range
- Pilot across ordinary and awkward products
- Give ongoing ownership to the catalogue team
- StoreBuilt point of view
Understand the two fields before renaming anything
Shopify’s product-type reference distinguishes its predefined category from a custom product type. Each product can have one of each. The standard category gives a shared classification; the custom type lets a merchant keep a useful internal grouping where needed. Neither should become a dumping ground for every attribute of the item.
A ceramic mug might need a standard category describing what it is, a concise merchant type used in an established buying workflow, colour and material attributes, and membership of a gifting collection. Those are separate decisions. Trying to express all of them in one long type value makes future rules harder to understand. Define the purpose of each field before choosing the vocabulary.
Keep categories separate from customer navigation
A customer menu is a route through the shop, while product classification describes the merchandise. A menu labelled Gifts under £50 can be useful without being the product’s fundamental type. Likewise, a seasonal collection may contain several kinds of product. Keep temporary campaigns out of permanent classification unless a documented downstream requirement genuinely calls for them.
Our taxonomy and navigation guide covers the broader architecture. This article addresses the narrower admin-field decision. That boundary matters: changing a category field is not a complete redesign of navigation, and it does not automatically create a useful landing page. Plan the customer-facing structure deliberately rather than expecting one field update to do all the work.
| Concept | Question it answers | Example use |
|---|---|---|
| Standard category | What kind of product is this? | Shared catalogue classification |
| Product type | Which merchant-defined grouping applies? | Established buying-team grouping |
| Attribute or metafield | What specific property does it have? | Material, dimensions or finish |
| Collection | Which assortment should include it? | Seasonal gifts or a core range |
| Menu item | How should a customer reach it? | A navigational route to an assortment |
Choose the standard category by product function
Use the current Shopify Standard Product Taxonomy guidance when making the mapping. Choose the category that best describes the product’s main function, then document any ambiguous cases for review. Do not select a category merely because its wording resembles a campaign headline or because it seems likely to improve search traffic.
Have the person who understands the product resolve ambiguous examples. A decorative lamp that also charges a phone needs a defensible classification based on the actual item, not the nearest phrase in an import sheet. Maintain a short exception register containing the product, chosen category and reason. That is more useful than allowing each merchandiser to improvise whenever a new hybrid product arrives.
Decide whether a custom type earns its place
Inspect how the business already uses product type. It may support a buying report, a collection condition or an integration mapping. If there is no clear use, avoid adding a parallel classification solely because the field exists. If it has an important use, keep the vocabulary small enough that staff can apply it consistently.
Write a definition for each allowed type and one example that does not belong. This catches vague boundaries such as Accessories versus Home accessories before they spread. Decide how singulars, plurals, abbreviations and legacy supplier labels are handled. The goal is consistent meaning, not cosmetic uniformity. A tidy list with unclear definitions will drift again as soon as several people start importing products.
Inventory dependencies before the first bulk edit
Search for every place that reads category or type: collections, product feeds, reporting, app rules, imports and custom theme code. Ask owners to identify the exact field used instead of accepting “we use categories”. Different teams may use that word for a collection, a standard category or a supplier grouping. Record the dependency and its expected behaviour after the change.
Shopify documents consequences of standard categories for channel data and, where applicable, tax calculation. This is a reason to involve the appropriate owners, not to promise that classification alone resolves tax treatment. Any tax-sensitive mapping should be reviewed by the business’s qualified adviser. Keep this project focused on accurate data and test evidence rather than presenting a field choice as financial advice.
Contact StoreBuilt to map catalogue fields and their storefront or integration dependencies before a bulk update.
Create a mapping sheet that can be reversed
Preserve product identifiers and current values before proposing new ones. Add the target standard category, proposed custom type, reason, reviewer and validation status. Separate undecided rows from approved rows. A blank target should mean something explicit, such as pending review, rather than accidentally becoming an instruction to remove existing data.
Keep the change file narrower than a full catalogue rewrite where possible. Unrelated descriptions, handles, images and variant options should not be casually included in a classification change. When an import tool is used, check its current overwrite behaviour and test a small sample. Preserve the original export separately so the team can restore known values if an unexpected dependency appears.
Work through an illustrative homeware range
Imagine a homeware shop whose product types mix supplier names, seasonal campaign labels and physical product kinds. A linen cushion appears under Spring refresh, while a similar cushion appears under Soft furnishings. The buying team cannot reliably compare the assortment, and a collection rule catches only one naming pattern.
The team defines the standard category by the item’s function and chooses whether Soft furnishings remains a useful custom type. Spring refresh becomes a campaign assortment decision, and supplier identity remains in its appropriate field. Before changing the range, the team tests the collection rules and the feed that depended on the old values. The benefit is a clearer data model; no sales uplift should be assumed without subsequent evidence.
Pilot across ordinary and awkward products
A good pilot includes a straightforward product, an ambiguous product, a product used in an automated collection and one used in a connected sales channel. Include a product with relevant category-linked data where your store uses it. Check the record after saving and inspect the downstream result after the relevant sync has completed.
| Pilot check | Evidence | Stop condition |
|---|---|---|
| Source field | Approved value saved | Unexpected overwrite |
| Collection membership | Intended products included | Important product disappears |
| Connected feed | Correct classification received | Mapping rejected or misinterpreted |
| Product attributes | Required information remains available | Buyer-facing detail lost |
| Reporting | Grouping matches the agreed definition | Historical comparison becomes unclear |
| Restore procedure | Original values retained | No reliable route back |
Give ongoing ownership to the catalogue team
Publish the vocabulary and review process where product creators actually work. Add classification checks to new-product intake and supplier imports. A quarterly cleanup is not a substitute for deciding who approves a new type value. Make it easy to request a new category mapping or raise an ambiguous item without bypassing the process.
Track useful exceptions rather than chasing a perfect-looking spreadsheet. Products awaiting review, inconsistent source imports and rules still referencing retired values deserve attention. Keep a dated mapping history so reporting changes can be explained later. Where a connected system owns a field, fix the source or its mapping; repeated manual corrections in Shopify will not last if the next sync restores the old value.
StoreBuilt point of view
The best classification is the smallest one that lets people and systems make the right decisions consistently. Standard categories provide common structure; custom types should serve a defined merchant need. Collections and navigation can then focus on how customers shop instead of compensating for an unclear product record.
Explore Shopify development for catalogue implementation and integration work. Contact StoreBuilt with a sample export and the workflows that depend on it to scope a controlled cleanup.