“Product snippets structured data issues detected”: What the Search Console Alert Means
Search Console sends you a message: “Product snippets structured data issues detected.”
Now you have a list of questions the email does not answer.
Is something broken? Is this serious? Does it affect indexing or rankings? Do you need to add whatever field Search Console says is missing? Is your Shopify theme fighting with an app? And, probably most important, what should you inspect before you start changing code?
The first thing to understand is that the notification is a starting signal, not a diagnosis.
Search Console has surfaced an issue associated with Product snippet structured data. Before you decide what to fix, you still need to know what the issue is, whether Google classifies it as critical or non-critical, which property is involved, which items or URLs are affected, whether that property actually applies, and what your page currently outputs.
That distinction can save you from solving the wrong problem.
What the Product snippets alert actually establishes
Search Console has a rich-result report specifically for Product snippets. Those reports show structured-data items Google has detected, whether reported items are valid or invalid for the corresponding rich-result feature, and the critical or non-critical issues associated with them. Google also notes that these reports are samples, not a comprehensive inventory of every structured-data item it knows about on a site.
That is what the alert gives you: a reason to inspect the affected structured data.
It does not, by itself, establish that the page has been deindexed. Google treats indexing status and structured-data enhancement issues separately; a URL can remain on Google while a structured-data item on that page has a critical issue.
It also does not establish a ranking loss. You would need separate performance evidence to make that claim.
It does not establish that the whole site has failed, because Search Console's rich-result reports are sampled.
It does not establish a manual action. Google has a separate Manual Actions report for cases where a human reviewer has determined that pages violate Google's spam policies.
And if the site happens to run on Shopify, the alert does not establish that your theme and an app are producing conflicting schema. That is one possible technical condition to investigate when the evidence points in that direction. It is not the definition of a Product snippets issue.
Start with what Search Console actually reported.
Critical and non-critical issues mean different things.
Google largely moved away from the older top-level Warning and Error categorization in Search Console. In current rich-result reporting, the important distinction is whether an item has a critical issue or only non-critical issues.
A critical issue can make that structured-data item invalid for the relevant rich-result feature. Google's Product snippet documentation likewise tells implementers to fix critical errors for eligibility.
A non-critical issue is different. An item can remain valid while Search Console reports improvements that could provide more complete data or affect the appearance available to the feature. Google’s Search Console issue-categorization documentation says non-critical issues can exist on valid items and may improve appearance if fixed.
Neither classification tells you that rankings changed.
Neither classification guarantees that a rich result will or will not actually display once the item is eligible. Google states separately that valid structured data enables eligibility for supported features; it does not guarantee that a particular search feature will appear.
And a critical structured-data issue is still not the same thing as a page-indexing failure.
The classification tells you the severity of the issue within the structured-data feature you are looking at. Keep the conclusion inside that boundary.
“Missing” does not automatically mean “required”
This is where Product snippets alerts can send people in the wrong direction.
Search Console may tell you that a property is missing. The natural reaction is to find that property, add it to the JSON-LD, and try to make the message disappear.
But first you need to ask whether Google actually requires that property for your implementation.
For Product snippets, Google's current documentation requires a name and at least one of three properties: review, aggregateRating, or offers. You do not have to provide all three. Google even notes that the Rich Results Test may still report a warning when offers is present without review or aggregateRating, despite only one of those three being required.
That is a useful example of why a surfaced message needs interpretation before implementation.
Offer markup has its own requirements and recommendations. For a Product snippet Offer, Google requires a price through price or the appropriate priceSpecification.price. Properties including availability, priceCurrency, and priceValidUntil sit in the recommended-property section for Product snippets. Google describes priceValidUntil as the date after which a price will no longer be available if applicable.
That last phrase matters.
If your price has a genuine expiration date, accurately representing it may make sense. If it does not, inventing an expiration date simply to remove a Search Console message would create new information that the business and visible page do not support.
The same principle applies to reviews. If a product has no real review data, you do not manufacture an aggregateRating or a Review because Search Console mentioned the property.
Google's structured-data guidelines say not to mark up information that is not visible to readers and require the structured data to be a true representation of the page content.
The goal is not a dashboard with fewer messages.
The goal is structured data that accurately represents the page and meets the requirements that actually apply.
Product snippets and Merchant listings are related, but they are not the same thing
Product structured data on Google has two related feature families.
Google describes Product snippets as being for product pages where people cannot directly purchase the product, including editorial and review-oriented use cases. Merchant listings are designed for pages where customers can purchase products directly, with additional commerce-specific information such as shipping and return details.
That sounds clean until you reach the next sentence in Google's documentation: there is overlap.
Google says that supplying the required Product information for Merchant listings generally also makes a product page eligible for Product snippets. Both support Product data, but they have different requirements and enhancements.
Search Console reflects that distinction by providing separate Product snippet and Merchant listing reports under Shopping when Google finds the corresponding structured data.
So if you run an ecommerce site and receive a Product snippets notification, do not treat that notification as proof that Google has somehow classified the page as an editorial or non-commerce page.
Look at what the page actually does. Then look at the Product snippets issue and, where relevant, the Merchant listings report.
Requirements can differ between the two. priceCurrency, for example, is currently recommended for Product snippets but required with the applicable price structure for Merchant listings.
Context determines which requirement you are evaluating.
What to inspect before changing anything
The fastest way to turn an alert into unnecessary work is to start editing the theme before you have identified the actual finding.
Use the message as the beginning of an investigation:
- Open the specific Product snippets issue in Search Console. Do not stop at the email subject. Open the issue detail and identify what Search Console is actually reporting. Google's issue pages show the issue itself, affected examples, validation state, and other details that help narrow the problem.
-
Record the classification, exact property or path, and representative affected items or URLs. Is it critical or non-critical? Is the message about
priceValidUntil,review,aggregateRating, an Offer property, or something else? Remember that the examples shown in Search Console are not necessarily an exhaustive sitewide list. - Identify what kind of page you are looking at. Is this a product someone can buy directly? An editorial product review? An aggregator page? That affects whether Product snippet requirements, Merchant listing requirements, or both deserve attention.
- Test a representative affected URL with Google's Rich Results Test where appropriate. The test shows which Google-supported rich-result types it can process from the live page and reports relevant structured-data issues. Its documented job is rich-result testing—not determining which Shopify theme, app, snippet, or developer created a block of markup.
- Compare the structured-data values with the visible page. Check the facts that matter for the reported issue: product name, price, currency, availability, reviews, ratings, or other relevant fields. Structured data should represent the content users can actually see.
- Determine whether the flagged property is required, recommended, and applicable. Read the current documentation for the feature rather than assuming every missing-field message calls for the same fix. Product snippet requirements and Merchant listing requirements are not identical.
- Trace source ownership only when the evidence gives you a reason to. If multiple Product outputs appear to describe the same item differently, values contradict the storefront, or you cannot safely change the markup without knowing which system generates it, source tracing has become relevant.
- If you make a change, test the deployed result and use Search Console's validation workflow where appropriate. Google provides a Validate fix process for reported issues after corrections have been deployed and checked.
Notice what is missing from that sequence: guessing.
You are moving from reported observation to evidence before you move into diagnosis or implementation.
When Shopify source tracing becomes relevant
Shopify can add another layer because structured data can come from more than one place.
Theme code can generate Product structured data. Shopify's own Liquid documentation, for example, provides a structured_data filter that can output Product or ProductGroup data from product objects.
A store can also have apps, review tooling, custom code, or remnants of previous implementations contributing structured data.
But this is the boundary to keep clear:
A Product snippets alert is not itself a diagnosis of a Shopify conflict.
Multiple structured-data items on a page are not automatically a defect when they legitimately describe the page’s content.
Source tracing becomes useful when the evidence gets more specific: two outputs appear to describe the same product with contradictory values; the structured data does not match visible product facts; or ownership is uncertain and you need to know what generated an output before you remove or alter it.
That is the problem state covered more deeply in Project E.V.I.L.'s Shopify structured-data conflicts article. It is a different starting point from interpreting a Search Console notification.
The right next step depends on what you found
By the time you finish the inspection, the message should have turned into a much narrower decision.
If the issue is non-critical, the property is not applicable, and your current markup accurately reflects the page, there may be no justified change to make simply to remove the notification.
If the property is recommended, applicable, and backed by real information already available on the page or in the business's product data, adding it accurately may be reasonable.
If a genuinely required property is missing, investigate the implementation that should supply it. Google's structured-data guidelines state that items missing required properties are not eligible for the corresponding rich result.
If two outputs disagree about the same product, or the markup and storefront tell different stories, you have moved beyond a missing-field question. Now you are investigating a source or content-alignment problem.
If you mainly want a human to explain the alert while looking at your site with you—and you do not need a written report—the Live Schema Walkthrough is the smaller paid option.
For a Shopify store where a theme/app/custom-code conflict is already known or strongly suspected, Shopify Schema Repair & Structured Data Fixes is the narrower Project E.V.I.L. path. The work begins with establishing what is producing the relevant output and whether the evidence actually supports a conflict before a repair is made.
If you still do not know what is wrong—or the findings span several page types, systems, or questions of applicability—the Schema Health Review is the broader diagnostic path. It is designed to distinguish verified issues, advisory opportunities, unresolved observations, and findings that do not apply before implementation decisions are made.
The sequence stays the same.
Read the issue first. Establish what the evidence supports. Then decide whether anything actually needs to change.