Google Ads

Feed Specification

Also called Product data specification, feed spec

Google's published rulebook of product attributes: which are required, which are optional, and what values each will accept.

Quick facts: Feed Specification

Category
Google Ads
Also called
Product data specification, feed spec
Level
Intermediate
Affects
Product approval, Shopping eligibility, search matching
Where to see it
Google Merchant Center (Diagnostics), Google's product data specification
In this article4
  1. What the feed specification defines
  2. Why the feed specification matters
  3. Common mistakes with the feed specification
  4. How to work with it

What the feed specification defines

The specification is the document Google publishes describing every attribute a product feed can contain, whether each one is required, and what a valid value looks like. It is the reference your feed is judged against, and every disapproval in Merchant Center traces back to a line in it.

Attributes fall into three groups. Some are required for every product — an identifier, a title, a link, an image, a price, an availability state. Some are conditionally required, meaning they only apply in certain categories or certain countries: clothing needs size and colour, some markets need particular shipping or tax detail. The rest are optional but often decisive, because they give Google information it uses to match your product to a search.

  • id — a permanent code that must never be reused for a different product
  • title — the text most often matched against a search query
  • availability — accepted only as one of Google’s fixed values, not your own wording
  • google_product_category — a value taken verbatim from Google’s own taxonomy

Why the feed specification matters

Shopping listings are not written by a copywriter; they are assembled from feed attributes. A missing brand, a vague title or an out-of-date price is not a cosmetic problem — it decides whether the product is eligible at all, and which searches it can appear for.

The specification also changes. Attributes are added, requirements tighten by category and country, and a feed that passed last year can start collecting warnings without anybody editing the shop. Knowing where the rulebook lives is what turns those warnings from a mystery into a task.

Common mistakes with the feed specification

Treating optional as unnecessary is the most expensive habit. Attributes that Google merely recommends are frequently the ones that decide matching, so a technically valid feed can still perform badly.

Format errors come next, and they are dull rather than difficult: a price without its currency code, a date in the wrong pattern, an availability value written in your own words, a category string invented rather than copied from Google’s taxonomy. Each one is rejected silently at item level while the feed as a whole still looks healthy.

Then there is identifier churn. Changing a product’s id because the shop was rebuilt destroys that product’s history and starts it again from nothing. And declaring that no identifier exists, purely to dodge a GTIN requirement on a product that plainly has one, tends to cost visibility rather than save effort.

How to work with it

Read the specification for the countries you actually sell to, not just your own, because conditional requirements differ. Map each required attribute to a real field in your shop before building the export, so nothing is filled in by hand and left to rot.

Write titles for people searching rather than for your internal catalogue — brand, product, key variant — and keep prices and availability flowing automatically from the shop. Then treat the Merchant Center diagnostics as a weekly job, since that is where the specification tells you, in detail, exactly which rule you broke. Ongoing feed management is mostly this: reading those messages and fixing the source.

Do and do not

Do

  • Read the specification for every country you sell to
  • Map each required attribute to a real shop field
  • Copy category values verbatim from Google's own taxonomy

Do not

  • Assume an optional attribute is a pointless one
  • Change product identifiers when the shop is rebuilt
  • Invent your own wording for fixed value fields

Questions people ask about this

Where do I actually find the feed specification?

Google publishes it in the Merchant Center help documentation as the product data specification, and it is updated as requirements change. Every diagnostic message in Merchant Center links to the relevant part of it. Bookmark the version for the country you sell to, because conditional requirements genuinely differ from market to market.

Do I have to fill in every optional attribute?

No, but the label is misleading. Optional means the feed will be accepted without it, not that the product will perform without it. Attributes describing brand, category, condition and variant help Google understand what you are selling and which searches to show it for, so the useful ones are worth the effort even though nothing forces them.

Can I change a product's id if my shop is rebuilt?

You can, but you lose that product's accumulated history and it effectively becomes a new item. Where a rebuild is unavoidable, keep the original identifiers by mapping them across from the old system rather than letting the new platform generate fresh ones. Reusing an old id for a genuinely different product is worse still, and against the rules.

Related terms

Found this useful?

Share it, or ask an AI to summarise it

Back to the glossary

Knowing the term is the easy part

Applying it to your own site and budget is the work. Book a call and I will tell you what actually applies to you.