← Back to blog
6 min readBy Feedyio

Google product category vs. product_type: how feed category mapping actually works

If you've ever opened the Google feed spec and wondered why there are two category fields, you're not alone. google_product_category and product_type sit next to each other, both hold a category path, and both look interchangeable - but they answer two different questions. One tells Google what kind of product you're selling (and therefore which rules and required fields apply to it). The other is your own filing system for organizing bids and reports. Mix them up and you either trip approval rules or lose the ability to bid the way you want. This guide explains what each field does, when to set google_product_category by hand, and how the two work together.

The two category fields, side by side

Here is the short version before the detail:

  • google_product_category - Google's own fixed taxonomy. It tells Google what category your product belongs to and is used to enforce category-specific rules and required attributes. There is one correct value per product, chosen from Google's list.
  • product_type - your own taxonomy. You define the values, usually mirroring your site's navigation. Google uses it to let you organize bidding, reporting and product groups; it does not affect approval.

The simplest way to keep them straight: google_product_category is Google's label for your product; product_type is your label for it.

google_product_category - Google's taxonomy

Every product in Merchant Center is assigned a category from Google's product taxonomy, a long, predefined tree of categories that Google maintains and updates over time. You submit the value in google_product_category, and you can send it in either of two formats - but never both at once:

  • The numeric category ID, for example 1604.
  • The full category path, for example Apparel & Accessories > Clothing > Dresses.

Send one or the other for a given item, not both. The numeric ID is the more robust choice because Google occasionally renames paths, and an ID won't break when wording changes.

✅ By ID

<g:google_product_category>1604</g:google_product_category>

✅ By full path

<g:google_product_category>Apparel &amp; Accessories &gt; Clothing &gt; Dresses</g:google_product_category>

❌ Wrong - a made-up category that isn't in Google's taxonomy

<g:google_product_category>Women &gt; Summer Dresses &gt; Floral</g:google_product_category>

That last value would be fine as a product_type, but it isn't a real node in Google's tree, so it doesn't belong in google_product_category. The value here has to match Google's list exactly.

Automatic categorization, and when to override it

You don't have to set google_product_category on every product. Google automatically assigns a category to each item using signals from your data - the title, description, price, brand and GTIN. The better and more specific that data is, the more accurate the automatic categorization tends to be. For a large catalog of clearly described products, the automatic value is often good enough.

When you do submit google_product_category, it overrides Google's automatic guess. So the question isn't "should I always fill this in" - it's "when is overriding worth the effort". Set it manually in these cases:

  • The product is in a category with special required attributes. Categories like Apparel & Accessories require attributes such as gender, age_group, size and color; Mobile Phones and Software have their own rules. If Google miscategorizes the item, it may apply the wrong required-attribute set - so pinning the right category keeps the requirements aligned with what you actually send.
  • The automatic category is plainly wrong. Ambiguous titles ("Galaxy", "Apple", "Boxer") can land a product in the wrong branch. A correct value fixes it.
  • You're targeting campaigns by category and need the assignment to be predictable rather than inferred.
  • Age-restricted or regulated products (for example alcohol), where the category drives compliance handling.

If none of those apply and your titles and descriptions are solid, letting Google categorize automatically is a reasonable default.

product_type - your own taxonomy for bidding and reporting

product_type is the field you control completely. There's no fixed list: you put in whatever category string you want, and the convention is a full path that mirrors your own site structure.

✅ Your own taxonomy, full-path style

<g:product_type>Home &gt; Women &gt; Dresses &gt; Summer Dresses</g:product_type>

Because it reflects how you think about your catalog, product_type is what you use to slice the catalog in Google Ads - building product groups, setting different bids per part of the range, and reading performance by your own categories rather than Google's. A useful detail for PPC managers: outside a small set of countries, it's product_type - not google_product_category - that's available for organizing Shopping product groups for bidding. So if your bidding structure depends on category, product_type is usually the field doing the work.

You can submit more than one product_type value per product if an item belongs in several of your own categories; Google uses the first one for product groups. Keep the paths consistent across the catalog, because inconsistent labels ("Womens" vs "Women's" vs "Women") fragment your product groups and make reporting messy.

Why category choice affects approval and performance

The two fields fail in different ways, which is the real reason to keep them straight.

google_product_category affects approval. Because it determines which rules and required attributes apply, a wrong category can cascade: a non-apparel category won't ask for size or age_group, so a misfiled clothing item might pass the wrong checks and then underperform - or, in regulated categories, a wrong value can put a product through the wrong policy path. Getting this field right is about compliance and being eligible for the correct surfaces.

product_type affects how well you can manage and optimize. It never gets a product disapproved, but a missing or sloppy product_type means you can't build the bidding and reporting structure you want - everything collapses into one undifferentiated bucket. Getting this field right is about control and performance, not approval.

In practice the strongest feeds carry both: an accurate google_product_category (set manually where it matters, left automatic where it doesn't) and a clean, consistent product_type that mirrors your site.

How Feedyio maps your Shopify categories to the feed

On Shopify your products already carry a product type and sit in collections, and Feedyio turns that structure into both feed fields. It maps your Shopify product types and collections to product_type so your own taxonomy carries through to Google Ads for bidding and reporting, and it lets you map to Google's taxonomy for google_product_category - by category, so you set a branch once rather than editing products one by one. Where a category has special required attributes, getting google_product_category right is what keeps those requirements aligned, which ties directly into our guides on the most common Merchant Center disapprovals and on product identifiers. The result is a clean Google Merchant Center feed where Google's category and your own category each do their job.

Want your Shopify collections and product types mapped to the Google taxonomy automatically? Try Feedyio free on the Shopify App Store.