Google product category

Google maintains a single published taxonomy of product categories, versioned and downloadable as a plain text or XML file. Every entry is a full path running from a top-level category down to a leaf, paired with a numeric ID.

You assign one value per item in the google_product_category attribute of your Merchant Center feed. Either the ID or the full path string is accepted, and Google treats them as equivalent. The ID is the safer of the two, because path strings get reworded between taxonomy versions and a stale string fails to match.

A few real values, taken from the published file:

Product	Category ID	Full path
3/8-16 x 2" Grade 8 hex bolt	1739	Hardware > Hardware Accessories > Hardware Fasteners > Nuts & Bolts
UL listed 600V twist-on wire connector	2274	Hardware > Power & Electrical Supplies > Wire Caps & Nuts
18 AWG THHN stranded copper wire	2345	Hardware > Power & Electrical Supplies > Electrical Wires & Cable
Nitrile disposable glove, 5 mil	5591	Business & Industrial > Work Safety Protective Gear > Safety Gloves

The taxonomy runs shallow in industrial branches and deep in consumer ones. That asymmetry is the source of most B2B mapping pain: thousands of your SKUs collapse into one leaf, and the leaf that fits best sits well above where your own taxonomy stops.

Mostly no, sometimes yes, and the "no" is misleading.

Google auto-assigns a category to every item using your product data, largely the title. If it guesses well, you never notice. If it guesses badly, you get the wrong tax treatment, the wrong shipping rate, or an item that quietly stops matching relevant queries.

It is required when:

• The item is in Apparel & Accessories (ID 166), which also turns on size, color, age_group, and gender requirements.
• The item is alcohol, which follows a separate policy and eligibility path.
• The item is a mobile device or service plan sold on a contract.
• You use category-based tax or shipping rules in Merchant Center. Those rules key off google_product_category, so an unset field means the rule never fires.

Outside those cases the field is technically optional and practically mandatory. Auto-assignment leans heavily on your product title, and a title like "HB-38162-G8-ZP" gives Google very little to work with, so the category it picks tends to be wrong in ways nobody catches for months.

These two get confused constantly, and the confusion is expensive.

Dimension	google_product_category	product_type
Whose taxonomy	Google's, fixed list	Yours, free text
Values allowed	Only published IDs or paths	Anything you want
Values per item	One	Several
What it drives	Eligibility, tax rules, shipping rules, policy checks	Campaign structure, feed rules, reporting segmentation
If left blank	Google guesses for you	Nothing breaks, you lose a grouping axis

Use google_product_category to speak Google's language. Use product_type to send your own taxonomy through unchanged, for example Fasteners > Bolts > Hex Bolts > Grade 8, so your Shopping campaigns can be structured the way your merchandisers actually think about the catalog.

Sending both is the normal practice. They occupy different fields, they cost nothing extra to populate, and each one answers a question the other has no way to address.

The taxonomy file carries a version header on its first line, and Google has reissued the file repeatedly over the years, merging, splitting, and retiring nodes as it goes. Anything you hard-coded against an older release is a candidate for quiet breakage.

Element	What it looks like	How it behaves across versions
Version header	# Google_Product_Taxonomy_Version: 2021-09-21	Changes every time Google republishes the file
Category ID	1739	Holds steady for as long as the category exists
Category path	Hardware > Hardware Accessories > Hardware Fasteners > Nuts & Bolts	Rewords whenever Google renames any node in the chain

That difference in behavior is the whole argument for IDs. A path is a chain of four editorial strings, and a rename anywhere along the chain breaks the match for every SKU underneath it. An ID is one token Google controls and keeps pointed at the same concept.

Retirement is the case worth planning around. When Google retires a category, the ID stops validating on your next feed upload and surfaces as a hard error. That is the failure mode you want, because it forces a decision while somebody is still looking at the feed.

This is a taxonomy mapping problem with an external standard on the far side, the same shape as mapping to UNSPSC or ETIM. Google's taxonomy exists to route ads and enforce shopping policy, so the fit is worst exactly where your catalog is deepest.

What holds up in practice:

• The decision belongs at the category node. One mapping there covers a 4,000-SKU bolt category, and SKU-by-SKU review is where these projects stall.
• Leaf values carry the weight. "Hardware" (ID 632) is a legal value that tells Google almost nothing, while Hardware > Hardware Accessories > Hardware Fasteners (500054) narrows the field and 1739 lands it.
• Unmappable SKUs deserve a record. Some of the catalog has no honest home in Google's tree, and logging those items forces someone to make a real call on them.

The mapping table itself belongs in your PIM alongside your category tree, and Anglera does the work of building it and keeping it current as Google reshuffles branches.