Product Taxonomy: A Practical Guide toDesign and Mapping

A shopper on a DIY website types "cordless drill", then ticks two boxes in the filters: 18 V and battery included. In those few seconds she has used your product taxonomy three times, once to land in the right category and twice to narrow the choice with attributes. She will never see the word taxonomy, but she feels it immediately when it is wrong.

What is a product taxonomy?

A product taxonomy is the structure that organizes a catalog: the categories a product belongs to, the families that decide which attributes it must carry, and the attribute values customers use to search, filter and compare. A good taxonomy is built around how customers shop. Channel taxonomies such as the Google product taxonomy or the Shopify Standard Product Taxonomy are mappings you publish to, not the model you run your catalog on.

The word sounds academic, but the meaning is simple. A taxonomy answers two questions for every product: where does it live, and what do we need to know about it? Product taxonomies then drive product discovery in three places: navigation through categories and subcategories, search and filters, and the feeds sent to channels.

Categories, attributes and families: three different jobs

Most taxonomy problems start when these three are mixed up.

• Categories are the tree a shopper navigates, for example Tools › Power tools › Drills. A product can appear in more than one category.
• Attributes are the facts about a product: voltage, battery included, chuck size, weight. They power filters, comparison tables and product pages. Their values should come from controlled lists wherever possible, not from free text.
• Families (also called product types or templates, depending on the system) decide which attributes a product must carry. Every drill shares the same set of attributes, and that set is different from the one for a paint or a garden hose.

Put simply, categories are for finding, attributes are for choosing, and families are for governing. It is like a library: the shelves are the categories, the record card is the attributes, and the type of card (book, magazine, map) is the family. Move a book to another shelf and its card stays the same.

What does a product taxonomy look like? Three examples

A few product taxonomy examples make the difference concrete.

In each example, the category path is short, and the real precision lives in the attributes. A catalog does not need ten levels of categories when a few levels, plus well-governed attributes, let customers narrow the choice themselves.

How does the Google product taxonomy work?

Google maintains its own tree of product categories for Merchant Center and Shopping, often called the Google product taxonomy. According to Google Merchant Center Help, the taxonomy goes from broad categories down to specific ones, for example Electronics › Communications › Telephony › Mobile Phones, and Google publishes the full list as a downloadable text file and Excel file, with a numeric ID for each category.

Useful facts from that page when you plan the mapping:

• You set it with the google_product_category attribute, using either the numeric ID or the full path, but not both.
• Google automatically assigns a category to every product, and the attribute is marked as optional. You submit it to correct the category, in the cases Google accepts an override.
• Google recommends the most specific category possible, and the one that matches the main function of the product.
• Some categories, such as Apparel & Accessories, Mobile Phones or Software, come with additional required fields.

Google also offers a separate product_type attribute. As the product type help page explains, it lets you include your own internal categorization system, for example Home › Women › Dresses › Maxi Dresses. Even Google expects you to keep your own structure, and to send its category as a translation next to it.

How does the Shopify Standard Product Taxonomy work?

Shopify has its own open standard. The Shopify Help Center defines a product category as "the standard category of a product from Shopify's Standard Product Taxonomy." Each product can have only one product category and one product type: the category comes from the standard, while the product type is a custom field unique to your store.

Two features are worth knowing:

• Category metafields. Each category comes with its own attributes, called category metafields in the Shopify admin and product attributes in the taxonomy. They can be used as filters and in reports, and a correct category also helps Shopify Tax collect the right rate at checkout.
• Suggestions and mappings. Shopify generates an AI-powered category suggestion that you can accept or replace with a more specific category. The taxonomy itself is public on GitHub under the MIT License, in txt and json formats, with dated versions and mapping rules to other taxonomy systems, including Google.

For a merchant who sells only on Shopify, the standard categories are a sensible base. The question changes when the same catalog also feeds a marketplace, a B2B portal and an AI assistant.

The two channel taxonomies side by side, as their own help pages describe them:

Why channel taxonomies are mappings, not your data model

Google, Shopify and each marketplace have a taxonomy designed for their own needs: their search, their ads, their tax rules, their listing checks. Exchange standards have yet another purpose. GS1 Global Product Classification gives trading partners a shared framework to classify goods, and ETIM gives technical products a consistent structure so that businesses can exchange product data reliably.

