GOOGLE SHOPPING PRODUCT FEED REQUIREMENTS EXPLAINED

Most of the time someone asks me about the google shopping product feed requirements, they've already built a feed, uploaded it cleanly, and are staring at a set of products that simply refuse to show. The frustrating part is that nothing looks broken. The upload succeeded, there's no red banner, and yet half the catalog isn't serving. In my experience that's almost never a broken feed, it's a feed that's missing one of the mandatory feed attributes that Google requires for that specific product, and the failure happens quietly enough that people don't realise a requirement was even in play.

This article is about those silent blockers specifically, not a generic tour of every field you can submit. The reason I focus here is that the attributes which cause the most wasted time aren't the obvious ones like price or title that you'd never forget. They're the conditional ones, the requirements that only apply to your products because of the category they sit in or the country you sell to, and that a basic checklist won't warn you about. Get clear on which of those apply to your catalog and most disapprovals stop being a mystery and start being a to-do list.

I'll walk through it in the order I actually think about it on a live account, because the google shopping feed requirements only make sense once you see them in sequence: the difference between an accepted upload and an approved product, the universal fields, the conditional silent blockers, the fields that are present but still fail, and the diagnostic workflow that ties it all together. Along the way I'll be concrete about the specific product information Google looks at, because the abstraction of "meet the specification" is exactly what lets these problems hide. The goal is that by the end you can look at your own catalog and predict, category by category, which requirements are about to bite before Google tells you.

Accepted is not approved: where the requirements actually bite

The single most important distinction in this whole topic is that a successful upload only means Merchant Center accepted your data for processing. It does not mean a single product is approved to serve. Approval is a separate stage where each item is checked against the product data specification and Shopping policies, and that's the stage where the google shopping product feed requirements are enforced. I've watched teams celebrate a clean upload and then wonder for a week why impressions never arrived, because they treated the two events as one.

This matters because the enforcement is per-product, not per-feed. A feed can be 90% approved and 10% silently disapproved, and the account overview won't scream about it the way a total failure would. So the mental model I work from is that submitting the feed is the easy half; the requirements live in the approval layer underneath, and you only see them if you go looking. That's also why understanding the requirements is really an extension of the wider google shopping feed setup process rather than a separate task, the setup delivers the data, the requirements decide whether it's allowed to serve.

There's a second reason the accepted-versus-approved gap trips people up, and it's about how the pipeline is layered. When your google merchant center feed is ingested, Google first runs technical validation, essentially "is this well-formed and are the mandatory fields present," and only afterwards runs the policy and quality checks that decide whether it can actually display your products in the auction. A file can sail through the first layer and stall at the second, which is why the account can look healthy while a chunk of the catalog never earns an impression. Whenever someone tells me "the feed is fine, it uploaded," I hear "layer one passed," and I go straight to the diagnostics to see what layer two thinks, because that's where product listings are either cleared to serve or quietly held back.

The universal required attributes every product needs

Before any category logic kicks in, there's a floor that applies to essentially every product. At minimum each item needs an id, a title, a description, a link to the landing page, an image_link, a price, and an availability value. Miss any one of these product attributes and the product cannot serve, full stop. These are the requirements nobody forgets on purpose, but they still fail in practice when a connector exports an empty description for some SKUs, or when a handful of items lack an image URL that Google can actually crawl.

The id attribute is the one most people never think about because it "just works," but it earns attention. Your product id has to be unique and stable, ideally the SKU, and it must stay the same across updates. When I inherit an account where the id changes on every export, I know before I look that history, reviews, and learning have been silently resetting, because Google treats a changed product id as a brand-new item. It doesn't disapprove anything, so it's invisible on a checklist, yet it quietly kneecaps performance, which is the sort of soft failure that hides inside "the feed uploaded fine."

Two of these deserve a closer look because they're required in a way people underestimate. Availability has to match the landing page, so an item where the feed and page disagree about in stock or out of stock is heading for trouble; a listing that says the item is available while the page shows it sold out is a mismatch Google will act on, a plain in stock out of stock disagreement between feed and page. And image links must point to a crawlable image in an accepted format, which means a robots.txt that blocks Googlebot-image can disapprove your entire catalog's images at once even though every URL is technically present. The mandatory feed attributes at this level aren't hard to supply, but they are unforgiving about quality and consistency, not just presence.

