Why the feed is the whole game
Google Shopping does not read your website. It reads your feed. Everything a shopper sees in a Shopping result — the title, the price, the availability, the image, whether the item appears at all — comes from a data file, not from the beautiful product page you paid for. A store can be perfect and invisible.
That makes the feed the highest-leverage and least-loved artefact in e-commerce. It is also the one nobody owns: the developer thinks it is marketing's, marketing thinks it is the developer's, and the platform's default export sits in between doing an adequate job on small catalogues and a poor one on large ones.
The number, and what the missing 5.5% is
Beds.ie sells beds, mattresses and bedroom furniture — more than 17,000 products across the catalogue. As of the sync log read on 4 September 2026, 16,281 of 17,233 submitted items are live in Merchant Centre. That is 94.5%.
I want to be precise about what that figure is and is not. It is not "we fixed everything". A catalogue that size is never at 100%, and a studio claiming it would be telling you either that their catalogue is tiny or that they are not looking closely. The 952 items that are not live are made up of genuinely discontinued lines that have not yet dropped out of the export, variants that should never have been submitted separately, and a residue of image and attribute problems that are worked through as they surface.
The useful claim is not the percentage. It is that the number is known, is monitored, and moves in one direction. Before the work, nobody could have told you what it was.
| Measure | Value |
|---|---|
| Items submitted | 17,233 |
| Items live | 16,281 |
| Approval rate | 94.5% |
| Reporting | Sync log records every rejection with its reason |
Source: Merchant Centre sync log, 4 September 2026
What actually gets items rejected
In order of how often they cost real money, not in order of how loudly Merchant Centre complains.
- Missing or wrong unique product identifiers. GTIN, brand and MPN. Google uses these to know what the thing IS, and an item it cannot identify competes badly even when it is not rejected outright. On furniture — a category full of own-brand and made-to-order lines — this is the single biggest piece of work, because the correct answer is often "this product genuinely has no GTIN", and that has to be declared properly rather than left blank.
- Price and availability mismatches between the feed and the landing page. Google checks. If the feed says £299 and the page says £319 because a sale ended overnight, the item is disapproved for a mismatch and the whole account's trust degrades.
- Image problems. Placeholder images, watermarks, promotional text burnt into the picture, or images too small. Furniture retailers inherit supplier photography, and supplier photography is full of logos.
- Missing required attributes for the category. Size, colour and age group are conditionally required depending on what you are selling, and "conditionally" is doing an enormous amount of work in that sentence.
- Landing page problems. A 404, a redirect chain, a page blocked to Googlebot, or a page that renders nothing without JavaScript.
- Policy categories. Rarer, but absolute — and worth checking before you assume a rejection is technical.
Notice that four of those six are data problems and none of them are design problems. This is why a store can look immaculate and sell nothing through Shopping.
What the work on Beds.ie actually was
Three things, in this order. The order matters, because doing them in a different one wastes weeks.
One: make the catalogue legible before touching the feed
The category structure came first. All 17,789 products were reorganised into a crawlable, logical hierarchy rather than a flat list. That is usually described as an SEO job, and it is, but it is also a feed job: product type and Google product category are derived from where a product actually sits, and you cannot derive a sensible product type from a flat list of everything.
Two: enrich and validate the data at source
Product-data enrichment and validation was automated, so that attributes are correct in the catalogue rather than patched on the way out. A feed is a projection of your product data. Fixing the projection while leaving the data wrong means fixing it again next month, and the month after, for ever.
Three: make the sync report rejections instead of hiding them
This is the part I would keep if I could only keep one. The sync was wired so that rejections are reported with their reasons rather than silently dropped. Before that, an item that failed simply was not there — indistinguishable from an item that had been deliberately excluded, or one that had never existed. A rejection you can see is a task. A rejection you cannot see is a permanent, invisible revenue loss.
What I got wrong
The first instinct on a catalogue this size is to chase the approval percentage, because it is the number on the screen. That is the wrong target, and I spent time on it before working that out.
Some of those rejected items were rejected correctly. Discontinued lines, duplicate variants, products that should never have been in the feed in the first place. Pushing them through would have raised the percentage and lowered the quality of the account — and a Shopping campaign spending money on out-of-stock lines is worse than one that never saw them.
The target that survived contact with reality is: every rejection is either fixed or deliberately accepted, with a reason recorded. The percentage is a by-product. It is a slower-looking metric and a much better one.
How to audit your own feed in an afternoon
You do not need a tool for this. You need two hours and a willingness to look at the number nobody has looked at.
- In Merchant Centre, find the count of items submitted and the count of items active. Write both down. Most people have never seen these two numbers next to each other and the gap is often a genuine surprise.
- Sort the disapproval reasons by number of items affected. Almost always, two or three reasons account for the large majority. Fix in that order, not in the order the interface lists them.
- Take the ten highest-margin products you sell and check each one is live. Approval rate is an average; averages hide the specific catastrophe of your best seller being invisible since March.
- Compare a feed row against its live page for price and availability. Do this on a product that has recently been on offer, because that is where mismatches live.
- Check whether anything is reporting rejections to a human. If the answer is "we look in Merchant Centre sometimes", that is the actual finding of the audit.
- Check the identifiers on a sample of own-brand products. If GTIN is blank and nothing declares that the product genuinely has none, that is usually the largest single fixable group.
If that afternoon finds a gap of more than a few percent on a catalogue of any size, the fix is almost never in Merchant Centre. It is in your product data, and it will stay fixed only if it is fixed there.
The feed and the organic catalogue are the same problem
The work that fixed the feed also moved organic search, and it is worth understanding why, because it changes how you budget for it.
Between April and August 2026 — the same five months — Beds.ie went from 672 to 7,781 organic clicks a month, impressions from 38,608 to 282,069, and the number of distinct queries the site appears for from 5,189 to 24,054 (Google Search Console, full calendar months). None of that was a separate Shopping project. Structure, product data and technical foundations are the inputs to both systems. Do them once and both improve.
That is the practical argument for treating a shopping feed as a catalogue problem rather than an advertising problem: the same fix is paid for twice.
