The Shopify product category taxonomy (and what it does for your feed)
How Shopify's native Category field, the Shopify Standard Product Taxonomy, differs from the legacy product type, how it maps to google_product_category, and why setting it well pays off.
Since 2024 Shopify has had a native Category field drawn from its own Standard Product Taxonomy, a fixed tree of around 10,000 categories, completely separate from the legacy free-text product type. It's the closest thing Shopify has to Google's category system, it unlocks category-specific attribute fields like colour and size, and setting it accurately is one of the highest-leverage things you can do for your Google Shopping feed.
Two category fields, one product page
Every Shopify product now carries two category-shaped fields, and they are not the same thing:
- Product type: the legacy free-text field. You type whatever you like ("Dress", "Womens Dresses", "dress-midi"). It's your own naming, unvalidated, and it drifts across a catalogue the way all free text does.
- Category: the native field rolled out in 2024, drawn from the Shopify Standard Product Taxonomy: a fixed, versioned tree of roughly 10,000 categories with stable IDs, from top levels like "Apparel & Accessories" down to leaves like "Apparel & Accessories > Clothing > Dresses".
The difference matters because a taxonomy pick is machine-readable in a way free text never is. "Cocktail dress", "Dresses: occasion" and "Dress (midi)" are three different strings to any system reading your product type; a Category ID is one unambiguous node in a published tree.
| Product type (legacy) | Category (Standard Product Taxonomy) | |
|---|---|---|
| Format | Free text, anything | Pick from a fixed tree of ~10,000 nodes |
| Validated | No | Yes: must be a real taxonomy node |
| Consistent across products | Only if you're disciplined | By construction |
| Google mapping | → product_type (your taxonomy, as-is) |
Strongest input for google_product_category |
| Extra behaviour | None | Unlocks category metafields (colour, size, etc.) |
How the Shopify product category taxonomy maps to Google's
Google Shopping's google_product_category attribute must come from Google's own taxonomy: a tree of roughly 5,500 categories that no Shopify field is. That hasn't changed, and it's covered in full in collections and product type.
What has changed is how close Shopify now gets you. The Standard Product Taxonomy was designed with Google's tree firmly in view: the top-level verticals align, the structure rhymes, and for most categories there's a clear corresponding Google node. A product categorised as Shopify's "Apparel & Accessories > Clothing > Dresses" translates to Google's "Apparel & Accessories > Clothing > Dresses" with essentially no ambiguity.
But close is not identical. The two trees differ in depth, in where they split categories, and in their IDs: Shopify's taxonomy is larger and slices some verticals more finely. So a translation step still exists; the point is that a well-set Category turns that step from a guess into a lookup:
- Category set at leaf depth: the mapping to Google's tree is near-deterministic. Your feed gets a specific
google_product_category("Cocktail Dresses"-level, not "Apparel & Accessories") and all the matching and CPC-efficiency benefits that come with specificity. - Category unset or set at a broad level: the classification has to be inferred from titles, descriptions, product type and collections. That works, but it's evidence-based inference rather than a direct read, and broad inputs produce broader outputs.
The practical rule: the Category field is the single strongest categorisation signal you can put in Shopify. Set it once, at the deepest node that honestly describes the product, and everything downstream gets easier.
Category metafields: the quiet second benefit
Setting a Category doesn't just classify the product: it changes what Shopify asks you for. Each taxonomy node carries a set of standard category attributes, exposed as structured metafields relevant to that category. Categorise a product as a dress and Shopify surfaces fields like:
- Colour: from a predefined value list
- Size: likewise
- Material, age group, sleeve length, neckline and so on, depending on the node
These are exactly the attributes Google wants for apparel: color, size, material, age_group are required or strongly recommended in clothing categories, and Shopify historically had no native home for most of them. Category metafields give them a home with three properties free text never had:
- Predefined values. "Blue" is "Blue", not "BLU", "navy-ish" or a hex code. Normalisation problems shrink at source.
- Per-category relevance. You're only asked for attributes that make sense: no "sleeve length" on a coffee grinder.
- Structured storage. They're standard metafields with known keys, so any pipeline reading your store finds them in a predictable place: unlike the custom metafields covered in metafields for Shopping, which every store names differently.
If you fill in nothing else after setting a Category, fill in colour and size for apparel. Those two drive filtering on Google's side, and a structured value beats a value scraped out of an option name every time.
What to do with the legacy product type now
Keep it: just understand its job has narrowed. Product type maps to Google's product_type attribute, which is your taxonomy, accepted as-is and useful for structuring campaigns (bid differently on "Dresses" vs "Accessories"). The Category field didn't replace that; it took over the classification job product type was never suited for. The division of labour:
- Category → drives
google_product_category(Google's tree, via mapping) - Product type → becomes
product_type(your tree, verbatim)
The distinction between the two Google attributes is covered in google_product_category vs product_type.
Deep dive Why a taxonomy pick beats free text at catalogue scale
The value of the Category field is easiest to see at the scale where free text breaks down.
Take a 3,000-product apparel store that's been trading for five years. Its product types were entered by four different people across three platform migrations. A sample: "Dress", "Dresses", "dress", "Womens Dress", "Midi Dress", "DRESS-OCCASION", "Apparel". Every one of those means dress to a human. To anything mapping products into Google's taxonomy, they're seven distinct strings, some of which ("Apparel", "DRESS-OCCASION") barely narrow the answer at all. Multiply across every product family and the classification job becomes thousands of small inferences, each one drawing on titles, descriptions and collection names to compensate for a field that was supposed to answer the question directly.
Now the same store with the Category field set: every dress carries the same taxonomy node: one ID, one meaning, zero drift. Classification into Google's tree collapses from thousands of inferences into a handful of node-to-node lookups (one per Shopify category in use, not one per product). New products inherit the same rigour automatically, because the field won't accept "DRESS-OCCASION": it only accepts real nodes.
There's a compounding effect on top. Because the Category node determines which standard attribute metafields exist, a well-categorised catalogue also tends to be a well-attributed one: the colour and size fields were there to fill in, so they got filled in. The store ends up with structured colour, size and material on precisely the products where Google requires them. A free-text catalogue never gets that prompt, so those attributes live (if anywhere) in option values and description prose, waiting to be extracted.
The honest caveat: setting Category on 3,000 existing products is real work, and Shopify's own suggestions get it wrong often enough to need review. Prioritise by revenue: categorise your top sellers at leaf depth first, since a specific category on a product doing £2,000 a month buys more than a specific category on one doing £20. And a feed layer that classifies from evidence covers the products you haven't reached yet, so the choice isn't "categorise everything by hand or suffer": it's "every Category you set makes the feed's answer for that product a certainty instead of an inference".
How /tools handles this
/tools reads your Shopify Category alongside product type, tags, collections, titles and descriptions, and classifies each product into Google's taxonomy at leaf depth: writing the result to its supplemental feed layer, never back into Shopify. Where you've set a Category, it acts as the strongest input and the mapping into Google's tree is essentially direct; where you haven't, classification proceeds from the other evidence, so unset categories are a weaker starting point rather than a blocker. Category metafields (colour, size, material) are read as structured attribute sources ahead of option-name parsing. Category coverage and specificity feed into your Feed Health Score, and the mechanics of the translation are covered in Google product category mapping.
Frequently asked questions
Is the Shopify Category field the same as product type?
No. Product type is a free-text field where you invent your own label ("Dress", "Trainers"). Category is a pick from Shopify's fixed Standard Product Taxonomy, a tree of roughly 10,000 predefined categories with stable IDs. They live side by side on the product page and do different jobs.
Does the Shopify Category become google_product_category automatically?
Not by itself, they are two different taxonomies. But Shopify's taxonomy was designed to align closely with Google's, so a well-set Category is the strongest single input for mapping into Google's tree. A feed layer still has to do the translation.
What are the category metafields Shopify creates?
When you set a Category, Shopify exposes standard attribute fields relevant to that category, colour, size, material, age group and so on for apparel. They're structured, predefined-value fields, and they map far more cleanly to Google attributes than free-text tags ever could.
Should I still fill in product type if I set the Category?
Yes. Product type maps to Google's product_type attribute, your own taxonomy, useful for campaign structure, while Category feeds classification. They're complementary, not redundant.