Your Schema Markup Looks Fine — Until Google Stops Showing Rich Results

Rich results aren't designed to once you add schema. Google treats structured data as a signal, not a command. If that signal is incomplete, contradicts the page content, or sits on a URL that isn't properly crawlable, the feature simply won't appear — and Search Console often takes days to reflect the change.

The gap between valid markup and eligible markup is where most rich result losses happen. A page can pass the Rich Results Test with zero errors and still fail to earn a feature because a required property is absent, the entity type is deprecated, or the page was recently moved and hasn't been recrawled yet.

Understanding this distinction matters before you start debugging. Valid means the syntax is correct. Eligible means the content, markup, and page context all meet Google's specific requirements for that feature type. Both conditions have to be true at the same time.

The Two Failure Modes

• Hard failures: Syntax errors, missing closing brackets, invalid property values — caught by validators.
• Silent failures: Correct syntax but wrong content relationship, deprecated types, low-quality page signals — only caught by cross-referencing Google's feature documentation and Search Console data.

Most of the mistakes covered in this article fall into the silent failure category. That's what makes them expensive — they don't trigger an obvious error, so teams assume the markup is working when it isn't.

1. Missing Required Properties

Every schema type Google uses for rich results has a documented set of required properties — not just recommended ones. For Recipe, that includes name, image, and recipeIngredient. For Product, name is required and at least one of Review, AggregateRating, or Offer is needed to qualify for enhanced display. Omit these and the feature won't render, regardless of how well the rest of the markup is structured.

2. Content Mismatch Between Markup and Page

Structured data must describe content that is actually visible to users on the page. Marking up a five-star aggregate rating when the page shows no visible reviews, or describing a product price in schema that differs from the displayed price, violates Google's guidelines. In our experience working with sites that lost rich results, this mismatch is one of the hardest problems to catch because it requires a human eye on the rendered page — not just a validator.

3. Applying Schema to Noindex Pages

If a page carries a noindex directive, Google won't index it — and won't surface rich results for it. This catches teams off guard on paginated content, tag pages, and staging environments accidentally left live.

4. Using Deprecated or Unsupported Schema Types

Schema.org evolves, and Google's supported feature list changes independently of Schema.org's vocabulary. Types like ItemList used for breadcrumbs have specific implementation requirements. Using a type that Schema.org still lists but Google no longer actively supports for rich results produces valid-but-inert markup.

5. Duplicate or Conflicting Markup Blocks

CMS platforms frequently inject structured data from multiple sources — a theme, an SEO plugin, and a custom post type plugin can all add JSON-LD blocks to the same page. When those blocks describe the same entity with conflicting values, parsers have to guess which is authoritative. The result is usually suppressed features.

6. Incorrect Context URL or Type Casing

Using http:// instead of https:// for the @context property, or writing "type" instead of "@type", breaks parsing silently in some implementations. These are the errors validators catch — but only if you run them.

7. Structured Data on Thin or Low-Quality Pages

Google's systems can suppress rich results on pages that don't meet a baseline quality threshold, even if the markup is technically correct. Schema on doorway pages, near-duplicate content, or pages with very low word counts rarely earns features regardless of implementation quality.

8. Not Updating Markup After Site Migrations

Domain changes, URL restructuring, and CMS migrations frequently break structured data — especially when absolute URLs are hardcoded in JSON-LD blocks or when canonical tags point to a different URL than the one carrying the schema.

Abstract descriptions of mistakes are less useful than seeing the difference in the markup itself. The examples below use FAQPage schema — one of the most commonly misconfigured types.

Broken: Missing Required Structure

The following block will pass basic JSON syntax checks but fail eligibility because the acceptedAnswer property is missing from the Question entity:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long does structured data take to work?"
    }
  ]
}

Google requires acceptedAnswer with a nested Answer type and text property. Without it, the FAQ rich result will not appear.

Correct: Complete FAQPage Implementation

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long does structured data take to work?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Rich results typically appear within days of Googlebot recrawling the page, assuming the markup is valid and the page meets eligibility requirements."
      }
    }
  ]
}

The Content Mismatch Problem in Practice

A common error: adding FAQPage markup to a page where the questions and answers are loaded via JavaScript after the initial HTML response. If Googlebot doesn't execute the JavaScript — which happens more often than teams expect — it sees schema that describes content that isn't in the DOM it crawled. The fix is either server-side rendering for the FAQ content or confirming JavaScript rendering works via the URL Inspection tool in Search Console.

Running the Rich Results Test on a live URL (not a code snippet) is the fastest way to catch rendering gaps, because it uses a real Googlebot user agent and reports what was actually parsed.

When a rich result disappears, the fastest path to a fix follows a specific diagnostic order. Skipping steps wastes time — especially when the problem is a content mismatch that a validator won't surface.

1. Check Search Console's Enhancements report first. If Google detected an error or warning, it will be listed here with the affected URLs. Error messages like "Missing field 'acceptedAnswer'" tell you exactly which property to fix.
2. Run the Rich Results Test on the live URL. Not a code snippet — the live URL, so the test renders the page the same way Googlebot does. Look for detected items, then cross-reference the properties found against Google's documentation for that specific feature.
3. Inspect the URL in Search Console. Check whether the page is indexed, whether the last crawl date is recent, and whether there are any coverage issues. A page that hasn't been recrawled since you added schema hasn't had its markup evaluated yet.
4. Audit for duplicate schema blocks. Use browser DevTools to view the page source and search for multiple @type declarations of the same entity. If your CMS and an SEO plugin are both injecting markup, disable one source and consolidate.
5. Verify content visibility. Manually check that every piece of data described in the markup is visible to a user reading the page — not hidden behind a tab, accordion, or JavaScript trigger that Googlebot may not execute.
6. Request reindexing after fixes. Use the URL Inspection tool to submit the corrected page for recrawling. Rich results typically reappear within days once Googlebot processes the updated markup, though in competitive crawl queues it can take longer.

If Search Console shows no errors but the rich result still isn't appearing, the likely cause is a quality-based suppression rather than a markup error. In that case, the fix sits at the content level — not the schema level.

Fixing broken schema after the fact is slower and more disruptive than catching errors before deployment. The gap between implementation and detection in Search Console — often several days to weeks — means a mistake can suppress rich results through an entire traffic cycle before anyone notices.

Build Validation Into Your Workflow

The most effective prevention step is making schema validation a non-optional part of the publishing process, not a post-launch check. This means running structured data through the Rich Results Test before a page goes live, not after.

For development teams, integrating schema validation into CI/CD pipelines catches regressions automatically — particularly useful when CMS template updates or plugin changes could silently modify injected markup across thousands of pages.

Maintain a Schema Inventory

Sites with multiple contributors, multiple plugins, or frequent template changes benefit from a documented inventory of which schema types are deployed, which pages they appear on, and which plugin or code source is responsible for generating them. Without this, conflicting markup from multiple sources is nearly inevitable at scale.

Monitor Search Console Enhancements Proactively

Setting up Search Console email alerts for new Enhancements errors means issues surface within days rather than weeks. Many teams only check this report when they notice a traffic drop — by which point the rich result has been gone long enough to affect click-through rates.

Use Tools That Surface Eligibility Issues, Not Just Syntax Errors

Syntax validators confirm your JSON is well-formed. They don't tell you whether your Product schema is missing the Offer property required for price display, or whether your Article markup is on a page with a thin content score that suppresses features. Structured data validation tools reviewed for this cluster go beyond syntax checking — they cross-reference your markup against Google's current feature documentation and flag eligibility gaps before they become lost rich results.