The way Google actually uses these fields is worth internalising, because it changes how carefully you treat them. Your title and image are the two things that will show the product to a shopper in the results, so they're doing double duty: they're required for eligibility and they're the front line of whether anyone clicks. That's why I never treat product titles as a box to fill; the same field that satisfies a requirement is the one that decides your click-through rate. Meeting the requirement is the floor, and treating it as merely a floor is how good catalogs still underperform.

Sitting alongside these is the identifier question, which is where "required" gets its first asterisk. Brand is required for most new products, and you need either a GTIN or, when there's no manufacturer GTIN, an MPN. This is the point where a lot of feeds first hit a conditional rule without realising it, and it connects directly to the deeper mechanics of what a google shopping feed carries and why product identifiers pull so much weight in matching and ranking.

Product identifiers: the requirement that hides in plain sight

Unique product ids are the area where "required" is most conditional and most misunderstood, so they deserve their own section. The trio Google cares about here is brand, GTIN, and MPN, collectively the unique product identifiers that let Google match your item to the same product across the marketplace. For most new products with a manufacturer-assigned GTIN, you should submit it; leave it out and visibility is limited even though nothing is technically disapproved. When a product genuinely lacks a GTIN, you provide an MPN and brand instead, and set identifier_exists to no so Google knows the omission is intentional.

The trap that catches people is the opposite of a missing field: submitting a wrong or made-up GTIN. Google validates GTINs against the GS1 checksum rules, so an invented number doesn't slip through as "close enough," it disapproves the product outright. This is one of the few places where an honestly empty field, handled correctly, is genuinely safer than a populated one. I'd rather see identifier_exists set to no on a product with no real barcode than a plausible-looking guess, because the guess is a disapproval waiting to happen while the honest blank is compliant.

Media and apparel each bend this rule in their own way, which is exactly the kind of category nuance that makes the identifier requirement feel arbitrary. Books use ISBN as a GTIN, so a book without one sets identifier_exists to no rather than inventing a barcode. Apparel without a recognised brand can also set the flag to no. The underlying logic is consistent even when it looks fiddly: Google wants accurate identifiers where they exist and an honest signal where they don't, and both directions of dishonesty, a fake GTIN or a suppressed real one, degrade how well it can display your products against the right query.

The conditional attributes that block products in silence

This is the section that actually solves most of the disapprovals I get called in for. The silent blockers are the conditionally required attributes, the ones that aren't on a universal checklist because whether they apply depends on your category and target country. A feed that's perfectly valid for a homeware store will fail the moment you drop apparel into it, and the person building it often has no idea a new rule just switched on.

The clearest example is apparel. For clothing targeted at Brazil, France, Germany, Japan, the UK, and the US, Google requires color, size, gender, and age_group. None of these are required for a generic product, so they're easy to omit, and when you do, entire apparel lines disapprove together. Because the rule is category-and-country specific, it feels arbitrary from the outside, which is exactly why it eats so much troubleshooting time. The color size pairing in particular is the one I see missed most, because a merchant who's been running fine with homeware simply doesn't expect two new mandatory columns to appear the day they add a clothing range.

The other big one is variants. Any product sold in multiple versions needs an item_group_id tying those versions together, and the variant-defining attribute (color, size, and so on) must actually differ between them. Get this wrong and you don't just lose one product, you can cascade disapprovals across a whole variant group. Then there's the identifier trap covered above, now compounded by category: a product without a manufacturer GTIN needs an MPN, and the requirement stacks with the apparel rules so a single clothing SKU can owe Google half a dozen fields at once. If you want the authoritative, attribute-by-attribute breakdown of which fields are required, it depends, or optional for each category, Google's official product data specification is the document I keep open while diagnosing, because the conditional wording is the whole point of these product feed specifications.

Country is the multiplier that turns a manageable set of rules into a minefield. A catalog that's compliant for the US can break when you expand into Germany or Japan, because the same category can pick up new mandatory attributes purely from the target market. I've had a clean feed disapprove a whole apparel line the week a client added a new country, not because the products changed but because the requirement did. So when I map the mandatory feed attributes for an account, I don't map them once, I map them per category and per country, because that intersection is where the silent blockers actually live.

The optional attributes that quietly cost you performance

Not everything that hurts a feed is a hard requirement. There's a whole layer of optional attributes that won't disapprove a product but will hold back its performance, and lumping them in with "nice to have" is a mistake I see constantly. The failure mode here isn't a red error, it's a listing that serves but underperforms because you handed Google less to work with than a competitor did. In an auction, less product information is a competitive disadvantage even when it's technically allowed.

