Google Merchant Feed
/
A merchant selling on Google Shopping has to get the whole catalogue into Google Merchant Center, keep it current as prices, stock and images move, and repeat that for every store view that sells in a different country or language. Done by hand it is a weekly spreadsheet export, a round of fixing the columns Google rejects, and a feed that is always a day behind the shop. Google Merchant Feed does it from inside Adobe Commerce and Magento Open Source, on your own server, with no spreadsheet in the loop.
You choose how the data reaches Google, per store view. Scheduled Fetch writes a static feed file and publishes it at a URL that Google pulls on its own schedule: no service account, no OAuth, no API quota, and optional HTTP Basic authentication on the download URL if you would rather the feed were not public. Merchant API push sends each product to Google over Merchant API v1, driven by a sync queue and Magento cron, with per-store credentials so one store view can push to a production Merchant Center account while another sits in sandbox.
The API surface matters more than it usually would. Google shut down Merchant API v1beta on 2026-02-28 and retired the Content API v2.1 for Shopping on 2026-08-18; extensions still built on either of them stopped working on those dates. This extension addresses Merchant API v1 only. Scheduled Fetch is unaffected by any of it, because Google fetches a file over plain HTTP.
Attribute mapping is a grid, not a fixed schema. 67 Google Merchant attributes
are on offer, each mapped to a Magento product attribute or to a fixed value.
57 of them map straight through to the Merchant API. Six more are Google's
multi-field messages – shipping, product detail, loyalty program, installment,
subscription cost and certification – and take a colon-delimited value in
Google's own text-feed spelling, for example US:CA:Ground:9.99 USD. Three
(tax, tax category, ships-from country) have no field in Merchant API v1 at all
and are written to the feed file only, which is stated rather than half-sent. A
value that cannot be read as the type Google declares is skipped with a log
line naming the attribute and the shape that was expected: never guessed at,
and never allowed to abort the rest of the batch.
The admin gives you a dashboard with per-status counters, a products grid where any product can be excluded from the feed individually or by mass action, a feed preview that resolves the same payload the sync sends, and an API log grid recording every call. Feed files export as XML (RSS 2.0), JSON or tab-separated CSV. Sandbox mode exercises the whole pipeline – queue, cron, mass actions, CLI – without calling Google at all.
For anyone who runs deployments from a terminal there are two commands.
bin/magento gm:sync --dry-run prints the exact JSON body each product would
be sent as, which is the thing you need in front of you when Google rejects a
product and you want to know why. bin/magento gm:export writes the feed to
stdout, to a file, or straight to the Scheduled Fetch path under pub/media/.
Google Merchant Feed is a deterministic, on-premise integration. Values come out of your catalogue through a mapping you configure; nothing is inferred and nothing is generated. The only outbound connection it ever opens is to Google's own Merchant API, and only when a store view is set to API delivery. Merchant account, feed label, credentials, delivery mode and file path are all scoped per store view.
Key Features
- Two delivery modes, chosen per store view: Scheduled Fetch (Google pulls a static feed file over HTTP, optional HTTP Basic auth, no API credentials at all) and Merchant API push (queue plus cron, per-store service account)
- Merchant API v1, the current Google surface – v1beta was shut down on 2026-02-28 and Content API v2.1 was retired on 2026-08-18
- Attribute mapping grid: 67 Google attributes to Magento attributes or fixed values; 57 map straight through to the API, six multi-field messages (shipping, product detail, loyalty program, installment, subscription cost, certification) take a colon-delimited value, three (tax, tax category, ships-from country) are feed-file only because Merchant API v1 has no field for them
- Unreadable values are skipped with a log line naming the attribute and the shape expected, never guessed at and never aborting the batch
- Admin dashboard with per-status counters and Scheduled Fetch URLs
- Products grid with per-product feed exclusion and Include / Exclude mass actions
- Feed Preview resolving the same payload the sync sends
- API log grid recording every call, with full request and response bodies when debug logging is on
- Feed export in XML (RSS 2.0), JSON, and tab-separated CSV
- Sandbox mode: exercises queue, cron, mass actions and CLI without calling Google
- `gm:sync` with `--sku`, `--dry-run` and `--limit`; the dry run prints the exact JSON body Google would receive
- `gm:export` with `--format`, `--sku`, `--store`, `--output` and `--to-media`
- Cron: full sync on a configurable frequency, incremental every ten minutes, both gated by Enable plus Auto-sync
- Per store view: merchant account, feed label, credentials, delivery mode, feed file path and format
Versions
The release that made Test Connection tell the truth. Five defects fixed and one addition, all on the admin configuration pane.
- Fixed: the probe tests the scope the page governs. Credentials are per store view, so a store-scoped page was reporting on the default store's.
- Fixed: Sandbox Mode no longer reports a connection that never happened. The outcome carries a third state, skipped, in its own colour.
- Fixed: SDK Transport is probed as selected, not as last saved. The credentials are still read only from saved configuration.
- Fixed: website scope probes instead of refusing, and the outcome names the store view it ran through. A website with no default store view refuses explicitly rather than falling back.
- Fixed: Default Config says which store view it actually tested, instead of implying it covered every store.
- Added: the configuration pane names the extension and its version, derived at runtime – the string to quote in a support request.
FAQ
Selling on Google Shopping means getting your whole catalogue into Google Merchant Center and keeping it current as prices, stock and images move – and doing that again for every store view that sells in a different country or language. Done by hand it is a weekly spreadsheet export, a round of fixing the columns Google rejects, and a feed that is always a day behind the shop.
Google Merchant Feed does that from inside Adobe Commerce and Magento Open Source, on your own server. You choose per store view how the data reaches Google: a static feed file that Google downloads on its own schedule, or a push over Merchant API v1 driven by a queue and Magento cron. Nothing is inferred and nothing is generated – values come out of your catalogue through a mapping you configure.
- You sell on Google Shopping and your catalogue changes often. Prices, stock and images that move daily are exactly what a manual export handles badly and a queue on cron handles well.
- You run more than one store view. Merchant account, data source, feed label, delivery mode, feed path and format are all per store view, so one Magento installation can serve a production Merchant Center account for one country and a separate one for another.
- You want the feed on your own infrastructure. No middleware, no external service holding your catalogue, no subscription. The only outbound connection the extension ever opens is to Google's own API, and only when a store view is set to API delivery.
- You are cautious about Google's API deadlines. Merchant API v1beta was shut down on 2026-02-28 and Content API v2.1 for Shopping was retired on 2026-08-18. This extension addresses Merchant API v1, and its Scheduled Fetch mode is unaffected by any API deadline because Google simply downloads a file over HTTP.
- You need feeds for channels other than Google. Amazon, Meta, Bing or a comparison-shopping aggregator are outside its scope; a general multi-channel feed extension fits that need better.
- You need Google promotions feeds or local inventory feeds today. Neither is supported – see the last question.
- You want someone to run your ads. This produces and maintains the product data. Campaigns, bidding and budgets live in Google Ads and stay there.
- You cannot have a Google Merchant Center account. The account is free, but it is a prerequisite; and for API delivery specifically, whoever owns your Google Cloud project must register it as a developer once, outside Magento.
- Your current feed tool works and you have no API-surface concern. Switching a working integration is a cost. The question worth asking your current vendor first is which Google API their extension speaks today.
Two delivery modes, chosen per store view. Scheduled Fetch writes a static
feed file under pub/media/ and publishes it at a URL Google pulls on its own
schedule – no service account, no OAuth, no API quota, and optional HTTP Basic
authentication if you would rather the feed were not public. Merchant API
push sends each product over Merchant API v1, driven by a sync queue and
Magento cron, with per-store credentials.
Attribute mapping is a grid, not a fixed schema: 67 Google Merchant attributes,
each mapped to a Magento product attribute or to a fixed value. 57 map straight
through to the API. Six are Google's multi-field messages – shipping, product
detail, loyalty program, installment, subscription cost and certification – and
take a colon-delimited value in Google's own text-feed spelling, for example
US:CA:Ground:9.99 USD. Three (tax, tax category, ships-from country) have no
field in Merchant API v1 at all and are written to the feed file only, which is
stated rather than half-sent.
In the admin: a dashboard with per-status counters and the public feed URLs, a products grid where any product can be excluded from the feed individually or by mass action, a feed preview that resolves the same payload the sync sends, and an API log grid recording every call. Feed files export as XML (RSS 2.0), JSON or tab-separated CSV.
From a terminal: bin/magento gm:sync --dry-run prints the exact JSON body each
product would be sent as, and bin/magento gm:export writes the feed to stdout,
to a file, or straight to the Scheduled Fetch path. Sandbox mode exercises the
whole pipeline – queue, cron, mass actions, CLI – without calling Google at all.
A value that cannot be read as the type Google declares is skipped with a log line naming the attribute and the shape that was expected. It is never guessed at, and it never aborts the rest of the batch.
- No promotions feed and no local inventory feed. Some competing extensions ship both. This one sends the primary product feed.
- No supplemental feeds, and no channels other than Google. It is not a multi-channel feed builder.
- No Google Ads management. No campaigns, no bids, no budgets, no reporting from the ads side.
- No order integration. Nothing comes back from Google into Magento; orders are placed on your storefront.
- No FTP or SFTP upload to Merchant Center. Delivery is the API push or the HTTP URL Google fetches.
- No Content API v2.1 and no Merchant API v1beta. Both are retired by Google and neither is implemented, by design.
- No Google Cloud developer registration. That one-time
registerGcpcall belongs to whoever owns the Cloud project and is made outside Magento; the User Guide documents it in §2.3. - No identifier invention. GTINs, MPNs and brands are read from your catalogue or set as fixed values. Nothing is generated, and no product text is rewritten – there is no AI or ML anywhere in the extension.