The feed fields that actually decide whether you show
The product data specification lists dozens of attributes without ranking them. Working through it top to bottom is how a feed project takes six weeks and still gets disapproved.
Google's product data specification marks attributes as required, it depends, or optional, and that is the only ranking it gives you. In practice the attributes divide into three tiers by consequence: ones whose absence stops the item serving at all, ones whose wrongness gets the item disapproved after it has already been submitted, and ones that only affect how well the item competes. Fix them in that order, because the second tier is where the expensive surprises live.
Three tiers, not one long list
The product data specification is the authority here, and it is organised by subject: basic product data, price and availability, category, identifiers, and so on. That organisation is right for a reference document and wrong for a work plan.
The ranking that matters is by consequence. Google's own definition of required is blunt: submit this attribute, and if you do not, your product will not be able to serve in ads and free listings. That is tier one, and it is short.
Tier two is the set of attributes that are present but wrong. These are worse than missing ones, because a missing required attribute fails immediately and visibly while a wrong value passes ingestion and then gets the item disapproved days later, often in a subset of countries. The spec is explicit about one of these: submit a product with an incorrect MPN value and your product will be disapproved.
Tier three is everything that affects how well an item competes rather than whether it appears. Those attributes are worth real effort, but only after the first two tiers are clean, because a beautifully optimised title on a disapproved item does nothing.
The ranking, with the failure mode attached
| Tier | Attributes | What goes wrong |
|---|---|---|
| 1. Item cannot serve | id, title, description, link, image_link, price, availability | Required by the spec. Missing one and the item is not eligible at all |
| 2. Item serves, then gets disapproved | gtin, mpn, brand, identifier_exists, google_product_category | Passes ingestion, fails validation or policy later, often per country |
| 2b. Item serves for a while, then stops | Any attribute on a product not refreshed inside the cadence Google asks for | Silent expiry rather than a disapproval, so nobody gets an alert |
| 3. Item serves worse than it should | product_type, item_group_id, colour, size, age_group, additional_image_link | No error anywhere. The item just loses auctions and nobody knows why |
The row people underestimate is 2b. Google's guidance on managing products is that to keep products relevant and prevent expiration you should update or refresh them with a regular cadence, at least every thirty days. There is no disapproval attached to letting that lapse. The item simply stops.
That is the single most common cause of a catalogue that quietly shrinks over a quarter while nobody reports a problem. The dashboard shows approved items and the count drifts down, and because there is no error to read, the drop gets blamed on demand.
Tier one, and the two fields people get wrong inside it
The required set is small enough to memorise: id, title, description, link, image_link, price and availability. Two of them are where the errors concentrate.
The id is capped at fifty characters in the spec, and the guidance is to use the product's SKU where possible, keep it the same when updating your data, and use the same id for the same product across countries or languages. That last clause is the one that bites multi-country retailers. A pipeline that appends a country suffix to the id has just told Google these are different products, and every performance signal the item accumulated in one market is unavailable to the other.
The image_link is the other. It has to be crawlable, which means the robots.txt on the image host cannot block Googlebot or Googlebot-image, and the spec says so directly. I have found this exact defect twice: a retailer serving product images from a subdomain with a blanket disallow, wondering why images failed while the pages themselves were fine. Nothing in the feed is wrong. The block is on a different host.
Google also announced an image size requirement of at least 500 by 500 pixels for all product images, with enforcement beginning 31 January 2027. If your product images come out of a legacy CMS at 300 pixels square, that is a content migration and not a feed change, and it needs to be on somebody's plan rather than discovered on the enforcement date.
Tier two: values that pass ingestion and fail later
This tier is why feed work is deceptive. The file uploads, the item count looks right, and the failures arrive two days later attached to a subset of the catalogue.
Identifiers are the biggest contributor. The spec requires brand for all new products except movies, books and musical recording brands, caps it at seventy characters, and explicitly tells you not to submit values such as N/A, Generic, No brand or Does not exist. Every one of those strings appears in real feeds, usually because a template filled a null with a placeholder. That is a whole subject of its own, which is why identifier requirements get their own article.
Category is the second. The spec allows either the full category path or the numerical category id from the Google product taxonomy, but not both, and recommends the id. Sending both is a common transformation bug in feeds assembled by concatenating fields.
The mechanism to watch for is that these failures are reported per country. Google's product resource reports approved, pending and disapproved country lists separately for each reporting context. An item can be live in Canada and disapproved in the United States on the same feed row, so a single approved-or-not number in a dashboard is hiding information you need.
Tier three: the fields that decide how well you compete
Title is technically tier one, because a missing title stops the item. Title quality is tier three, and it is the highest-leverage tier three work there is. The spec caps it at 150 characters, tells you to match the title on the landing page, and tells you not to include promotional text such as free shipping, all capitals, or gimmicky characters.
The variant attributes are next. Getting item_group_id, colour and size right is what lets Google understand that eight rows are one product in eight sizes rather than eight unrelated items. The spec is precise about the pattern: the same item_group_id across all variants, different values for the varying dimension.
Then product_type, which is your own taxonomy rather than Google's, and which the spec caps at 750 alphanumeric characters. It does nothing for eligibility. It does a great deal for how you can segment campaigns, and the confusion between it and google_product_category is common enough that it deserves its own explanation.
Descriptions run to 5000 characters in the spec, which is far more room than most retailers use. That is not an argument for filling it. It is an argument for putting the actual product information there rather than shipping and returns boilerplate, which the spec asks you to leave out.
How I would sequence the work
Start by counting. Pull the processed products through the Products sub-API rather than reading the interface, and count items by status and by country. A tier-one gap and a tier-two gap look identical in a summary count and completely different in the detail.
Fix tier one across the whole catalogue before touching anything else. It is usually a small number of rows and it is always worth doing first, because those items are contributing nothing right now.
Then work tier two by volume, largest issue first. This is the part that feels slow and is not: the same root cause usually explains thousands of rows, and fixing it once moves the whole block. That is the argument behind triaging disapprovals by cause rather than by item.
Only then spend time on titles and variants. It is the most enjoyable part of the work and the least urgent, and doing it first is how a feed project produces a beautiful catalogue that half serves.
The engagement behind the self-storage case note drove cost per acquisition to roughly half the target, and none of that came from clever bidding. It came from the account being able to see what it was buying. Feed hygiene is the same class of work: unglamorous, upstream, and the reason the clever parts can pay off. If you are inheriting a catalogue with no idea which tier the problems sit in, that is what a structural account audit is for.