JSON-LD Required vs. Recommended Fields, Why Add Fields That Aren't Mandatory?
"The schema.org docs say most properties are optional — so why does everyone say a rich snippet won't show up without this field?" Anyone new to structured data runs into this confusion sooner or later. The cause is simple: the rules you actually have to follow come from two different organizations, and their standards don't overlap. This guide lays out what those two standards are, why they diverge, and how to handle it in practice.
1. The schema.org spec and Google's requirements are two separate documents
schema.org is a "vocabulary" jointly built by a W3C community group along with Google, Microsoft, Yahoo, and Yandex. The vocabulary itself defines most properties as optional — a loose definition along the lines of "an Article may have an image." Google Search, on the other hand, maintains its own separate requirements document (Google Search Central's structured data guidelines) that defines how this vocabulary gets turned into rich results — star ratings, prices, FAQ accordions, and so on. That document spells out Google's own required conditions: "if this field is missing, we won't show this rich result at all." In other words, schema validity (the schema.org standard) and rich-result eligibility (Google's standard) are two entirely separate checks.
2. Why a "valid schema" sometimes shows no snippet
Because these two standards differ, you can end up with a schema whose JSON-LD syntax is perfect and whose @context/@type are correct — a "valid" schema by spec — and still see zero rich snippets in search results. For example, an Article type is syntactically fine with just a headline under the schema.org spec, but for Google to actually show an Article rich result (like the top news carousel), fields such as author and datePublished are effectively required. The Schema Validator implements this distinction explicitly in its code, maintaining separate REQUIRED_FIELDS (marks the schema invalid if missing) and RECOMMENDED_FIELDS (keeps it valid but shows a warning) lists.
| @type | Required fields (invalid if missing) | Recommended fields (warning only if missing) |
|---|---|---|
| Article | headline, author, datePublished | description, image, publisher |
| Product | name | description, image, offers, aggregateRating |
| Event | name, startDate, location | endDate, description, organizer, image |
| Recipe | name, recipeIngredient, recipeInstructions | description, cookTime, prepTime, recipeYield, image |
The important thing here is that the "required fields" in this table aren't schema.org's own required rules — they're the tool's reflection of the minimum conditions search engines like Google actually demand for a rich snippet to appear.
3. The real reason to fill in recommended fields
"Not filling in recommended fields still gets you a snippet" is accurate, but having them increases the odds of a richer-looking snippet. For example, if a Product has an image, the search result shows the product photo alongside it; if it has aggregateRating, star ratings appear. These directly affect click-through rate (CTR), so the real motivation for filling them in isn't "to follow the rules" — it's "to stand out more in search results."
name filled in still gets judged "valid" by the Schema Validator. But without offers (price) and aggregateRating (rating), Google is unlikely to show the rich snippet with price/star display and will more likely fall back to a plain link. In other words, "passing validation" and "standing out in search results" are two separate goals.
4. The final check comes from Google itself, not a tool
A site's own validation tool (including a schema validator) is useful for quickly checking whether fields are present based on the spec and Google's guidelines, but the final call on whether a rich snippet actually shows up rests with Google itself. Google factors in page quality, spam signals, crawl frequency, and more on top of field presence when deciding whether to display something — so after your first-pass check with a self-hosted tool, a second-stage check with Google's Rich Results Test is still necessary before you can trust the actual outcome.
5. Practical checklist
- First, run the Schema Validator to catch syntax errors and missing required fields.
- Once all required fields are filled, scan the recommended-field list and add whatever you can (image and aggregateRating especially move the CTR needle).
- Rather than hand-writing a new schema, using a type-specific generator like the Article Schema Generator or Product Schema Generator reduces the odds of missing required or recommended fields.
- After deploying, periodically check Google Search Console's "Enhancements" report to confirm the page is actually being recognized as eligible for rich results.
Frequently Asked Questions
Q. I filled in all the required fields but still don't see a rich snippet. Why?
A. Meeting the required fields only makes you eligible — it's not a guarantee. Google also weighs page quality, whether the markup matches the visible content, site trustworthiness, and more before deciding whether to display it, and it can take anywhere from days to weeks to show up even after everything checks out.
Q. Are there schema.org types that Google's guidelines don't cover at all?
A. Yes, plenty. schema.org defines hundreds of types, but Google only supports a subset of them for rich results (Article, Product, Recipe, FAQPage, Event, and others). No matter how thoroughly you fill in the fields for an unsupported type, it won't render as a special snippet.
Q. Do the required-field criteria change often?
A. Yes. Google periodically updates its structured data guidelines, and types that have seen heavy abuse — FAQPage and HowTo, for example — have had their eligibility requirements tightened. It's safe to re-check the Google Search Central documentation roughly every six months.
Q. Can I fill in fields with values that don't match reality?
A. No. A schema that doesn't match the actual content — for example, showing a rating that doesn't really exist — violates Google's structured data policy and can trigger a manual action, ranging from loss of rich-result eligibility to harsher penalties. Always keep the schema values in sync with what's actually shown on the page.