Getting a Magento catalogue into Google Shopping, and keeping it there

A merchant who sells on Google Shopping has the same week every week. Export the catalogue. Fix the columns Google rejected. Upload again. Notice on Thursday that a price changed on Monday and the feed still shows the old one. Multiply by the number of store views selling in different countries, and the export becomes a job someone owns rather than a thing that happens.

Google Merchant Feed moves that work inside Adobe Commerce and Magento Open Source, onto your own server, and makes it a setting rather than a routine.

What it is for

The extension keeps your Google Merchant Center product data in step with your catalogue, without a spreadsheet in the loop and without sending your catalogue through anyone else's service on the way. Values come out of Magento through a mapping you configure: nothing is inferred, nothing is generated, and the same resolved payload you see in the admin preview is the one Google receives.

It is scoped the way a real store is scoped. Merchant account, data source, credentials, feed label, delivery mode, file path and format are all per store view, so a single installation can push a production account for one country while another store view sits in sandbox.

How it can be used

As a file Google collects. In Scheduled Fetch mode the extension writes a static feed file under pub/media/ and publishes it at a URL. Google pulls it on its own schedule. There is no service account, no OAuth consent, no API quota and no Google Cloud project to register – and optional HTTP Basic authentication on the download URL if you would rather the feed were not public. For most merchants this is the shortest path from installation to products in Merchant Center, and it cannot be broken by an API deprecation, because Google is simply downloading a file over HTTP.

As a live push. In Merchant API mode each product goes to Google over Merchant API v1, driven by a sync queue and Magento cron: a full sync on a frequency you choose, and an incremental pass every ten minutes for what changed. This is the mode for catalogues where a price or a stock state going stale for a day costs money.

Both at once, in different countries. Delivery mode is per store view, so the choice is not a store-wide commitment. A merchant can run the API push where the volume justifies the credentials and leave the smaller locales on a fetched file.

From a deployment script. bin/magento gm:export writes the feed to stdout, to a file, or straight to the Scheduled Fetch path. bin/magento gm:sync --dry-run prints the exact JSON body a product would be sent as – which is the thing you want in front of you when Google rejects a product and you need to know why, rather than a summary of what the extension believes it sent.

How it compares

The category is crowded and mature. Measured on 2026-08-24 by reading the structured data on the Adobe Commerce Marketplace listings themselves, seven comparable feed extensions sit mostly in one place: five of seven under Sales → Marketplace Feeds (four of those also carrying Comparison Shopping Engines), the remaining two under Marketing → Advertising. Published prices across that set run from about 40 to 500 US dollars, one-time.

What they have in common is the shape of the work: generate an XML feed, run it on cron, map Magento attributes onto Google's. Several go further than this extension does – promotions feeds, local inventory feeds, FTP and SFTP delivery, multi-channel output beyond Google. If any of those is on your list, buy the extension that has it.

Three things this extension does differently, each of which you can check before you trust it:

Delivery is a choice, and one option costs no credentials at all. Most feed extensions assume one path. Here the merchant picks, per store view, between a file Google fetches and a queue that pushes over the API – and the file path needs no Google Cloud project, no service account and no API registration, which is exactly the part of a Merchant Center setup that stalls.

Everything is verifiable before it is live. Sandbox mode exercises the whole pipeline – queue, cron, mass actions, command line – with fabricated responses and no outbound call. The dry run prints the real serialized request body. The feed preview resolves the same payload the sync sends, with its columns generated from your mapping rather than from a fixed list. The API log grid records every call, with full request and response bodies when debug logging is on. You are never asked to believe a summary.

The untranslatable is stated, not smoothed over. Of the 67 Google attributes on offer, 57 map straight through. Six are Google's multi-field messages – shipping, product detail, loyalty program, installment, subscription cost, certification – and take a colon-delimited value in Google's own text-feed spelling. Three have no field in Merchant API v1 at all and are written to the feed file only, and the extension says so rather than pretending to send them. When a value cannot be read as the type Google declares, it is skipped with a log line naming the attribute and the shape expected – never guessed at, and never allowed to abort the rest of the batch.

There is also the question worth asking any feed vendor right now, ours included. Google shut down Merchant API v1beta on 2026-02-28 and retired Content API v2.1 for Shopping on 2026-08-18. This extension addresses Merchant API v1 and never implemented Content API v2.1; Scheduled Fetch is unaffected by either date by construction. Ask your current vendor which surface their extension speaks today, and take the answer in writing.

What it does not try to be

It is not an ads tool, not a multi-channel feed builder, and not a service that holds your catalogue. It is a deterministic, on-premise integration that reads your catalogue and talks to Google. The full list of what is deliberately absent is in the FAQ on the extension's page.