Magento 2 and Adobe Commerce do not generate a Google-ready product feed natively. You build the feed with a feed extension or a custom export, map every required attribute Google expects, and make sure the price and availability in the feed match both the product page and its structured data. Most disapprovals trace to one of three things: missing required attributes, a price mismatch between feed and page, or broken microdata that Google reads during Automatic Item Updates.
If your Shopping ads are underperforming or products keep getting disapproved, the problem is almost never Google being difficult. It is a feed that does not match your store, or a storefront that does not emit the structured data Google cross-checks against. This guide covers how to build the feed correctly on Magento, the extra wrinkle Hyva introduces, and a fix-by-error playbook for the disapprovals merchants actually see.
Why Magento needs help to feed Google
Google Merchant Center wants a structured product feed: a file, or an API push, that lists every product with a specific set of attributes in Google’s exact vocabulary. Magento stores that data, but it does not export it in Google’s format out of the box. That gap is why every serious Magento store runs a feed extension or a custom feed export.
The common feed extensions each do the same core job: generate and auto-update a feed for Merchant Center. Options include Magefan, MageDelight, Mageplaza, Amasty, Mirasvit, and Wyomind. They differ in attribute-mapping flexibility, update frequency, and how they handle configurable and bundle products, which is where cheap extensions tend to fall down.
The attributes that matter, and the ones that get missed
Google requires a baseline set of attributes and strongly recommends several more. Getting these right at the feed level prevents most disapprovals.
| Attribute | Required | Common Magento pitfall |
|---|---|---|
| id | Yes | Must be stable; do not reuse across products |
| title | Yes | Keep under 150 characters, front-load key terms |
| description | Yes | Strip HTML, avoid promotional text |
| link | Yes | Must be the canonical, indexable product URL |
| image_link | Yes | Use a high-resolution main image, not a placeholder |
| price | Yes | Must match the page and the structured data exactly |
| availability | Yes | Must reflect real stock, in sync with the page |
| gtin or mpn | Conditional | Missing GTINs cause disapprovals for branded goods |
| brand | Conditional | Often empty on Magento default attribute sets |
| condition | Recommended | Default to “new” unless you sell used goods |
The three that quietly break feeds are the identifier attributes (GTIN, MPN, brand), the availability sync, and the price consistency across feed, page, and microdata. A feed can be perfectly formatted and still get products disapproved if the price Google reads on the page does not match the price in the feed.
The Hyva wrinkle: microdata and Automatic Item Updates
Here is the part that catches merchants on modern storefronts. Google does not just trust your feed. Its Automatic Item Updates feature crawls your product pages and reads the structured data on them to verify price and availability. If the structured data is missing or wrong, Google flags a microdata mismatch and can disapprove the product even when the feed itself is fine.
Magento 2 emits inline microdata by default, but that markup frequently misses the fields Google’s merchant listings want, in particular offers.availability, priceValidUntil, and aggregateRating. Worse, a migration to a Hyva theme can break the default microdata entirely, because Hyva rebuilds the product template and the inherited microdata does not always come along.
The reliable fix is to stop depending on scattered inline microdata and emit clean, complete JSON-LD structured data on every product page instead. JSON-LD is easier to validate, easier to keep in sync with the feed, and less fragile across theme changes. We covered the full approach in structured data on Magento and Hyva, and it is the single most effective thing you can do to stop microdata-driven disapprovals.
A fix-by-error playbook
Merchant Center errors are categorised by severity: red errors that disapprove products, yellow warnings that hurt ad performance, and blue notifications that suggest optimisations. Here is how to handle the ones Magento merchants hit most.
- “Missing value: GTIN” or identifier errors. Populate GTIN, MPN, and brand attributes in Magento and map them in the feed. For products without a real GTIN, set the identifier_exists attribute correctly rather than inventing numbers.
- “Mismatched value: price.” The feed price does not match the price Google read on the page. Check for tax display differences, customer-group pricing, and stale feed caching. Align all three: feed, page, and JSON-LD.
- “Insufficient match of microdata availability information.” Google could not confirm availability from your page’s structured data. Emit availability in JSON-LD that matches the page and the feed, and confirm it renders on the live Hyva template.
- “Image issues.” The main image is missing, too small, or a placeholder. Feed the real product image URL, not a swatch or a lazy-loading placeholder that returns a blank.
- “Landing page not accessible.” The link attribute points to a URL that redirects, 404s, or is blocked by robots. Feed the canonical product URL and verify it resolves.
Work errors first, then warnings, then notifications. Disapprovals cost you impressions immediately; optimisations can wait a week.
Building the feed the right way on Magento
A durable feed setup follows a clear order:
- Complete your attribute data. Fill GTIN, MPN, brand, and Google product category in Magento before touching the feed. Garbage in, disapprovals out.
- Choose feed granularity. Decide how configurable products map to feed items. Most merchants feed child variants with item_group_id so size and color show correctly.
- Generate and schedule the feed. Use a feed extension to auto-update on a schedule that matches your price and stock changes. Hourly for volatile catalogs, daily for stable ones.
- Align structured data. Emit JSON-LD on product pages with the same price and availability the feed carries.
- Validate before submitting. Run the feed through Merchant Center’s diagnostics and Google’s Rich Results Test on a sample of product pages.
- Monitor weekly. Check the diagnostics tab for new disapprovals, especially after catalog or theme changes.
This is standard Magento development hygiene: the feed, the page, and the structured data are three views of the same product data, and they must agree.
Configurable products and variants: where feeds break
Magento’s configurable products are the most common source of feed confusion. A configurable product is a parent with child simple products for each size or color. Google wants to see the buyable variants, grouped so it understands they are one product family.
The correct pattern is to feed the child variants as individual items and tie them together with the item_group_id attribute set to the parent. Each variant carries its own size, color, GTIN, and image, while item_group_id tells Google they belong to one product. Feeding only the parent hides your real inventory; feeding children without item_group_id makes Google treat every size as a separate product and can trigger duplicate-content warnings.
Bundle and grouped products need their own decisions. Usually you feed the components that are actually purchasable and set pricing to match what the shopper pays. Test these edge cases specifically, because a feed extension that handles simple products cleanly can still mishandle bundles.
An identifier strategy that survives audits
GTIN, MPN, and brand are the attributes that decide whether Google trusts your listings. For manufactured goods with real barcodes, populate the GTIN and never guess. For products that genuinely have no GTIN, such as custom or handmade goods, set identifier_exists to false rather than leaving the field blank or inventing a number. Inventing GTINs is worse than omitting them, because a wrong GTIN can get an entire account flagged.
Brand should map to a real Magento attribute, not a hardcoded store name, so multi-brand catalogs feed correctly. Keeping these identifiers clean at the source pays off every time Google tightens its matching rules, which it does regularly.
Feed extension versus custom export
Most merchants should use a feed extension. It is faster to deploy, handles Google’s changing spec, and covers scheduling and diagnostics. A custom export makes sense only when you have unusual catalog logic, feed many channels beyond Google, or need transformation rules an off-the-shelf extension cannot express. For a single Google Shopping feed on a standard catalog, an extension is the pragmatic choice, and the engineering time is better spent on the structured-data alignment that actually prevents disapprovals.
Frequently asked questions
Does Magento generate a Google Shopping feed automatically?
No. Magento 2 and Adobe Commerce store product data but do not export a Google-ready feed on their own. You need a feed extension or a custom export that maps your attributes to Google’s required format and updates on a schedule.
Why do my products get disapproved when the feed looks correct?
Usually because Google’s Automatic Item Updates crawled your product page and found price or availability in the structured data that does not match the feed. Align the feed, the page, and the JSON-LD so all three agree.
Does a Hyva migration affect my Google feed?
It can. Hyva rebuilds the product template, and the default Magento microdata can break in the process. Emit clean JSON-LD on the Hyva product template and validate it, or Google may lose the structured data it uses to verify your items.
What is the difference between microdata and JSON-LD for Merchant Center?
Both are structured-data formats Google can read. Microdata is inline in the HTML and fragile across theme changes. JSON-LD is a separate script block that is easier to validate and keep in sync. For Magento and Hyva, JSON-LD is the more reliable choice.
How often should I update my product feed?
Match the update frequency to how often your prices and stock change. High-velocity catalogs benefit from hourly updates; stable catalogs are fine with daily. A stale feed is a common cause of price-mismatch disapprovals.
Where this fits
A clean Google feed on Magento is three things kept in agreement: complete attribute data in the feed, a resolving canonical product page, and structured data that matches both. Hyva adds one requirement, that you emit reliable JSON-LD because the default microdata can break. Get those aligned and disapprovals largely disappear.
Bemeir is a Brooklyn ecommerce agency and the first US-based Hyva partner, with a deep technology partner ecosystem spanning feeds, SEO, and merchandising tools. We build Magento and Hyva storefronts that emit correct structured data, and we also work across Shopify, Shopware, and BigCommerce. Read more about Bemeir and how we approach catalog and feed quality.
External references: an open-source Magento Google Shopping feed extension, a detailed guide to Google Shopping feed optimisation in Magento, and a practical Magento Google Shopping feed setup walkthrough.
