Magento 2 Google Shopping Feed

View Demo

Create a feed file with the Google Shopping extension for Magento and get more orders while increasing your revenue.

The Google Shopping is a go-to sales channel for online stores to increase their revenue and customer base. Roughly 1 billion shopping sessions a day are conducted on this platform, according to Google.

Sell directly from the Google Search engine by placing your products on its dedicated Google Shopping tab. Get new audience by advertising your products in Google Ads on hundreds of websites.

  • Generate a fully compliant Magento 2 Google Shopping feed
  • Keep your feed always up to date with an automatic update option
  • Filter out products to be excluded from the Google Shopping schema
  • Easily configure what product attributes to include in the feed
  • See your feed success with its clicks, orders, and revenue statistics
  • Start with a Google-ready preset, copy it for related campaigns, or build a feed from scratch
  • Run pre-flight checks before upload to Google Merchant Center

ℹ️ Important: This sub-module is included in the Advanced Product Feeds extension.

Buying this item gives you access to all feeds including Facebook, Instagram, Google Shopping, and others in one powerful package.

Magento Cloud
Compatible with:
Community:
2.3.* - 2.4.9
Enterprise:
2.3.* - 2.4.9

Business Value

Google Shopping is a proven sales channel to get you more orders. Roughly 46% of product searches begin on Google, and Google Shopping accounts for 36% of product discovery searches. Almost 35% of Google shoppers make a purchase within 5 days of searching for a product.

  • Problem: Presenting your product catalog on Google’s comparison shopping engine means you need to format data on your products within Google’s XML feed specification and taxonomy. Google also expects this info to be automatically updated.
  • Solution: Magento Google Shopping extension easily makes a product feed that is fully compliant with Google’s specification and automatically updates the feed. It tracks the feed business success and serves best for your business goals.

How Google Shopping feed drives your sales

Using the Google Shopping Magento extension to sell your products directly on Google, you can expect rapid sales growth. Here are three main reasons for this:

Match with shopper's interests

Products on Google Shopping automatically match relevant keywords and search queries. Shoppers will see items they are potentially interested in buying.

Reach wider audience

Google is the most popular search engine, serving millions of search queries per day. By selling on Google, you can reach a wider audience in a short time period.

One feed for multiple platforms

A Google Shopping feed can be used for selling on other sales channels. Facebook, Microsoft Bing, and dozens of other sales engines accept this feed.

Fully compliant with Google feed specification

Google Shopping extension generates a product feed that can pass the check by Google Shopping from the start. The shopping feed Google expects may have such information on products:

  • Basic product data
  • Price and availability
  • Product category
  • Product identifiers
  • Detailed product description
  • Shopping campaigns and other configurations
  • Destinations
  • Shipping
  • Tax

Some of the product info, like price and availability or product category, is mandatory. The corresponding attributes are included in the default feed template when you create it in the Magento Google shopping feed module.

To stand out your products from competitors, let your potential shoppers to fully see your products. For that purpose, include optional product data, such as additional images, expiration date, or mobile-optimized landing page. Google shopping extensions' capabilities allow you to present goods in the best way possible.

Two steps to get a feed

To speed setup, the builder opens on a start screen with popular destinations, an A–Z index for quick filtering, and instant search to help you pick the right preset.

Using a prebuilt template for Google Shopping, you can get the feed literally in a minute. Make a product feed in two steps:

  • Provide a feed file name
  • Click the Generate button

Then, simply copy and paste the feed file URL into your Google Merchant account. Alternatively, configure the FTP/SFTP feed file upload to Google if it suits you better.

However, typically, the Google Shopping product feed requires more than two steps as you may want to make it more personal. To stand out from competitors, you can edit the default feed template to change its output. For example, customize the template to add more product information and apply product filters to filter out irrelevant items.

For similar destinations, you can duplicate a preset, and both presets and feeds support helper metadata (logo, guide link, short note) for clearer organization.

Additionally, configure e-mail notifications regarding the feed status and reporting on the user statistics. Attach your UTM tags to track your feed access in Google Analytics.

