Valid is not eligible: the properties Google actually requires

Schema.org is a vocabulary. Its job is to define what a word means and where it may be used: a property page tells you which types accept it and what kinds of value it takes, and that is the whole remit. It has no notion of a mandatory property, which is why its validator will never report one as missing. From its point of view a Product with nothing but a name is as correct as one with forty properties. Both are things it can understand.

Google's structured data documentation is a different kind of document with a different purpose. It is organised by feature rather than by type, and each feature page carries a table splitting properties into Required and Recommended. That table is not a description of the vocabulary. It is the entry condition for one presentation on one search results page, and Google is free to change it, which it does.

Nothing in your markup is invalid when a required property is missing. It is ineligible, and those are not the same word.

One consequence of the split catches people out. Requirements attach to features, not to types, so the same type can clear the bar for one presentation and miss it for another because two features read it with different tables. And a type with no feature attached to it has no required properties at all, because there is nothing to be eligible for.

The instinct is that some markup beats no markup, and on this rung it is wrong. Four reasons, in the order they cost you money.

• You pay the maintenance and get nothing back. Once a price is in your markup, every price change has to update two places instead of one. An incomplete block carries that whole liability with none of the eligibility that was supposed to justify it.
• A permanent error count hides real ones. Google's report lists items missing a required property as errors, so a template that has always been incomplete produces a number that never reaches zero. Six months later nobody reads that report, and a genuine regression arrives inside a count everyone has learned to ignore.
• The missing property is the expensive one. Nobody omits name. What goes missing is the review count nobody collects, the currency the storefront treats as implicit, the modified date the CMS never recorded. Those are exactly the properties your competitors had to build a system to supply, which means the comparison you lose is with the sites that did.
• A stale value is worse than an absent one. A half-finished block is usually half-wired, and the properties that were filled in by hand stop matching the page the first time the page changes. Markup that contradicts its own page is a different and more serious problem than markup that says less than it could.

The reliable method is to stop reading schema.org for this question. Its type pages list every property a type accepts, in alphabetical order, with no indication of importance, because importance is not something a vocabulary has an opinion about. Reading schema.org/Product to work out what you need produces a list of everything and a plan to write half of it.

Google publishes an index of the structured data features its search results support, and each feature has its own page with the Required and Recommended table for that feature. That table is the only list that decides eligibility. If a type you are marking up does not appear in that index at all, then no properties are required, and the reason to write the markup has to be something other than a search feature.

There is also a faster way to answer it for a page you have already built, without reading either document. Run the URL through Google's Rich Results Test and read the two categories separately. An error means a required property is missing and the item is out. A warning means a recommended property is missing and the item is still eligible. That distinction is the requirement table, applied to your actual markup, which is more useful than the table itself.

Two cautions on the tooling. It only reports on features it still renders, a limit the HowTo guide works through, so a type with no live result gives you no requirement feedback at all. And the vocabulary validator at validator.schema.org is the wrong instrument here by design: it will pass the ineligible block above without a murmur, because from its side there is nothing wrong with it.

Not directly, and the reason is worth being clear about rather than hedging. Required properties are a Google concept. They exist to gate one vendor's presentations, and no assistant publishes a property list you have to satisfy before it will read your block. A model handed structured data takes what is in it. Nothing is dropped for incompleteness, because nothing was checking.

So the eligibility argument does not transfer. What does transfer is why those specific properties ended up on the list. They are, almost without exception, the ones that remove an ambiguity a reader cannot resolve on its own. A currency turns a number into money. A count turns a rating into evidence. A date turns a claim into a claim made at a time. Any machine reading your page benefits from those for reasons that have nothing to do with rich results, which is a better argument for completing them than eligibility was.

And there is a small active harm worth naming. An incomplete block does not merely say less, it can say something wrong. A price with no currency invites a guess, and a guess about currency is not a rounding error. If you are going to state a fact in machine-readable form, state enough of it to be interpreted one way.