Search Console emailed you about merchant listing issues, or you opened the report and found a list of properties you have never typed. The useful first question is not “how do I add these?” but “which of these actually stop my products appearing?” Google answers that one directly, and the answer is that most of the list doesn’t.
Where the report lives, and what “invalid” means
The merchant listings report sits under Shopping in Search Console. Google says: For product snippets and merchant listings , reports can be found under Shopping .
(Google’s overview of the rich result reports).
The report counts items, not pages, and splits them in two:
-
A valid item is an item that doesn’t have any critical issues and can appear on Google as a rich result.
-
An invalid item has at least one critical issue preventing it from appearing as a rich result.
Underneath, two tables: “Why items are invalid”, which lists critical issues, and Improve item appearance: Shows non-critical issues affecting structured data on your site.
That second table is where most merchants panic unnecessarily. Google’s own guidance on it is explicit that fixing those is optional: Consider also fixing any non-critical issues that may be flagged in the tool, as they can help improve the quality of your structured data (however, this isn't necessary to be eligible for rich results).
(Google’s merchant listing documentation).
So: work the “Why items are invalid” table first. Treat “Improve item appearance” as a wish list.
Google does not publish a property-by-property list saying which issue is critical and which is not. In our experience the missing properties Google marks as required turn up as critical and the recommended ones as non-critical, but that is our observation, not Google’s rule.
What Google requires
Google’s merchant listing documentation names a small set of required properties, and a much longer set of recommended ones.
Required on Product:
name: the product’s name.image:The URL of a product photo.
Google adds that image URLsmust be crawlable and indexable
.offers: a nestedOffer.
Required on Offer:
price(orpriceSpecification.price), with one trap here:Unlike product snippets, merchant listing experiences require a price greater than zero.
A page showing “price on request”, a £0.00 placeholder, or a configurable product with no base price will not qualify.priceCurrency.
Recommended, among others: availability, hasMerchantReturnPolicy, shippingDetails, priceValidUntil, gtin or mpn, brand.name, category, sku, review and aggregateRating.
Two of the recommended ones are worth doing anyway, because they also feed Merchant Center, and Google suggests putting them in one place rather than on every product: where a return policy applies to most of your catalogue, Google recommends nesting the return policy markup under the Organization type, and the same approach applies to sitewide shipping. One block in your theme beats a block per product.
The four problems worth fixing first
1. A price of zero, or no price at all. See the rule above. This is the single most common reason a whole catalogue reads as invalid.
2. A priceValidUntil date in the past. Google is blunt: Your listing may not display if the priceValidUntil property indicates a past date.
Themes and apps often write a date a year from install and never move it. If you can’t keep it fresh, our reading is that leaving it out is safer than letting it go stale. It is a recommended property, not a required one.
3. The page isn’t a page where someone can buy. Google restricts eligibility: Only pages where a shopper can purchase a product are eligible for merchant listing experiences, not pages with links to other sites that sell the product.
Category pages, comparison pages, blog posts with product markup and affiliate round-ups will not qualify, however complete their markup.
4. Markup written by JavaScript. Google warns about it twice, in two places, for two different reasons. On the search side: Be aware that dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price.
On the Merchant Center side it is a hard requirement for automatic updates, because the markup can't be generated with JavaScript after the page has loaded
(Google’s page on structured data for Merchant Center).
If your product markup is injected by an app or a tag manager, Search Console’s URL Inspection tool will often show it while Merchant Center never sees it.
The same markup Merchant Center reads
This report is a Search Console feature, but the markup behind it is the markup Merchant Center uses to check your prices and stock. Google’s rule for it is one sentence long and it is the one that causes suspensions: your structured data must match the values that are shown to the user
. If a mismatch has already cost you the account, our guide to how to fix a Misrepresentation suspension works through the fixes in order.
Merchant Center also uses it to correct your data for you. Google’s page on automatic item updates explains that the feature reads your pages’ structured data to keep price and availability current.
So markup that disagrees with the visible page is worse than no markup: it can feed Merchant Center a price your shopper never sees. Our posts on price mismatches in Merchant Center and our guide to an availability mismatch cover what happens when it does.
It isn’t only Google reading it, either. AI shopping answers quote prices they picked up from a feed, a catalogue or a page’s own markup, which is why a stale priceValidUntil or an old price in the JSON-LD can turn up in an answer long after your page changed. Our post on ChatGPT showing the wrong price covers how to work out which source an answer came from.
After you fix: the “Validate fix” button
Press it, then wait. Google says: Validation can take two weeks or more
(Google’s page on fixing structured data issues).
Our reading: don’t press it again while it runs, and don’t read a validation still in progress as a failed fix. If you want a same-day answer on one page, use the URL Inspection tool and the Rich Results Test on that page instead. They tell you what Google can read now, whereas the report tells you about the whole site at crawl pace.
Where to fix it on each platform
- Shopify. Most themes write Product JSON-LD. Check the product template and
theme.liquidfor a second block: two Product blocks on one page is a common cause of odd issues. Apps for reviews and currency conversion often add their own. - WooCommerce. WooCommerce writes Product markup itself. Conflicts usually come from an SEO plugin adding a second copy, so turn one of them off rather than editing both.
- BigCommerce, Wix, Squarespace and others. Look for the platform’s own product markup first, then anything an SEO or reviews app adds. On a headless or single-page storefront, confirm the markup is in the HTML the server sends, not added after load.
Our post on Product JSON-LD and llms.txt covers what the markup is for in the first place, and what it isn’t.
Where ShieldKit fits
Our free store check reads your product pages the way a crawler does and reports whether it found Product structured data and whether what it found is broken. It also compares the price in that markup with the price the page itself shows, on any platform, and that comparison is in the free check.
How far the price comparison goes depends on what your platform publishes. On Shopify and WooCommerce we can also read the store’s own product list, so a paid plan lists each product whose markup disagrees with the price your store charges; everywhere else the comparison is between the markup and the page. With your Merchant Center account connected, a paid plan adds the price Google itself holds for each product, on any platform.
It doesn’t read your Search Console report, and it won’t tell you which Search Console issue is critical. It answers the question behind both: does the markup on the page exist, parse, and agree with the page?
FAQ
What does “Merchant listings structured data issues detected” mean?
Search Console found product markup on your pages that it couldn’t fully use. The email doesn’t say whether the issues are critical. Open the report under Shopping and look at the two tables: “Why items are invalid” lists the critical issues that stop a rich result, and “Improve item appearance” lists the non-critical ones, which Google says aren’t necessary to be eligible.
Do I have to fix the non-critical issues?
No. Google says fixing them isn't necessary to be eligible for rich results
. They can improve how a listing looks, which is why the table is called “Improve item appearance”.
Which properties does Google actually require?
On the Product: name, image and offers. On the Offer: price (or priceSpecification.price) and priceCurrency. Merchant listings also need a price above zero, which product snippets don’t.
Why does my markup show in the testing tool but not in Merchant Center?
Usually because it is added by JavaScript after the page loads. For Merchant Center’s automatic updates, Google requires markup that can't be generated with JavaScript after the page has loaded
, and it warns separately that dynamically generated markup makes Shopping crawls less frequent and less reliable.
How long does “Validate fix” take?
Google says validation can take two weeks or more. Our reading: start it once, leave it, and use URL Inspection on a single page if you need a quicker answer about that page.