Google Shopping reads your feed twice, for two different purposes, and most stores only ever hear about the first one. The first read is compliance: are the required fields present, is the price consistent with the landing page, does the image resolve. Merchant Center reports on that, loudly, and a failure means the product is not listed at all. The second read is matching: given a shopper’s query, is there anything in this product’s text that says it is the thing being asked for. Nothing reports on that. A product can be fully approved and simply never shown.
That split is the whole of feed optimization for Shopping. Compliance gets you into the auction. The text decides whether you are in the right auction. This page is about both, in the order they matter, and it stays specific to Google: if you want the channel-agnostic version, the product feed optimization guide covers what to fix in what order across every destination.
What Google actually reads
Google does not crawl your product page to build a Shopping listing. It reads the row you sent it. If the row says less than the page does, the page’s extra detail is invisible to the auction. This surprises people who have spent months on their product descriptions, and it is the single most useful thing to understand about the channel. If you have not looked at a feed row field by field, what a product feed contains walks through one real product.
Within that row, the fields do different jobs, and it is worth being blunt about which ones carry weight:
- title: the field that does the most work by a wide margin. It is what the query is matched against, and it is what a shopper reads in the listing.
- gtin, mpn, brand: identity. Without them Google often cannot tell that your product and a competitor’s are the same thing, which costs you the comparison entirely.
- google_product_category: which taxonomy branch you are competing in. Wrong branch, wrong competitors, wrong benchmark price.
- price and availability: checked against the landing page. A mismatch is a disapproval, not a warning.
- image_link: a resolution and a resolvable URL. Blocked hotlinking is a common and invisible cause of failure.
- description: read, but weighted far below the title. Useful for attributes that do not fit a title.
Titles: write for the query, not for the brand
The most common title in an unoptimised feed is the product name as the store’s own catalog records it. “Chino sand 32” is a perfectly good internal label and a bad Shopping title, because nobody searches that. A shopper searches “sand chino trousers 32” or “men’s slim fit chinos beige”.
A title that matches queries carries the attributes a shopper would name. For apparel that is usually brand, product type, key attribute, colour, size. For electronics it is brand, model number, capacity. The order matters because the beginning of the title is what survives truncation in the listing.
Two things worth saying plainly. First, this is not keyword stuffing: a title crammed with terms the product does not have will get clicks that do not convert, and Google’s own systems learn from that. Second, the attributes have to already exist in your data. If the feed has no colour field, no title rewrite can add the colour honestly, and the fix is upstream in the catalog rather than in the title.
google_product_category and product_type are not the same field
This one costs real money and is genuinely easy to get wrong. google_product_category is Google’s own taxonomy, roughly five and a half thousand fixed categories, and it decides who you are benchmarked against. product_type is your own category string, free text, and it is useful for structuring campaigns and bidding.
Sending your own category name in the Google field does not fail loudly. Google will often accept it and then place the product in whatever branch it can infer, or in none. The symptom is not a disapproval, it is a product that gets impressions in the wrong context at the wrong benchmark price. Half a catalog sitting in an unmapped or wrongly mapped category is one of the larger silent losses in a Shopping account.
If your store is in Turkey, use the official Turkish taxonomy path rather than translating the English one yourself. The Turkish tree is not a word-for-word translation and an invented path will not match.
Merchant Center is a feedback loop, not a gate
Most stores treat Merchant Center as a door: get through it, forget it. It is more useful read as a report. The disapproval reasons are grouped, they name the products, and they are readable over the Content API, which means they can be pulled back into the feed workflow rather than checked by hand in a browser.
The reasons cluster into a small number of causes far more often than the count suggests. Six hundred disapprovals is usually four problems. Working them by cause rather than by product is the difference between a morning and a quarter; every Merchant Center disapproval reason and its fix goes through them one at a time.
Two loop-closing habits that pay for themselves. Check the report after every feed change rather than on a schedule, because a change that fixes four hundred products and breaks twelve is a good trade you want to know about. And treat a rising “limited performance” or account-level warning as a data problem first: it is more often a missing identifier or an image than a bidding decision.
What Shopping rewards beyond compliance
Approved is the floor. A few things measurably help beyond it, and none of them are tricks:
- Identifiers on everything that has one. A GTIN lets Google match your product to the same product elsewhere, which is what puts you in a comparison rather than alone. For genuinely unique products,
identifier_exists=nois the correct answer, not a blank field. - Images that fill the frame. Above the minimum is not the same as good. A product shot with a lot of white space loses to one where the product is the image, at the same resolution.
- Price that matches, to the decimal. Including tax handling. A VAT-inclusive feed price against a VAT-exclusive page price is a disapproval that reads like a mystery until you check.
- Attributes that answer the obvious question. Size, colour and material for apparel. These feed both the match and the shopper’s decision.
- Freshness. An availability field that lags reality by a day produces clicks on things you cannot ship, and that is a worse outcome than not being shown.
Fix the export, not the source
The practical objection to all of this is that editing thousands of titles in the store back end is not a project anyone wants. It is also the wrong place to do it. Your store’s catalog exists to run your store; a Shopping title is a channel requirement and it does not belong in your product database.
The workable shape is a layer between the two: the source feed stays exactly as your platform emits it, replacements are written into separate fields, and they are applied at export. That way a title rule can be changed without a catalog migration, a change can be reverted, and next week’s new products inherit the same rule rather than needing the same manual pass. Google’s supplemental feeds do a narrow version of this, and a feed layer does the general version.
How to tell whether it worked
Impressions are the first thing to move, and they move before revenue does. A title fix that finally matches the query shows up as more impressions on more search terms, at first with worse click-through, because you are now appearing for queries you were previously invisible to. That dip is expected and it settles.
Watch these, in this order: approved product count, then impressions and the number of distinct search terms, then click-through, then conversion rate. If approved count is flat and impressions are flat, the change did not reach the auction and something is wrong with the export rather than with the copy. And give it a fortnight before drawing a conclusion, because the feed refresh, the crawl of your landing pages and the learning on the campaign side do not finish on the same day.
If you want the starting numbers before doing any of this, a free feed scan grades every product and ranks the fixes by how many points each one recovers. It is read only, so nothing is written back to your store.
Frequently asked questions
Is Google Shopping feed optimization different from product feed optimization?
The compliance half is Google-specific: the required fields, the taxonomy, the disapproval reasons and the Merchant Center loop are all Google’s. The matching half generalises, because every channel that reads a feed reads the title first. Doing the Google work well gets you most of the way on Meta and the price comparison sites too.
How long should a Shopping title be?
Long enough to carry the attributes a shopper would name, and front-loaded so the important part survives truncation. Padding a title to fill the field is worse than a shorter accurate one: the tail gets ignored and the irrelevant terms attract clicks that do not convert.
Do I need a GTIN for every product?
For anything manufactured with one, yes, and leaving it blank costs you the comparison. For genuinely own-production items there is no GTIN to find, and the correct answer is identifier_exists=no with brand and MPN filled in. Inventing a number is worse than declaring you do not have one.
Will fixing the feed help my organic search too?
Partly, and not through the feed itself. The feed is not an organic ranking input, but the work of getting real attributes onto every product usually improves the product pages as well, and those are indexed. The gain is real and it is a side effect rather than the mechanism.
Does any of this matter for AI shopping assistants?
More than for Shopping, if anything. An assistant has no listing grid to browse and no image to fall back on: it answers from the structured text. A feed that is merely compliant can still say nothing an assistant can act on, which is a different question from whether Google accepted it. Whether your store is invisible in AI search is about that second reading.
