Shipping products to Google Merchant Center

The first decision saves you from everything downstream. There is one source of truth for a product, and every channel is a projection of it. In the setups we build, the store’s own catalog is canonical, price, stock, title, images, identifiers and category in one model, and Google Merchant is a downstream consumer of it, like the storefront itself.

The alternative is a second source of truth, a nightly spreadsheet, a plugin with its own copy, a feed hand-edited for one product. Two sources of truth always disagree eventually, and when they do, Google shows a price that is not real, the customer clicks, and you have earned a disapproval in one move.

You can hand Google a scheduled file, a manual upload, or the Content API for Shopping. For anything with real inventory movement we use the API. A nightly file is fine for a catalog that never changes, but tyres, parts and serious retail move constantly, and waiting for the next fetch means the feed is wrong for hours at a time.

With the API we push each product as a structured item, then push only what changed. A price update is a small targeted call, not a full re-export. Stock hitting zero is sent the moment it happens. We keep the writes idempotent and let them retry, so a rate limit or transient error self-corrects on the next pass.

Here is the part the "just connect your store" tools skip. Google does not approve a product because you sent it. It approves a product because it is described well enough to be trusted, and disapproves the ones that are not.

The usual failures are boring and fixable, a missing GTIN, no brand, no unique identifier, a category that does not match the item, a title that is a slogan, an image with a watermark. Each is a rule, and each broken rule is a product pulled from search. We map these once, at the catalog level, so every product is born feed-ready.

• Identifiers: GTIN where it exists, brand plus MPN where it does not. Many products, tyres included, carry no clean GTIN.
• Google product category and product type, mapped from the store's own categories, not guessed per product.
• Title and description built from real attributes, size, spec, model, not slogans, because the title is what Google matches against.
• Price and availability that match the landing page exactly, including currency and tax for the market.
• Images that meet Google's rules, no overlays, promo text or watermarks.
• Shipping and identifier-exists signals set correctly so Google does not have to assume.

Even with clean data, Merchant Center will occasionally push back, a policy change, a tightened category, an identifier it wants verified. The difference between a healthy feed and a dying one is whether anyone is listening.

So we read the status back. Google reports per-product and account-level issues, and we pull those in rather than waiting for someone to notice traffic dropping. A disapproved item surfaces with its reason, grouped so one root cause across a hundred products reads as one problem. Fix the mapping rule once, the next sync clears the batch.

This is not theory for us. On TyreEurope, a pan-European tyre platform we built, the storefront’s catalogue is the canonical model and Google Merchant Center is wired in as a first-class channel. The platform generates the Shopping feed from the same product data that renders the site, gives every product and size its own SEO-ready landing page, and keeps price and availability in step with the warehouse through a real-time two-way ERP sync, so the listing Google shows is the product the shelf actually holds.

Because the feed and the storefront share one source of truth, the hard parts became small. EU energy labels are generated per product straight from the EPREL registry, identifiers and categories are mapped once at catalogue level, and a price change in the ERP reaches the site and the feed together. Nothing is exported, hand-edited or re-keyed.

The payoff is the order path. A buyer searches Google Shopping, sees a live listing with the real price and availability, and clicks straight onto the exact product page for that tyre and size, in their own language and market. The landing page matches the listing, because both are projections of the same catalogue, so there is no bait-and-switch moment and no disapproval risk.

From there it is a normal purchase. Checkout on the storefront, payment, and the order flowing straight into fulfilment through the same ERP sync that keeps stock honest. Purchases are tracked back against the Merchant Center account, so the business can see which listings actually turn into revenue, and the channel earns its budget with numbers rather than faith.

This work matters most where the catalog is large and the data is messy, which is where we spend a lot of our time. Tyre and parts retail is the hard version, tens of thousands of SKUs, supplier feeds that each describe a product differently, identifiers that are inconsistent, and stock that changes all day across suppliers.

Get the canonical catalog right and the same pipeline that keeps the storefront correct keeps Google Merchant correct, and Amazon, and the comparison feeds, from one model. The feed stops being a thing you babysit and becomes a thing that maintains itself.

If your listings keep dropping out of Google Shopping, the fix is almost never a better feed tool. It is one honest catalog, an API sync that keeps up with reality, attribute rules that live in the pipeline, and someone reading the disapprovals back. That is how we build it, and it is why the products stay up.