Your products in Google Shopping: the feed, the errors, and what actually changes

The question always arrives after launch, always phrased the same way: should we put the products in Google Shopping? The answer is almost always yes, since free listings exist and cost nothing but setup work. It's one of the first things we wire up on the stores we host on a subscription. But the phrasing hides a stubborn misconception.

Google Shopping isn't a button you switch on. It's a second, machine-readable copy of your catalogue that Google continuously reconciles against your site. Merchant Center holds that copy; your store holds the original. As long as the two tell the same story, your products circulate. The moment they diverge, on a price, an availability, a language, a greyed-out buy button, Google disapproves the product and tells you so in a diagnostics table nobody reads.

Almost everything that goes wrong in Merchant Center is a synchronization problem, not a marketing one. So it gets fixed with discipline. Budget doesn't help.

The short answer, for the busy

Google Shopping runs on a data source, formerly called a feed: a structured file, one row per product, that your store sends to Google Merchant Center. The specification requires id, title, description, link, image_link, availability and price. The brand attribute is required for all new products except movies, books and musical recordings, gtin is strongly recommended when one exists, and mpn becomes required when the manufacturer assigned no barcode. The same account feeds both free listings, which are on by default on new accounts, and paid Shopping ads. That source comes from a platform connector, an uploaded file, or the Merchant API. In Canada, the currency is the Canadian dollar, the submitted price must exclude tax, and both configuring shipping settings and publishing a return policy are mandatory. Disapprovals almost all come from a gap between what the feed says and what the product page shows.

What a data source really is

Google renamed feeds "data sources", and the word is better. Each item is described in a fixed vocabulary: one row per product, one column per attribute, with 150 characters for title and 5,000 for description. The specification sorts every attribute into required, optional, or "it depends", the last meaning it becomes mandatory depending on the product or the target country. The consequence of a missing required attribute is spelled out: the product won't be able to serve in ads or in free listings.

A connector wired into your store keeps that copy current, and so does the Merchant API. An uploaded spreadsheet is defensible for thirty stable SKUs and ruinous once prices move. Either way, Google will then read your product page and compare. The Product markup already sitting on your pages is exactly what it reads, a subject we covered separately in our article on product pages that rank.

Free and paid come out of the same account

Merchant Center feeds two things. Free listings, on by default on a new account: your products can appear in Search, the Shopping tab, Google Images, Google Lens, YouTube, Gemini, Maps and the products module on your Business Profile. And Shopping ads, driven from Google Ads.

Coverage isn't uniform. Rich results in Search are available globally, as are Google Images and Google Lens. The Shopping tab is available to users in Canada, and the Shopping Knowledge Panel names Canada explicitly. The "Popular Products" carousel for apparel exists only in the US, on mobile. A Quebec store gets the essentials, without getting everything.

Two eligibility conditions are easy to miss because they have nothing to do with the feed: your return policy has to be published on your site, and shipping settings are mandatory in Canada as in about thirty other countries. A flawless catalogue with no shipping configured doesn't serve.

Disapprovals are gaps, not punishments

The most common reason carries an unappealing name, "mismatched value", and describes something mundane: the price or availability in your data source doesn't match what the crawler finds on the page. Google's logic is blunt: someone clicking through expects the same availability on your page, and a gap makes you pay for wasted clicks.

The real causes are prosaic. A sold-out product still shown as available. A pre-order item presented as in stock, when Google expects the preorder value plus an availability_date visible on the page. A greyed-out buy button with no text clearly stating the item is gone. Or stale markup left in a theme somebody edited two years ago.

Google cushions this with automations, enabled by default, which read your page and correct price, sale price, availability and condition. The example comes from its own documentation: if your upload says $4 and the page says $3, $3 is what gets served. It's a net, and Google says so itself: automations don't replace regular updates and can't cover all of your products.

The other common disapprovals are about identification and images. With no manufacturer barcode, you need brand plus mpn. Images must show the product, with no border, no logo standing in for the photo, and no promotional element covering the item, which rules out the "-30%" badges stores burn into their visuals. An all-caps title gets refused too. And there's a date for the calendar: Google is imposing a minimum image size of 500 x 500 pixels for all product images starting January 31, 2027, and recommends 1,500 x 1,500. If your catalogue still carries 300-pixel thumbnails, the inventory happens now.

Two administrative rules close it out. New products go through a three to five business day review after the first sync, so early silence is normal. And an account has to be opened at least once every 14 months to stay active, which explains plenty of dead accounts belonging to clients who "already did this once".

The Quebec details: French, dollars, tax excluded

This is where local stores get caught, because the rule is linguistic before it is technical. Google asks for the same language across three things: your website, the product data you submit, and the language declared when you register the source. Landing pages have to be in that language, as do the navigation and checkout elements a buyer needs to make a decision, and if the majority of your data doesn't match the declared language, your products can be disapproved.

In practice, for a bilingual store: a French data source points to French URLs, and English, if it exists, forms a second source pointing to English URLs. A French feed sending people to English pages is a disapproval reason.

On the money side, Canada has its own rule and it surprises people: the currency is the Canadian dollar, and the submitted price must exclude all tax, the opposite of Europe where VAT is included. So you advertise $34.99 in Shopping and GST and QST get added at checkout, which is compliant as long as those taxes are properly displayed on your checkout pages. The tax attribute itself is US-only.

Shopify, WooCommerce, or a file

On Shopify, the Google & YouTube channel syncs products along with your shipping and tax settings, and lets you pick which countries and languages from Shopify Markets get sent to Merchant Center. Google's prerequisites are spelled out plainly there: no password-protected store, a valid payment provider, refund policy and terms of service in the footer menu, visible contact information, and shipping to a supported country in a matching currency. One warning: if a feed already existed in your account, connecting overwrites it.

On WooCommerce, the Google for WooCommerce extension plays the same role, with one quirk that matters here. Multilingual feeds depend on WPML and its multi-currency companion; without them, no separate French market. And its documentation sets a limit merchants discover too late: only products actually translated into a market's language make it into that market's feed. Twenty products in English, ten translated into French, and your French feed holds ten. For Canada and the US, the extension sends prices excluding tax automatically.

Which platform you run changes what this machinery costs to maintain week to week, which we detail in our comparison of Shopify and a custom store.

What Shopping will not do for you

Here's the part a vendor rarely has an interest in saying. Shopping is a distribution channel, not a demand generator. The system matches your products against what people are already searching for: a product type, a model, a part number. Google says it plainly: turning on free listings doesn't guarantee your products will be shown, since everything rests on matching your data to what customers search.

If nobody searches your category, Shopping won't create that search. It excels on products people name and compare, and does nothing for an unknown brand selling an object with no known name. The money is better spent elsewhere, and saying so costs less than six months of testing. Second limit: Shopping sends people to a product page. If that page repeats the manufacturer's description and shows three blurry photos, the click is bought and lost in the same place.

Where to start

Take the twenty products that carry most of your sales and make them faultless before wiring anything up: a readable title, a description written for a buyer, a barcode or brand plus mpn, a clean photo of at least 500 x 500 pixels. Then install your platform's connector, configure shipping, publish your return policy, and let the first review pass. For the first month, open the diagnostics weekly and fix every gap at the source, in the store, never in the feed. Paid ads come after, once free listings have shown what catches.

If you'd rather we look at your catalogue first, tell us how many SKUs you carry, which platform you're on, and whether your store is bilingual. It's the work we do upstream when helping someone start an online store.

→ Get in touch