All of these are useful. But a classification standard is not a data model. Standards like ETIM or GS1 are a shared language between companies, and a shopper needs a different structure (what ETIM is built for, and what it is not). If you run your catalog on one channel's tree, you inherit choices made for that channel's business, and the day you add a second channel, you discover that the trees do not agree.

The healthier pattern looks like this:

1. Your own taxonomy (families, attributes, navigation categories) is the source, designed for your customers and your range.
2. Each channel gets a mapping: one of your families or categories points to one channel category ID, and your attribute values are translated into the values the channel expects.
3. When a channel changes its taxonomy, you update the mapping, not the catalog.

In a PIM, this is usually done with one category tree per channel or with a mapping attribute on each family. The method matters less than the principle: the model is yours, the mapping is a publication.

How do you design your own product taxonomy? Five best practices

1. Start from customer filters, not from the org chart

Read your site search logs, your zero-result searches and your filter usage. List the questions a customer must answer before buying in each category, then turn them into product attributes. On the D2C site of a global petcare brand, after catalog categories and attributes were reworked for search, searches returning zero results dropped from about 8% to about 2% in a year (figure reported by the client team).

2. Use a two-level family model

The first level groups products that share a common base of attributes, for example power tools. The second level adds what is specific to one type: drills, sanders, saws. Shared attributes are defined once, specific ones only where they belong, and completeness starts to mean something again, because each product is only asked the questions that are relevant to it.

3. Govern attributes like a shared asset

Every attribute needs a definition, an owner, a type (list, number with unit, yes or no, text) and a scope: is it for the web, for logistics, for compliance, or for one channel only? Prefer controlled lists to free text and one attribute to three synonyms. A "color", a "colour" and a "main color" in the same product catalog are not richness, they are three places where the customer filter will fail. The taxonomy should live in the system that owns product information, usually a PIM; if you are unsure where PIM ends and master data management begins, see PIM vs MDM.

4. Keep navigation categories flexible

Once families and attributes are stable, build the shopper's category tree on top of them. It can be reorganized for a season, a market or a campaign without touching the product data, because the data lives in the families.

5. Map to channels last

Only then build the mappings to Google, Shopify, marketplaces and exchange standards. Mapping a clean model is a translation exercise. Mapping a messy one becomes a permanent project.

A field story: 1,324 families copied from a supplier

A European DIY retailer had built its catalog on 1,324 flat families copied from a supplier classification. Each family carried between 196 and 385 attributes, so completeness meant nothing and teams could not tell what was really missing. On paper, the model looked complete. In practice, nobody could say whether a product was ready to sell.

The same DIY catalog was restructured into a two-level family model and 5,181 attributes were reduced to 555 kept for the web. The lesson is not that the supplier classification was bad. It was made to exchange data between companies, which is a different job. It simply should not be the structure the customer has to live in.

What are the most common product taxonomy mistakes?

• Copying a supplier or standard classification. It was designed to exchange data between companies, not to help a shopper choose. Supplier data is often where catalogs break first: see why supplier data is where PIM projects fail.
• Free text where a list is needed. "18V", "18 V" and "18 volts" become three different filter values.
• Attributes without owners. Nobody fixes a field that nobody owns.
• Governing the taxonomy in a spreadsheet forever. A spreadsheet is fine to draft a taxonomy, much less to govern it across teams. Excel vs PIM explains when it stops being enough.

Why do AI shopping assistants depend on your taxonomy?

More buyers now start by asking an AI assistant what to buy. The assistant reads structured product data, compares it, and recommends the products it can describe with confidence. A clear family tells it what kind of product it is looking at. Filled, controlled attribute values let it check the shopper's constraints: 18 V, battery included, a given chuck size.

When the taxonomy is vague, the assistant has to guess, and it tends to recommend the product it does not need to guess about. I go deeper on this in why products do not appear in AI search results. AI enrichment can also help fill empty attributes, but only when it is forced to respect the model: pick from the existing attribute options, never invent values.

Build it for the shopper, publish it to the channels

Listen, Google's tree, Shopify's standard, GS1 and ETIM all deserve respect. They solve real problems for the companies that use them. But it is not because a taxonomy is official that it is right for your customers. Your taxonomy is how your customers think about your range, written down. The channel taxonomies are the languages you translate it into.

If you want a second look at your own taxonomy, I work as an independent PIM consultant, and a PIM audit is often the right place to start: we look at your families, attributes and filters from the customer's side first.