Every schema testing tool draws a line between errors and warnings, and I find most people treat that line as a suggestion rather than a real distinction. It is not a suggestion. Errors and warnings mean structurally different things, and mixing them up leads to either wasted effort chasing warnings that do not matter or, more often, ignoring a warning that is quietly the reason a rich result never showed up.
What an error actually means
An error means the markup violates the specification in a way that blocks Google, or any parser, from processing it correctly. This includes malformed JSON-LD (a missing comma or unclosed bracket that breaks parsing entirely), a required property that is missing (a Product without a name, for instance), or a value in the wrong format (a date that is not ISO 8601, a price that is not a number). Errors are unambiguous: fix them before doing anything else, because a page with an error is not eligible for the rich result at all, and in the case of a JSON-LD parsing error, none of the markup on that page is being read by anything.
What a warning actually means
A warning means a recommended, not required, property is missing. Schema.org and Google both define properties as required or recommended for each type, and a warning fires on the recommended list. The critical thing to understand is that “recommended” does not mean “optional in practice.” For an Article type, image is commonly flagged as a warning rather than an error, but in my experience an Article without an image property is far less likely to generate a rich result or an AI Overview citation than one with it, warning or not. The same is true for author and datePublished on content types, and for aggregateRating or review on Product types. Google’s own documentation is explicit that meeting only the required properties is the minimum bar, not the target.
How I actually prioritize a list of warnings
When a client sends me a Search Console export with forty warnings across a site, I do not treat them as one list. I sort by which property is missing, because the same missing property across many pages usually traces back to one template gap, and by which type it belongs to, because a warning on your highest-traffic template deserves attention before the same warning on a handful of low-value pages. Concretely, I prioritize in this order: missing image or author on content pages, since these correlate most directly with visibility in my experience; missing aggregateRating or review on Product or Service pages, since these drive the actual visual difference (stars) that gets the click; and then everything else, which tends to be lower-impact properties like alternateName or sameAs that round out entity clarity but rarely make or break rich result eligibility on their own.
When a warning is genuinely low priority
Not every warning deserves attention immediately. If the Validator flags a missing additionalType or a niche property that neither Google nor any other consumer of your markup is known to use, I note it and move on. The goal is not a zero-warning report — that is a vanity metric. The goal is a testing process that separates the properties actually correlated with visibility from the ones that are technically recommended but practically inert. That distinction only becomes clear once you have tested enough sites to see which warnings keep showing up alongside missing rich results and which ones do not.
Errors and warnings together tell a story
The most useful signal is not either category alone but the pattern across both. A page with zero errors and several warnings that never generates a rich result is a strong hint that one of those “recommended” properties is functionally required for that type in practice. I walk through the broader set of reasons rich results fail to appear, including cases with a completely clean report, in why rich results are not showing. And if you have not yet built a repeatable process for catching these before they pile up, my full schema testing workflow covers the sequence of tools I run and when.
A concrete example: the missing image warning
One pattern I see often enough to call out specifically: a client’s Article or Product pages pass with zero errors, one warning for a missing image property, and the client asks whether it is worth the engineering time to fix a “warning.” In nearly every case I have tested, yes. The image property is what Google uses to decide whether to show a visual element alongside the result, and on mobile search in particular, results with an associated image occupy noticeably more space and get a disproportionate share of clicks compared to a plain text listing. Calling this a warning rather than an error is technically accurate under the spec — an Article without an image is still valid structured data — but treating it as low priority because of that label is a mistake I would not make on my own sites. The label tells you whether the markup is spec-compliant. It does not tell you whether the property is worth having.
A concrete example: warnings that really are safe to skip
On the other end, I have had clients spend time chasing a warning for a missing alternateName on an Organization entity, or a missing areaServed on a Service type that genuinely serves one location with no ambiguity. In both cases, adding the property did nothing measurable, because the property exists to disambiguate a case that did not apply to that business. Knowing the difference between these two examples — one where the “just a warning” label is misleading and one where it is accurate — comes down to understanding what the property is actually for, not just whether the tool flagged it.
If a client’s Search Console is showing a consistent pattern of the same warning across dozens or hundreds of URLs, that is not a page-by-page fix — it is a template issue, and it is the kind of systemic pattern I look for first when doing schema markup consulting work.