Fixing Missing Required Fields in AI-Generated Schema

What "missing required field" means for generated markup

A required field is a property that a particular Google rich result cannot work without. Schema.org itself makes almost nothing mandatory, so the word only has meaning against a named feature. The same Recipe block can be complete for one purpose and incomplete for another. When the generator validates its output against Google's criteria and flags a required field, it is telling you that the block, as written, cannot be considered for that feature at all.

The fields Google marks as required are short lists, and they are usually the most basic facts about the thing:

Google changes these lists from time to time and has retired several features in recent years, so check the current documentation for your type before you start work. Article, notably, has no required properties in Google's documentation at all; if an Article block is being flagged, the problem is almost always a missing image or a malformed value rather than an absent field.

Why a model misses facts that are plainly visible

A person looking at a page sees a finished picture. A language model reading a page works from text: the words, and whatever structure survives the conversion of the page into something it can read. Anything that is not text, or not text at the moment the page is read, is invisible or ambiguous to it. The common reasons fall into five groups.

1. The fact is a picture

Event posters, menu boards, price lists saved as images, infographics with opening hours, and screenshots of spec sheets all carry information as pixels. Unless the same words appear in the HTML, perhaps in alt text or a caption, the model has nothing to extract. Alt text helps only if it actually states the fact; "summer fair poster" does not give a start date.

2. The fact arrives after the page loads

Prices from a pricing API, stock levels, review widgets, store locators and many booking systems write their content into the page with JavaScript once it is running in a browser. Tools that read the page source, rather than the page as rendered, see an empty container. Whether a given generator renders scripts depends on the tool, so the safe assumption is that anything missing from View Source may be missing from what the model read.

3. The fact is in a different document

Iframes are separate pages. A YouTube or Vimeo player, an embedded Google map, a ticketing widget and many review carousels all live in their own documents. The text inside them is not part of your page's HTML, so a video's upload date or a venue's address shown inside an embed is not available to extract.

4. The fact is there but unlabelled

A line reading "Sat 14th, doors 7" is a start date to a local reader and noise to a model deciding whether it is a date, a room number or a price. The same happens with prices written as "from 12", times given as "an hour or so", ingredients split across two columns, and addresses broken over separate elements with no heading. The model may skip a value rather than risk a wrong one, which is the behaviour you want, but it leaves a gap.

5. The fact belongs to the site, not the page

Your business address, logo, company name and default image are often in the header, footer or another page. A generator that reads the main content, or that is asked to describe one page, can reasonably leave them out. These are the values that should come from site-wide settings rather than page-by-page generation anyway.

Finding where each missing value really lives

Diagnosis takes a few minutes per template and tells you which of the fixes below applies. For each missing field, answer three questions in order.

1. Can a visitor see it? Open the live page in a normal browser window. If the value is nowhere on the page, stop here: it is a content gap, not an extraction problem.
2. Is it in the source? Press Ctrl+U (Cmd+Option+U on a Mac) to open View Source and use find for the exact value, such as the price or the date as printed. If it is not there, it arrives by script or through an iframe.
3. Is it text, and is it labelled? If the value is in the source, look at the surrounding HTML. Is it inside an element with a clear label or heading, such as a <dt> reading "Date", a table column called "Price", or a <time> element? Or is it a loose fragment?

The answers point straight at the remedy:

Making facts readable without changing how the page looks

Often the cleanest fix is to improve the page itself, so that the fact is present as labelled text. That helps every reader of the page, including screen readers, search engines and AI systems, not only the schema generator. Small changes usually do it:

• Dates in <time> elements. Wrap a printed date in <time datetime="2026-11-14T19:00:00+00:00">Sat 14 November, doors 7pm</time>. The visitor sees the friendly wording; the machine-readable value sits in the attribute.
• Real images with honest alt text. Swap a CSS background hero for an <img> element, and write alt text that describes the picture. The recipe or product image then has a URL the generator can find.
• Poster text repeated as text. Under an event poster, add a short line with the date, time and venue. It also helps visitors on slow connections and anyone who cannot see the image.
• Labelled details. A small definition list with "Price", "Venue" or "Prep time" as labels removes guesswork about which number is which.
• Currency written out. A £ sign is usually enough for a person, but a model can safely map "£24.00" to GBP only if nothing else on the page suggests another currency. Where you sell in several currencies, state the currency explicitly.

