Fixing Missing Required Fields in JSON-LD

Three different meanings of "required"

Much of the confusion around this finding comes from the word itself. Three different parties can call a property required, and they rarely agree.

This is why two validators can disagree. The Schema Markup Validator checks vocabulary and passes a bare Event with only a name. The Rich Results Test checks Google's feature rules and fails the same block because startDate and location are absent. The JSON Checker reports both layers, so you can see which rule a finding comes from.

Required fields for common types

These are the properties Google's documentation lists as required for common features at the time of writing. Google revises its guidelines, so treat this as a working checklist and confirm against the feature's own page when something does not add up.

If a type your pages use is not in the table, look up the feature in Google's search gallery documentation. If Google offers no rich result for the type at all, there is nothing "required" in Google's sense, and a missing property is at most a gap in how completely you describe the page.

Why hand-written and plugin markup loses fields

Markup produced by a theme, plugin or custom template rarely omits a field because someone forgot it. It omits it because the data behind it was empty, or because the value was printed somewhere the consumer does not look.

• Conditional output with empty source data. Well-written templates skip a property when its source field is blank, which avoids invalid values but leaves the field missing. A post with no featured image produces a Recipe with no image; an event entered without a venue produces no location.
• Plugin settings never completed. SEO plugins build Organization, LocalBusiness and publisher data from a settings screen. If nobody filled in the address, logo or business name during setup, every page inherits the gap.
• A type printed on the wrong pages. Themes sometimes output a Product or Event block on archive and category templates, where there is no single price or date to give. The result is a flood of missing field errors from pages that should carry no such markup.
• The value is present but at the wrong level. price placed directly on a Product, or address placed on an Event instead of inside its Place, looks complete to a person reading the code, but the consumer looks for it in a specific object and reports it as missing.
• A near-miss property name. Property names are case-sensitive. startdate, StartDate and start_date are all unknown properties, so startDate is reported missing even though a date is sitting right there.
• The wrong kind of value. Some consumers ignore a value that is not the expected type. An Event location given as the bare string "Town Hall" may not satisfy a rule that expects a Place with an address.

Required fields inside nested objects

Many requirements apply to an object inside the main one. The finding names the top-level type, but the fix is one or two levels down. This Event shows the shape that satisfies the rules for an in-person event, with the required values at the level where they are read:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Spring Pottery Open Studio",
  "startDate": "2027-04-17T10:00:00+01:00",
  "endDate": "2027-04-17T16:00:00+01:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "Millbrook Clay Works",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "4 Canal Yard",
      "addressLocality": "Millbrook",
      "postalCode": "MB1 2CW",
      "addressCountry": "GB"
    }
  },
  "image": "https://www.example.co.uk/images/open-studio-1200.jpg",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "GBP",
    "url": "https://www.example.co.uk/events/open-studio/",
    "availability": "https://schema.org/InStock"
  }
}
</script>

The common nesting mistakes, and where each value should live:

If the nested object is referenced by @id rather than written in place, the definition it points to must carry the required values. A reference to an entity that is not defined anywhere is a separate problem, covered in the dangling references guide.

Reading the report without chasing noise

A large site can show hundreds of missing field entries. Most come from a small number of templates, so group before you fix.

1. Sort errors from warnings. In Google's tools, a required field appears as an error, and a recommended one appears with "(optional)" after the name. Fix errors first; they are the ones that remove eligibility.
2. Group by template. Take the affected URLs and note which page template each uses: product, post, event, category, location. If every URL in the group shares a template, one change fixes them all.
3. Group by source. Check whether the failing block comes from the theme, a plugin, an app or a hand-written snippet. The JSON Checker shows each block separately, so you can tell a theme's Product apart from a review app's Product on the same page.
4. Look at one good page. If some pages on a template pass, compare the source data of a passing page with a failing one. The difference is usually an empty admin field.

The fix, step by step

When the data genuinely does not exist

Some missing fields cannot be fixed honestly. Google's guidelines expect structured data to reflect the visible page and real facts, and markup that invents values can lead to a manual action that removes rich results across the site. Better options:

• An event with no fixed date yet. Leave out Event markup until the date is confirmed. When it is postponed with no new date, keep the old startDate and set eventStatus to EventPostponed.
• A product with no price because it is "price on application". You cannot meet merchant listing rules, but you can describe the product with real reviews or ratings for product snippets, or describe it without chasing a rich result.
• A recipe or article with no image. Add a real photo of the finished dish or a relevant image. A generic logo or stock placeholder used on every page does not represent the content.
• A job with no stated location. If the role is remote, say so with jobLocationType set to TELECOMMUTE and the countries applicants may live in. If it is office-based, the office address exists and should be added.
• A business with no public address. Service-area businesses that do not receive customers at their premises may prefer not to publish an address. In that case LocalBusiness rich features may not apply, and a plain Organization is the honest choice.

Keeping required fields filled

• Make the source fields mandatory. If recipes need an image, make the featured image a required field in the editor, or add a pre-publish checklist item. Fixing the input is cheaper than fixing the output.
• Print types only where they apply. Restrict Product markup to product templates and Event markup to single event pages, so archive pages never produce half-empty blocks.
• Test per template, not per page. Keep one URL per template and re-run it through the JSON Checker after every theme, plugin or app update, and after any change to custom fields.
• Watch the enhancement reports. A sudden rise in missing field errors in Search Console after a release usually means a template stopped printing a value, not that content changed.