The two I push hardest on are google_product_category and product_type, because they're both easy to skip and both quietly consequential. Setting google product category explicitly overrides Google's automatic guess, which matters a lot for ambiguous items where the algorithm might file a product under the wrong tree entirely. And product types are your own taxonomy, the value you define and, importantly, the field Shopping campaigns use to organise bidding and reporting; skip it and you lose a clean way to structure the account later. Neither is on the required list, yet a feed that ignores both is one I'd expect to underperform a well-categorised competitor.

The same logic runs through the descriptive fields. A rich description, up to the 5000-character ceiling, gives Google more text to match against a query than a one-line stub does, and the additional_image_link attribute lets you add context images beyond the required main one. These are optional, so they never block anything, but they're the difference between a compliant feed and a competitive one. My rule of thumb: treat the required attributes as the price of entry and the high-value optional ones as where the actual performance is won.

Present but wrong: when a required field still fails

A subtler class of silent block happens when the required attribute is present but non-compliant, which is deceptive because a quick scan of the feed shows the column filled in. Title and description are required, but they also have to match the landing page and avoid promotional text, all-caps, and gimmicky characters, so a title stuffed with "FREE SHIPPING!!!" can be present and still trigger a policy disapproval. The field isn't empty, so nobody suspects it.

Titles are worth dwelling on because they fail in more ways than any other field. There's a hard limit of 150 characters, so an over-long title gets truncated, but the more common problem is content: a title that reads as a keyword dump, mismatches the landing page name, or leans on symbols will get flagged even though the character count is fine. When I audit product titles I'm checking three things at once, that they're within length, that they match the page, and that they lead with the attributes a shopper actually searches, because a title can satisfy the requirement and still be the reason the product loses the click.

The same present-but-wrong pattern shows up with price and stock. If the feed price doesn't match what a shopper sees at the landing page or checkout, that inconsistency is a disapproval reason in its own right, even though price is unambiguously supplied. Availability is the same story: an item that reads in stock but shows out of stock on the page is a mismatch, and Google is strict about it because a shopper clicking through to a sold-out product is a bad experience it's motivated to prevent. This is the category of problem where "I've filled in every required field" and "my products are disapproved" are both true at the same time, and where a lot of the real work of meeting the requirements actually lives. Because these overlap so heavily with the routine check I run on any new feed, they're best caught during structured Merchant Center feed verification rather than after a campaign is already spending against a half-approved catalog.

Images have their own present-but-wrong failures that catch people off guard. The image_link can be perfectly valid and the product still gets held back because the image itself carries a watermark, promotional overlay, or border, or because it's a placeholder rather than the real product. Google is also moving the minimum resolution floor to 500 by 500 pixels, with enforcement landing in early 2027, so an image that's compliant today can quietly slip below the bar. The lesson is the same across titles, prices, and images: presence is necessary but nowhere near sufficient, and the requirement is really about accuracy and quality, not a filled cell.

The workflow I use to trace a silent block

When a feed uploads clean but products won't serve, I don't re-check the whole specification from scratch, I let the diagnostics point me at the failing attribute. Merchant Center's Issue Details lists the specific attribute and the products it affects, which turns "something's wrong" into "these 40 apparel SKUs are missing size." That's the fastest route from symptom to cause, and it's the step people skip because the clean upload made them assume the job was done.

Once I know the attribute, I fix it at the source rather than patching individual products, because a conditional requirement almost always affects a group. If size is missing on apparel, the fix is in the data or the connector mapping, not in one row, and solving it there clears the whole group at once. Fixing at the source also protects you against regression: patch one product and the next export overwrites it, but fix the mapping and the whole category stays compliant on every refresh. This is the discipline that separates a feed that just barely serves from one built to scale, which ties back into how you structure Google Shopping as a system rather than a one-off upload.

The habit I'd most like to pass on is to build a standing map of your own requirements rather than rediscovering them every time something breaks. For each category you sell and each country you target, write down which attributes are required, which are the high-value optional ones, and where the present-but-wrong risks sit. That map is what lets me predict a disapproval before Google reports it, and it's the thing a generic checklist can never give you because it doesn't know your catalog. The practical takeaway is simple: treat every clean upload as unproven until diagnostics confirm approval, learn which conditional mandatory feed attributes apply to your specific catalog, keep your product identifiers and product information accurate rather than merely present, and fix requirements at the data layer so a category rule you didn't know about can never silently take a product group offline again. Do that and the shopping ads you eventually build sit on a feed that's genuinely eligible, not one that just looked eligible on upload day.