For script-loaded content, the durable fix is server-side rendering: output the price, stock or review summary in the HTML the server sends, and let the script update it afterwards if it needs to. Most e-commerce platforms and modern frameworks can do this. If that is not practical, keep the value out of the generated snapshot and take it from the same data source the script uses, so that the markup and the page cannot drift apart.

Worked example: an event with its date in the poster

A fictional venue, Riverside Hall, published a page for a ceilidh night. The date and venue were only in the poster, so the generated block came back with just a name and description. After adding one line of text under the poster, with the date in a <time> element and the venue address written out, regeneration produced a block the checker accepted:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Autumn Ceilidh Night",
  "startDate": "2026-11-14T19:00:00+00:00",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "eventStatus": "https://schema.org/EventScheduled",
  "location": {
    "@type": "Place",
    "name": "Riverside Hall",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "12 Mill Lane",
      "addressLocality": "Exampleton",
      "postalCode": "EX1 2AB",
      "addressCountry": "GB"
    }
  },
  "image": "https://www.example.co.uk/images/ceilidh-poster.jpg",
  "url": "https://www.example.co.uk/events/autumn-ceilidh"
}
</script>

Every value in it can be pointed to on the page. Nothing was typed in by hand that a visitor could not read, which is the test to apply before publishing.

The fix, step by step

Where missed facts usually hide, by platform

WordPress

Page builders are the usual culprit. Hero sections set as background images, text inside slider modules and details held in tabbed widgets can all be hard to read in context. Event and booking plugins often print dates through their own shortcodes, which is fine as long as the output is text; check that it is not a calendar rendered by script. Recipe card plugins usually output well-labelled text, so a missed ingredient list there is more likely a duplicate block issue than an extraction one.

Shopify

Themes normally render product title, price and images in the HTML, but some apps replace the price block with a script, particularly bundle, subscription and currency conversion apps. Review counts from review apps are frequently loaded by script too. The Shopify guide explains why moving values like these should come from Liquid rather than a generated snapshot.

Custom sites and JavaScript frameworks

Single-page applications built with client-side rendering can send an almost empty HTML shell, so a tool that does not run scripts sees nothing at all. Frameworks with server-side rendering or static generation, such as Next.js, Nuxt or Astro, avoid this when configured to render the content on the server. If you control the data, the most reliable pattern is to build the JSON-LD from the same props or API response that renders the page, and use generated output only as a guide to structure.

Hand-built and static sites

Static pages are usually easy for a generator to read, so misses there tend to come from wording. Look for dates without years, prices without currency, and ranges like "10 to 4" in opening hours that are clear to people but ambiguous in isolation.

Awkward cases

The fact is on the page but only in a PDF

A downloadable menu, brochure or timetable is a separate file. The generator reading the page will not see inside it. If the fact matters, such as opening hours or a course start date, put it in the page text as well; that also helps visitors on phones who would rather not open a PDF.

The fact is in a tab or accordion

Content in closed tabs is usually still in the HTML, just hidden with CSS, so it is readable. If it is loaded only when the tab is clicked, it behaves like script-loaded content. Check View Source to tell the difference.

Different variants have different values

A product with sizes at different prices, or an event with several dates, may come back with none of them because the model could not choose. Decide what the page represents: the selected variant, a price range with AggregateOffer, or separate Event entries for each date. Then supply the values to match that decision.

The image exists but fails the requirements

Sometimes the image field is filled but still flagged, because the URL points to a thumbnail, a placeholder, a lazy-loading stub or a file blocked by robots.txt. Point it at the full-size, crawlable image that appears on the page.

Getting it right on the next page

• Write key facts as text. Make it a house rule that dates, prices, addresses and times are always in the page text, even when they also appear in a graphic.
• Use semantic elements. <time>, <address>, definition lists and tables with headers give both people and tools the context they need.
• Keep site facts in one place. Business name, address, logo and default image belong in site-wide settings or a single Organization entity, not in every generated block.
• Test a sample per template. When you add a new template or install a new app, generate markup for one page and check for new gaps before rolling out.
• Recheck after redesigns. A new theme or page builder layout can move facts into images or scripts without anyone noticing. Rerun a few pages after any visual change.

For the related problem of markup that has every required field but still does not appear as a rich result, see the rich result eligibility guide. For required fields in hand-written or plugin markup, rather than generated output, the required schema fields guide covers that side.