Fixing Rich Result Eligibility Gaps in AI-Generated Schema

Valid, eligible and shown are three separate tests

People often treat "my schema is valid" and "I should get a rich result" as the same statement. They are two steps apart, and generated markup can stall at either one.

The AI Schema Generator validates its output against schema.org and against Google rich result criteria before handing it over, so the first stage is usually settled. The second stage is where most gaps sit, for three reasons that are specific to generated markup:

• The model can only use what it can read. If ticket prices, opening hours or a rating live in a booking widget, an image or a separate system, the text the model saw did not contain them, and a careful generator leaves the field out rather than guess.
• It targets the vocabulary, not a feature. schema.org has hundreds of types. Only a small number of them feed a Google feature, and a type can be perfectly chosen for the page yet have no rich result attached to it at all.
• Some rules are about the page, not the markup. Policies such as "reviews must not be self-serving" or "the event must be open to the public" cannot be spotted by looking at JSON.

Features that exist today and what they ask for

Google's search gallery has shrunk over the years, so check the current list before promising anyone a result. HowTo rich results were removed in 2023. FAQ rich results are now shown only for well-known, authoritative government and health sites, so most businesses will not see them however good the FAQPage markup is. Google also announced in 2025 that it was phasing out a further group of less-used features; if your target is an unusual type, confirm it still appears in the search gallery before spending time on it.

For the features most sites target, this is where generated markup most often falls short of what Google asks for:

Required fields decide whether you can have the feature at all. Recommended fields decide how much of it you get: a recipe with totalTime and nutrition.calories can show cooking time and calories, one without cannot. Google's own wording is that adding recommended properties can make the result more useful, so a block with required fields only is eligible but thin.

Policy rules a validator cannot check

• Self-serving reviews. Star ratings for LocalBusiness and Organization are not shown when the business marks up reviews of itself on its own site. A generator that sees testimonials on a plumber's homepage may produce a valid aggregateRating that will never earn stars.
• Visible content. Every value must be something a visitor can see on the page. A price or rating that exists only in the markup breaks the guidelines.
• Events must be real events. Vouchers, opening hours and "sale ends Friday" are not events, even when the model reads them that way.
• Product pages must sell or review the product. A blog post that mentions a product in passing should not carry Product markup to chase stars.

Reading the test results for generated markup

Run the page, not the snippet, through the Rich Results Test. Pasting the block as code tells you whether the JSON qualifies in isolation. Testing the URL tells you what Google sees after rendering, including any other markup on the page and whether the page can be indexed.

In Search Console, each feature has its own report under Enhancements, or under Shopping for merchant listings. The reports only list pages Google has crawled since the markup went in, so an empty report straight after publishing tells you nothing. The Performance report's Search appearance filter is the only place that shows whether a feature is actually being displayed and clicked.

A quick gap audit

1. List the feature you want and its required and recommended properties from Google's documentation page for that feature.
2. Tick off each one present in the generated block.
3. For each gap, write where the true value lives: on the page, in your CMS, in a supplier sheet, or nowhere.
4. Anything that lives nowhere stays out of the markup.

Where the missing values should come from

The honest answer to most eligibility gaps is not "ask the model again" but "give it, or your template, the data it could not see". These are the usual places the missing values already exist.

Here is a generated Event after the gaps were filled from a fictional studio's booking system. The generator had produced the name, date and venue from the page text; offers, eventStatus, endDate, organizer and the extra images were added once the ticket price and finish time were printed on the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Autumn Pottery Taster Evening",
  "description": "A three-hour beginners' session on the wheel. Clay, glazing and firing included.",
  "startDate": "2026-10-17T18:30:00+01:00",
  "endDate": "2026-10-17T21:30:00+01:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "image": [
    "https://example.co.uk/img/taster-16x9.jpg",
    "https://example.co.uk/img/taster-4x3.jpg",
    "https://example.co.uk/img/taster-1x1.jpg"
  ],
  "location": {
    "@type": "Place",
    "name": "Millstream Clay Studio",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "4 Wharf Yard",
      "addressLocality": "Exampleton",
      "postalCode": "EX1 2AB",
      "addressCountry": "GB"
    }
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.co.uk/book/taster-october",
    "price": "45.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "validFrom": "2026-09-01T09:00:00+01:00"
  },
  "organizer": {
    "@type": "Organization",
    "name": "Millstream Clay Studio",
    "url": "https://example.co.uk/"
  }
}
</script>

The fix, step by step

When the markup is complete and nothing shows

If the Rich Results Test says the page is eligible and weeks have passed, the markup has usually done its job and something else is in the way. Work through these before editing the JSON again.

• The page is not indexed. A noindex tag, a robots.txt block or a canonical pointing elsewhere means Google will not show any result for that URL, rich or plain. URL Inspection shows the indexing status.
• The page is not the canonical. Markup on a URL that Google treats as a duplicate is read from the canonical version instead. If the canonical lacks the block, so does the result.
• A manual action. Check Security and Manual actions in Search Console. A structured data manual action removes rich results site-wide until it is resolved and reconsidered.
• Query and device. Rich results are shown for some searches and not others. Search for the page's own topic, not your brand name, and try on a phone.
• Site quality. Google says it may not show rich results for a site it does not consider trustworthy, even when the markup is perfect. This is not something markup can fix.
• Two conflicting blocks. If a plugin or app outputs its own version of the same type, Google may read the thinner one. The duplicates guide covers merging them.
• Time. Search Console reports and the results themselves update as pages are recrawled. A large site can take several weeks.

Getting eligibility right the first time

• Decide the feature before you generate. Set the type yourself when a page could be read two ways, and note the feature you expect alongside the page in your tracking sheet.
• Make the page carry the facts. Prices, dates, timings and ratings that are printed on the page reach both visitors and the generator. Facts hidden in widgets reach neither reliably.
• Template the moving parts. Use generated markup as the pattern and let the template supply prices, stock, dates and ratings from live data.
• Recheck the gallery once a year. Features are added, restricted and retired. Markup aimed at a retired feature does no harm, but effort spent chasing it is wasted.
• Test a sample after every theme or plugin update. Updates can strip script tags, add a second block or change what renders.