Checked on 20 August 2026, the first line of Google’s published English taxonomy file still reads # Google_Product_Taxonomy_Version: 2021-09-21. That Google taxonomy lists 5,595 categories across 21 top-level branches, seven levels deep at its deepest point. The en-GB file carries the same version number. Google describes its own categorisation as “continuously evolving”. The gap between that and a static published file causes most of the mapping confusion we are asked to fix.
This is the mapping method we use, followed by the twenty categories that cause the most trouble.
One convention before we start. Google writes its category names with an ampersand where we write “and” throughout this piece. Map to the numeric ID and the difference stops mattering, which is the point of stage three.
What the Google taxonomy actually is
It is a flat text file of category paths, each with a stable numeric ID. Google publishes it per locale. The IDs are the same across locales, the names are not. The clothing branch is ID 166 in every language. Google’s UK documentation calls it “Clothing and Accessories”. The US file calls it “Apparel and Accessories”.
Distribution across the tree is uneven in ways that matter commercially. Home and Garden alone holds 1,035 of the 5,595 categories. Business and Industrial holds 224 and never goes deeper than five levels. If you sell consumer goods the Google taxonomy is granular. If you sell industrial supply, it is not, and no amount of mapping effort changes that.
One more thing worth knowing. The google_product_category attribute is a feed attribute in Merchant Center. It does not exist in Google’s product structured data documentation, so marking it up on your product pages does nothing. Category reaches Google through the feed.
What Merchant Center does when you leave the category out
This is where most articles on the subject are years out of date, so read Google’s current wording carefully.
Merchant Center lists google_product_category as optional. Its wording is direct: “All products are automatically assigned a product category from Google’s continuously evolving product taxonomy.” Google then says it “will only accept a product category override in the following cases”:
- Enforcement of category-specific attribute requirements, where categories such as clothing, mobile phones and software impose extra required fields.
- Targeting of Google Ads campaigns that have been built around Google product categories.
- Alcohol, where the product must be correctly categorised for policy reasons.
Read that in order. Google is auto-assigning a category to every product you send, whether you submit one or not. Your submitted value is an override, and it is honoured in a defined set of situations rather than universally.
That has two practical consequences. First, submitting a category is not optional in any meaningful sense for the categories that carry hard requirements. The auto-assignment decides which requirements get enforced against you. Second, a bad submitted category is worse than no category. You have overridden a machine that was probably right with a spreadsheet that was probably wrong.
Get the value wrong entirely and Merchant Center raises “Invalid product category”. Google’s guidance is that the value “doesn’t match any of the categories in the Google product taxonomy”, and that affected products have limited performance. The most common cause we see is submitting only the last segment of the path. “Tuxedos” on its own is rejected. The full path or the ID is accepted.
Stage 1: Pull the file and pin the version
Download the taxonomy file for your target locale, store it in your PIM as a versioned reference list, and record the version header alongside it. Not a copy pasted into a spreadsheet on someone’s drive.
Two reasons. Categories do get retired between file versions, and Google notes that what you submit might not match what you see. And when a feed starts throwing invalid category errors eighteen months from now, the first question is simple. Which version of the list was the mapping built against?
If you sell into more than one market, pull each locale file and map against IDs, not names. Locale name drift is exactly why.
Stage 2: Map at node level, not SKU level
Nobody maps 300,000 SKUs to Google categories. You map your leaf nodes, and every SKU inherits from its node.
That means the quality of your Google mapping is capped by the quality of your own taxonomy. If your leaf nodes contain mixed products, no single Google category fits. You then argue about the mapping when the real problem is the node. We treat Google mapping as an output of taxonomy and attribution work rather than a separate project, for that reason.
Practical shape of the job:
- Export your leaf nodes with SKU counts and revenue against each.
- Sort by revenue. Map the top 200 nodes by hand, with a category manager in the room.
- Machine-suggest the tail, then review anything where the suggestion confidence is low or the node is large.
- Store the mapping as an attribute on the node, versioned, with the date and the person who approved it.
Expect a genuine one-to-many problem in the tail. Where one of your nodes legitimately spans two Google categories, the answer is usually to split your node, not to fudge the mapping.
Stage 3: Map to the numeric ID, not the path string
Google accepts either the full category path or the numeric ID, and explicitly says not to send both. Send the ID.
Path strings break in four ways we see repeatedly. They differ by locale. They contain ampersands that XML feeds must entity-encode. They get truncated by spreadsheet exports. And a single renamed segment invalidates every row that carries it. The numeric ID has none of those problems and is stable across every locale file.
Store the ID as the mapped value on your node. Generate the path only if a downstream tool insists on it.
Stage 4: Work the exceptions that carry hard requirements
A handful of categories change what the feed must contain. These are not edge cases, they are where the disapprovals come from.
Clothing and shoes. For products targeted at Brazil, France, Germany, Japan, the UK and the US, Google requires age group, gender and colour on clothing. Size is required for categories 1604 (clothing) and 187 (shoes) in those same countries. Variants in those countries also require item_group_id. Miss any of them and you get the “Missing value” issues for size, colour, gender and age group.
Note the trap. If you do not submit a category and Google auto-assigns one of these, the requirements are enforced against you anyway. Teams then report that the error is wrong because “these are not clothing”, when the fix is to submit the correct category as an override.
Gift cards. Must use category 53, Gift Cards and Certificates. Open-loop cards branded by a card issuer are unsupported content and will not run at all.
Mobile devices sold on a contract. Google names a specific set: 267 mobile phones, 4745 tablet computers, 6030 pre-paid cards and SIM cards, 6544 GPS tracking devices, and 201 watches.
Physical goods subscriptions. Only a named set of categories is permitted. It includes 2915 personal care, 491 health care, 536 home and garden and 2 pet supplies. It also includes 1253 toys, 5814 prepared foods, 166 clothing and accessories and 1868 coffee.
Alcohol. One of the three override cases Google accepts by name, and one where getting it wrong is a policy problem rather than a performance problem.
Media. Brand is required for all new products except films, books and musical recording brands. Books also sit next to eBooks, which are unsupported content entirely.
Build these as rules in your feed layer, not as tribal knowledge. Every one of them is a published requirement with a published error message.
Stage 5: Use product_type for everything the Google taxonomy cannot hold
product_type is your own category string, and it is the release valve for every product the Google taxonomy classifies badly.
It is optional, takes up to 750 characters, and can be submitted up to five times. Only the first value is used to organise bidding and reporting in Google Ads Shopping campaigns.
Our default is to send the full internal path as the first product_type value, at the depth your own taxonomy actually reaches. Google has one node for screws. Send “Hardware > Fasteners > Socket Screws > Socket Cap Screws > Stainless A4” instead. That gives campaign structure and reporting granularity the Google category alone cannot. The same pattern applies to any feed-driven channel, including Shopify product content that syndicates onward.
Where the Google category genuinely has no match, Google’s own advice is to use product_type rather than force an incorrect category. Take that advice.
Stage 6: Test on a feed slice before you push the catalogue
Push 500 SKUs spanning your ten most awkward nodes. Wait for the results. Merchant Center takes 24 to 72 hours to reflect changes on the Needs attention page, so build that into the plan.
Check three things on the slice. Invalid category errors, missing-value errors that the category triggered, and whether the products landed in the surfaces you expected. Then push the rest.
Testing on the whole catalogue instead means a suspension risk on a live account. Data quality violations that go unresolved can escalate from item disapprovals to account-level enforcement, and price and availability mismatches carry a 28-day clock. That is not the moment to be learning how the categories behave.
Stage 7: Re-map when the catalogue changes
The mapping is not a one-off. Three triggers should re-open it:
- A new node in your taxonomy. Mapping is part of node creation, not a later clean-up.
- A feed error report showing category-driven issues. Route these back to the node owner, not to the person who runs the feed.
- A locale or market launch. New locale file, same IDs, but the category-specific requirements differ by country.
Review the whole mapping annually against the published file. It takes a day for most catalogues, and it catches the retired categories.
Twenty categories that trip everyone up
Every ID below is from the published 2021-09-21 file. Names are written with “and” in place of Google’s ampersand.
| ID | Category | Why it causes trouble |
|---|---|---|
| 166 | Clothing and Accessories | Named differently in the US file. Also the only apparel root allowed for physical subscriptions |
| 1604 | Clothing | Triggers age group, gender, colour and size requirements in the UK |
| 187 | Shoes | Same requirement set, and size is enforced here too |
| 267 | Mobile Phones | Mandatory for handsets sold with a contract |
| 4745 | Tablet Computers | Mandatory for contract tablets |
| 6030 | Mobile Phone Pre-Paid Cards and SIM Cards | Mandatory for SIM-only offers |
| 53 | Gift Cards and Certificates | Mandatory for gift cards. Open-loop cards are unsupported entirely |
| 499676 | Alcoholic Beverages | One of three override cases Google accepts by name |
| 784 | Books | Brand is not required here. Sits next to eBooks, which are unsupported |
| 518 | Medicine and Drugs | Restricted category with certification requirements |
| 2915 | Personal Care | One of the few roots allowed for physical goods subscriptions |
| 491 | Health Care | Same, and adjacent to restricted healthcare policy |
| 772 | Mature | A whole top-level branch of 38 nodes with policy consequences attached |
| 2092 | Software | Named by Google as a category that imposes extra required fields |
| 111 | Business and Industrial | 224 categories for the entire industrial world, five levels at most |
| 7261 | Automation Control Components | Has exactly two children: PLCs and variable frequency drives |
| 2251 | Screws | One leaf node for every screw you sell |
| 125 | Lumber and Sheet Stock | One leaf node for all timber and sheet materials |
| 6807 | Circuit Breaker Panels | The nearest node to a breaker. There is no node for breakers |
| 899 | Motor Vehicle Parts | 21 child nodes, 20 of which are terminal |
Where the Google taxonomy runs out for distributors
Look at the last six rows of that table together and the pattern is obvious.
The entire fastener range in the Google taxonomy is eight leaf nodes. Drywall anchors, nails, nuts and bolts, rivets, screw posts, screws, threaded rods and washers. A fastener distributor with 40,000 lines maps all of them into eight buckets.
An industrial automation distributor gets three nodes: the parent, PLCs and variable frequency drives. Everything else in the range, from safety relays to servo amplifiers, has no home.
Electrical distribution is not much better. Hardware, Power and Electrical Supplies runs to 32 nodes in total, and there is no node for a circuit breaker.
The automotive aftermarket has the same shape. Motor Vehicle Parts has 21 child nodes and 20 of them are terminal. Braking, engine parts, exhaust and suspension each get one node. ACES and PIES describe that same catalogue in tens of thousands of applications.
None of this is a criticism of Google. The taxonomy is built for consumer shopping, and it does that job well. It is a reason to keep expectations straight. The Google taxonomy is a channel requirement, not a classification system, and it will never be the tree your own site runs on. That is why we keep it separate from ETIM, eCl@ss and the rest of the B2B product classification picture. The same catalogue routinely carries four different category codes for four different jobs. Anyone selling through marketplaces will recognise the pattern, because Amazon, eBay and the rest each impose their own.
Key takeaways
- Google’s published taxonomy file has read version 2021-09-21 for years, while Google’s own categorisation is described as continuously evolving.
- Every product gets a category assigned automatically. What you submit is an override, accepted in a defined set of cases.
- Map leaf nodes, not SKUs, and map to the numeric ID rather than the path string.
- The clothing, shoes, gift card, contract device, subscription, alcohol and media categories change what the feed must contain.
- Use product_type for the granularity the Google taxonomy cannot carry, and for products it classifies badly.
- Test on a 500-SKU slice and allow 24 to 72 hours before reading the results.
- For industrial, electrical and automotive catalogues, the taxonomy runs out early. Plan around it rather than fighting it.
Category mapping is usually the visible symptom of an internal taxonomy that was never designed for channel output. If feed disapprovals keep coming back to categories, the fix sits in taxonomy and attribution rather than in the feed tool. Book a thirty-minute call and we will look at your node structure and your current mapping together.