Product Attributes

Configure your Magento Google product feed easily in a visual manner, no experience of working with XML required.

Simply click the Library of patterns and find a product attribute you want to include in your feed. Use the Preview function to get a view on the output the pattern delivers. Then copy the pattern and paste it in your feed template.

Magento Google product feed

Product Filters

Make your Google Shopping feed more effective by filling it with products that meet your business interests best.

For example, Google requires to exclude out of stock products otherwise it will disapprove the product. Additionally, you may want to promote only products of a specific price range.

Apply the Base Product Filter or Extended Filter or both to your product feed to filter out irrelevant products from your feedt.

Magento Google product feed

Feed Preview

Magento Google product feed

Make sure you get a perfect XML feed before it is uploaded to Google. Use the preview option to correct any misconfiguration that may occur when editing the feed default template.

You will see the output exactly as it will be received by Google Shopping. Check for possibly deleted mandatory attributes, tags have opening and closing elements, etc.

Having such a preview tool helps to save time by avoiding a rejection when the feed is uploaded to Google.

Feed Validation

Catch issues before export and avoid rejections. Validate any feed against your own rules and get a clear report before upload.

Set checks in Content Settings > Validation Rule, generate the feed, and run validation. If a rule is present, it can run automatically; you can also start it manually at any time.

Typical checks include title length, required fields, character encoding, price and currency formats, and dimensions, etc. Reports show line numbers and plain-language messages, so you can fix values, regenerate, and validate again.

Magento Google product feed

How to sell on Google Shopping with a product feed

To start selling on Google Shopping, Google Ads, and other Google services, the first thing you need to do is to create a product feed file. This file contains all information on your products you want to sell via Google services.

Next, create a Google Merchant account and configure the access to the feed file. You may set up Google Merchant to fetch your feed by the URL or FTP/SFTP.

The last step is to finish the setup of your Merchant account by providing such business info as shipping, taxes, branding, returns.

Finally, you can publish your product listings to start selling on Google.

Magento Google product feed
No hidden fees
Lifetime access to source code
Access to free support and updates for 1 year
Updates and support prolongation - $108

Pay today $179 for the first year.

Then $108 for updates and support services per year.

Cancel anytime.

30 days money back guarantee
See it in action!
Pick a quick tutorial to learn about various aspects of this extension
Customer Reviews 0
Earn points for your review about this extension modules. $1 = 10 points
Write Your Own Review

check-circle You submitted your review for moderation.

Manual & Support
Need more help?

Save time by starting your support request online and we'll connect you to an expert.

Changelog
Version 1.15.8Sep 7, 2026
An empty feed now tells you it is empty. A generation that matched no products used to finish with a green Feed file was generated., a blank or negative Products in feed count and a stray Valid 0 — with an empty file and no hint as to why. Such a run now ends with a warning that names the usual causes (the product filter matched nothing, the chosen store view has no products assigned, the catalog indexes are invalid) and links the troubleshooting guide, and the count always reads as a real number, including a genuine 0. ([#757]())
Category filters now select the products they describe. With Enable fast mode filtering on — the default on every feed — four of the Category operators compared the single category id stored per product against the whole comma-separated list you picked, so Category is 5, 7, 12 produced an empty feed and Category is not 5, 7, 12 exported the entire catalog. Does not contain was wrong in a second way: it matched the ids as text, so excluding categories 3 and 4 also quietly excluded 13, 23, 30, 34 and every other id containing those digits. Is, is not, contains and does not contain now all ask the indexed category-membership question — a positive operator means "in one of these categories", a negative one "in none of them" — in both filtering modes, so saved rules match correctly and both modes agree. Is one of / is not one of are unchanged. ([#756]())
A filter that combines conditions with ANY no longer empties the feed in fast mode. Fast mode narrows the catalog with a database query before checking each product, and a condition that has no database equivalent — Quantity, Is Salable, the image fields, a PHP condition and a dozen more — was simply left out of that query. Inside an ANY group that made the query stricter than the rule: measured on a 2,046-product store, Quantity is greater than or equal to 0 OR SKU is NO-SUCH-SKU kept all 2,046 products with fast mode off and exported none with it on, with nothing in the log to explain it. An ANY group is now used to narrow the catalog only when every condition in it can be expressed as a query; otherwise the feed checks the full candidate set — slower on such a rule than before, and correct, where before it was fast and wrong. Rules that are a plain ALL list of ordinary attributes, the common case, keep exactly the speed they had, and stock filters keep selecting the same products as always.
Final Price filtering in fast mode is exact again. 1.15.7 started reading Final Price from Magento's price index to narrow the catalog, and that is not the same number the filter itself computes: on stock sample data 26 of 147 configurable products disagreed, and because the narrowing runs first, a product the rule keeps was never even looked at — Final Price is greater than or equal to 25 silently left out a product priced at 28.00. The index also holds enabled products only, and under a per-website or per-customer-group price index it can be empty altogether, which would have emptied every Final-Price feed. Final Price is now decided by the same per-product calculation the slower mode uses, in both modes, for simple, configurable, bundle and grouped products alike. ([#764]() follow-up)
Filters left with an empty value now match exactly what they match with fast mode off. 1.15.7 gave three of them a fast-mode condition, and two of those did not agree with the slower mode: is not one of with nothing selected kept every product that has a value for the attribute, where the filter in fact matches no product at all — on the sample catalog that was 47 of the 81 products the admin preview offered for a rule that selects nothing — and is one of with nothing selected built no condition, so fast mode let the whole catalog through. Both now select nothing, as they do with fast mode off. Is not with an empty value — the "is not empty" filter — keeps its meaning and no longer drops a product whose value is 0. ([#772]() follow-up)
forloop.first and forloop.last work in feed templates. Both were computed from the product's internal id rather than its position in the loop, so {% if forloop.first %} never once matched and forloop.last fired on whatever product happened to carry the matching id — the documented way to write a feed-level value into a header produced nothing. Both flags, and forloop.notlast, now follow the loop's own position. ([#746]())
A value captured out of the product loop now reaches the header and footer. The documented pattern — {% capture %} around {% for p in context.products %} — came out blank: the end of the product loop stopped the rest of the document for that pass, so the field that reads the captured value was never rendered, and on the next pass the exhausted loop overwrote the value with an empty string. The captured value is now kept and carried between the passes of a chunked export, so a footer rendered only in the final pass still sees it, while a capture inside a {% for %} still recalculates per row. A capture interrupted part-way — by the export's time limit or by Stop — no longer publishes the half-built value it had accumulated, in a header, in an {% if %}/{% else %} branch or inside another capture: the field stays empty for the rest of that export rather than shipping a plausible-looking but truncated value. Very large captured values (over 64 KB) still reach the feed file in the pass that produced them, they are just not carried across passes. An export already in progress keeps running across the update.
The exported product count no longer goes blank on a store view that is not in English. The export runs in the store view's language and the count was looked up by the export step's translated label, so on a Spanish or Romanian store view — 42 of the 45 shipped locales translate the word — the Count column in the Feeds grid, the status bar and the generation panel all showed nothing, and a spurious Valid 0 appeared beside a green success. Verified on a store view in Spanish: a 346-product feed now reports 346. The lookup also keeps working when another extension plugs into one of the export steps. ([#757]())
Version 1.15.7Sep 3, 2026
A filter on Final Price is no longer ignored. With Enable fast mode filtering on — which it is by default on every feed — a condition such as Final Price is greater than 50 was silently dropped: the rule matched the whole catalog, so the feed shipped every product instead of the selection you asked for, while the same rule with fast mode switched off filtered correctly. Final Price is now taken from Magento's price index for the feed's store and website, and bundle, configurable and grouped products are compared against the same price the slower mode uses, so both modes now produce the same feed. ([#764]())
Filters left with an empty value now do what they say in fast mode. Three operators built no usable condition when their value was blank, so instead of filtering they let every product through: is not with the value left empty — the "is not empty" filter — kept products that have a value and products that have none, the exact opposite of what it asks for; is not one of with nothing selected did the same; and does not contain with an empty value, which excludes every product, excluded none. All three now give the same result as they do with Enable fast mode filtering turned off. ([#772]())
Version 1.15.6Sep 2, 2026
See at a glance which feeds are switched on — the Feeds grid has a new Enabled column with a Yes/No filter beside it, so the list can be narrowed to just the feeds that are active or just the ones that are turned off. (pm[#1147]())
⚠️ Feed generation can no longer be started from the storefront. The public address mst_feed/export/execute ran a complete export for anyone who knew it — no admin login and no permission check — and it could also be used to reset the progress of an export that was already running, or to have arbitrary code echoed back to a visitor's browser. That address, and the two controllers behind it (Mirasvit\Feed\Controller\Export and Mirasvit\Feed\Controller\Export\Execute), are gone; it now answers with a 404. Generation runs only through the admin — the Generate button, the feed's own schedule, or bin/magento mirasvit:feed:export on the command line — and every one of those enforces the admin session and the Feeds permission. If anything on your side fetched the old storefront address to trigger a feed (a monitoring check, an external scheduler, a cron entry calling wget/curl), switch it to the command line. (pm[#1119]())
⚠️ The long-dead type column is removed from the mst_feed_rule table by setup:upgrade. Nothing in the extension has written to it since 2022; on stores installed after that it never existed, so the upgrade is a no-op there.
⚠️ Three unused classes are removed: Export\Liquid\BlankFileSystem, Model\Config\Source\ArchiveSource, and Model\Feed\Copier, which had been marked deprecated — use Mirasvit\Feed\Api\FeedRepositoryInterface::duplicate(), which the web API already exposes directly.
⚠️ Two admin pages that nothing in the extension ever opened are removed: the feed history grid (Controller\Adminhtml\Feed\HistoryGrid), which had been failing with a server error on every request since the block behind it was deleted in 2023, and the "new custom feed" action (Controller\Adminhtml\Feed\NewCustom), which no button or menu item ever pointed at. Nothing you use in the admin changes; both addresses now simply answer with a 404 instead of a broken page.
The extension runs on PHP 7.1 and 7.2 again. A number of places had picked up functions and syntax that only exist in newer PHP — FTP and SFTP delivery, product URL resolution, feed and template logo uploads, XML feed validation, the AI column filler, template export, the file-cleanup task and the HTML-content admin fields — each of which failed outright with a fatal error on an older store. They work on every supported PHP version now.
Feed generation finishes again on stores that keep media on remote storage (Amazon S3 and compatible). The export writes a small progress file after roughly every product, and that file was being uploaded to the bucket each time — several seconds per product, so a generation started from the admin or by cron on a large catalog never realistically completed, while the same feed run from the command line finished in minutes. The progress file is now kept on the local disk (var/mst_feed/tmp) alongside the export's own scratch file, so admin and cron generation runs at full speed. (pm[#1153]())
A feed built from the bundled ChatGPT template is now accepted by OpenAI. Nine of its columns did not match what OpenAI's Commerce ingestion expects, so products came through without the flags that make them searchable and buyable, and OpenAI reported the feed as incomplete.
Feed screens no longer answer with "Something went wrong" after an update. A progress file left behind by an older version — or one that had been truncated or garbled — could not be read back, and every admin action that touched it (opening a feed, generating, resetting) failed with that message and no way out other than deleting the file by hand. An unreadable or outdated progress file is now treated as "no progress recorded" and generation simply starts from the beginning. (pm[#1149]())
The scheduled clean-up of old feed files no longer deletes files it should keep. On a store with no feeds configured it removed every feed file in pub/media/feed/ — which, where several environments share one remote storage bucket (S3 / MinIO), meant a staging or beta store with no feeds wiping production's feed files. With no feeds there is now nothing to clean up and nothing is removed; where feeds do exist, orphaned files are still tidied away as before.
Filters using is not one of or does not contain no longer drop products whose attribute has never been set. A rule such as Color does not contain "red" silently left out every product with an empty Color, even though the rule says nothing about requiring a value; those products are now exported, as the rule intends. This completes the same correction made for does not equal in 1.15.5. ([#743]())
A filter that lists several values no longer ignores the value 0. Where the option you picked is stored as 0Out of Stock in Quantity and Stock Status, the NOT LOGGED IN customer group, the default store scope, or any attribute option that happens to carry id 0 — that entry was thrown away while the list was being read, so the rule matched nothing and the feed came out empty or short. All selected values are now kept.
Creating or saving a product filter no longer fails on stores upgraded from an older version. The attempt ended with the database error Column 'type' cannot be null, and the filter was not saved; stores installed more recently were never affected. Run setup:upgrade after updating and filters save normally again. (pm[#1068]())
The Google Merchant Center setup guide link, shown in the error message when an upload fails because your Google Cloud project is not registered with your Merchant Center account, pointed at a manual page that no longer exists and returned a "page not found". It now opens the current page.
Version 1.15.5Aug 27, 2026
A filter that fails on one product's value no longer stops the whole export. Whatever the reason — a value of an unexpected type, a division that cannot be done — that single value is now exported unfiltered, the product still ships, and the rest of the feed is unaffected. Each dropped filter is written to var/log/mirasvit/feed.log with the filter's name and the reason, so a filter that is failing on every row can be found instead of quietly producing a wrong feed.
A feed configured with an export step that is not a real step now fails immediately with a message naming it, instead of running part-way through generation and stopping with an unrelated error.
A does not equal filter no longer drops products whose attribute has never been set. A rule such as Meta Title is not "EXCLUDE-ME" kept only products that had some other value in that field and silently left out every product where the field was empty, even though the rule says nothing about requiring a value. Such products are now exported, alongside the ones with a different value. (pm[#1159]())
Feeds on a store with several store views no longer export each other's products. The intermediate list of products matching a Filter is cached while a feed generates, and that cache ignored which store view it had been built for: generating the same filter for a second store view wiped and replaced the first one's list, so a feed could pick up products that belong to another store view, and two feeds generating at the same time could corrupt each other's results. Each store view now keeps its own cached list, and clearing one leaves the others intact. (pm[#934]())
A template calculation that cannot be carried out on some products no longer kills the entire feed. With {{ price | divided_by: pack_qty }} in a column, a single product whose pack_qty is empty or not a number aborted generation outright and produced no file at all. Dividing by an empty or zero value now leaves the value as it was, and a modulo by such a value returns 0, so the export finishes.
The secure, unsecure and media-URL filters no longer export the literal word Array when applied to a multi-value attribute — and no longer behave differently depending on whether the store runs in developer or production mode. Every value in the attribute now gets the URL rewrite and they are exported as a comma-separated list.
Version 1.15.4Aug 26, 2026
The filter preview opens straight away, whatever the size of your catalogPreview Products on a Filter used to load every matching product into memory and walk the whole catalog before it drew a single row, so on a 20,000-product store the first page took 12–19 seconds, and on catalogs of 90,000 and up it built a query several megabytes long and could run out of memory outright. The preview now works through the catalog in chunks and stops the moment the page you asked for is full: the same three rules measured 19.4s, 12.8s and 15.8s now come back in 0.3s, 0.03s and 0.03s. Memory no longer grows with the size of the catalog, only with the size of the page you are looking at.
Paging through a preview stays fast to the last page — turning to a deep page used to mean walking past every product before it, so on a rule matching 18,138 products page 1 took 0.4s and page 900 took 15.9s — and because the grid remembers the page you were on, one stray click deep into the pager left you waiting on every later visit too. Each page now remembers where the next one starts, so page 900 costs the same as page 2. A first jump far into the pager is still slow once, and every page up to it is instant afterwards.
The exact number of matching products, counted in the background — the count shown next to the grid is now an upper bound to begin with, so the rows appear immediately, and the precise figure is fetched behind the scenes and swapped in when it is ready. While it is being counted the number reads around 20000 (counting…) with a spinner beside it, so a figure that is about to change never looks like a settled one. The exact count is then reused for the rest of your visit — paging around the same rule shows it with no further waiting — and is recalculated only when you change a column filter, the keyword search or the page size, reload the page, or press Preview Products again, which is an explicit ask for a fresh answer. Both new labels are translated into all shipped locales.
The admin no longer freezes while a preview count is running. PHP holds an exclusive lock on your session for the duration of a request, so a count that takes minutes — a rule built from computed conditions such as Image 2–5, Is Salable or Final Price still does — used to queue every other admin request behind it, including turning the very page you were counting. Measured on the QA host, turning to page 2 during a count went from 201 seconds to 1.2 seconds. The count itself is no faster; it simply happens in the background instead of stopping you from working.
The filter preview no longer dies on a rule that uses an Image 2–5 or an MSI (Multi-Source Inventory) stock condition. Such a rule produced a server error and left the preview grid stuck on "loading" forever, with no message to explain it. Rules built from these conditions now preview normally.
A filter using an Any aggregator together with a condition that cannot be expressed in SQL — quantity, salable status, final price, an image — no longer previews an empty or too-short list. The preview quietly narrowed the candidate set on the SQL condition alone and hid products the real export includes; it now checks every product the same way the export does. (pm#263)
The preview no longer promises products your feed will not actually contain. For a handful of conditions — is_in_stock, is_in_stock_inventory, image, small_image, thumbnail — the shortcut the preview took asked a slightly different question than the export does, so a stale stock index was enough to make the two disagree (2046 previewed against 2045 exported). Those conditions are now always checked the way the export checks them, and the exported file itself is unchanged.
A filter that uses a custom attribute whose code begins with stock (for example stock_level) alongside a stock condition no longer fails with an "Unknown column" database error.
Jumping to the last page of a preview no longer reported a nonsense total — "18 records found" for a rule matching 18,138 — and no longer bounced the pager back to page one.
Returning to a preview page you had already looked at no longer put the rough upper bound back on screen next to a pager that still showed the exact number of pages.
A field value containing the feed's own column delimiter no longer shifts every following column on that row. In a format that uses no quoting — a TSV feed, most commonly — a tab inside a product's HTML description was read as an extra column separator; such characters are now replaced with a space. Quoted formats are unaffected. (pm[#416]())
An XML feed whose template contains an empty element — written as <g:brand/> or <g:brand></g:brand> — no longer fails to generate. Pressing Generate on such a feed stopped with the generic "a technical problem occurred" message and produced no file at all, on every feed that carried one. The empty element now reaches quality-control validation as an empty value, so a required-field rule reports it as missing, exactly as intended, and the export completes.
The feed edit page no longer writes PHP deprecation notices to the error log. On PHP 8 the Google Merchant Center notice shown on that page was rendered without an internal name, which other extensions that watch block rendering — Adobe Commerce price permissions among them — could not handle; every visit to the page added noise to the log. All feed admin blocks of this kind are now named, so the notices are gone.
Reasons to choose Mirasvit
Client focusing and satisfaction

These are our primary. A major portion of our new clients come from referrals from our existing clients. Our professional team of developers, marketers and support staff have invested the best knowledge and experience in the field into our work, so you know you can come back to us again and again.

Remarkable support

One year free and high quality support. We go to great lengths to provide maximum satisfaction with every module you have purchased in our store. By helping you with installation, configuration, answering your every question, we do all our best to eliminate any possible problems.

Risk-free Investment

30-days money back guarantee. If you are not satisfied with our extension performance for any reason, we provide a full refund.

Constant improvements and upgrades

We constantly add new features to all our modules, and are always interested in hearing your opinion and implementing your suggested features in our future developments.

Comprehensive Documentation

We provide an expanded user guide for every aspect of our extension, so you can find answers for all your burning questions.

Unencrypted source code of our products

You can customize extension according to your needs and requirements.

Usability and Performance

The Module is easy to install and upgrade, just follow our step-by-step user guide.

Ready for Magento Cloud

No core modifications. The extension has been tested in a Magento Cloud environment and is fully compatible with it.

Loading...