In the audits I run, certain schema markup errors show up across almost every site I review, regardless of industry or CMS. The good news is that most of them are fixable in an afternoon once you know what to look for. The problem is that many of these errors are invisible: the page looks fine, the HTML is valid, but the structured data is quietly failing Google’s parser, and you are losing rich result eligibility you did not know you had earned.

This guide covers the errors I find most consistently, how to catch them with the Rich Results Test and Schema Markup Validator, and the fixes that resolve each pattern. Schema is not a direct ranking factor — but rich result eligibility, entity clarity, and AI Overview signals all depend on clean structured data. Getting these errors fixed is worth the time.

How to Find Schema Markup Errors: Two Essential Tools

Before going through the error types, the tools. You need both of these in your QA process.

Google Rich Results Test (search.google.com/test/rich-results): Paste a URL or code snippet to see whether your markup qualifies for enhanced search features. It reports errors, warnings, and detected items by type. This is the authoritative source for Google-specific rich result eligibility — if this tool shows an error, that schema type will not produce a rich result.

Schema Markup Validator (validator.schema.org): Tests against the Schema.org specification rather than Google’s rich result requirements. It catches type compatibility issues, property value format problems, and deprecated properties that the Rich Results Test does not flag. Run both — they surface different layers of the same structured data.

For finding duplicate blocks and JSON syntax errors, I also use the browser’s View Source directly. Search the raw HTML for application/ld+json to see exactly how many blocks are present and what each one contains. This catches conflicts that neither tool above will flag because both tools parse each block independently.

Missing Required Properties

Every schema type has required properties defined in Google’s rich result documentation, and missing even one can disqualify the entire block from generating a rich result. The Rich Results Test will flag these explicitly, but only if you run it — sites often go months without checking after the initial implementation.

The most common missing-property patterns I find:

  • Product schema without name, image, or offers (all required for the Product rich result)
  • Review schema without reviewRating and author
  • FAQPage with Question entities that lack an acceptedAnswer
  • LocalBusiness without address or telephone
  • Article without headline, author, or datePublished

The fix: cross-reference Google’s documentation for each type you are using (developers.google.com/search/docs/appearance/structured-data) and confirm every required field is populated with real, non-empty content. Recommended properties should be treated as required wherever the data exists.

<script type='application/ld+json'>
{
  '@context': 'https://schema.org',
  '@type': 'FAQPage',
  'mainEntity': [
    {
      '@type': 'Question',
      'name': 'What is schema markup?',
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': 'Schema markup is structured data added to a web page that helps search engines understand the content and qualify it for rich results.'
      }
    },
    {
      '@type': 'Question',
      'name': 'Does schema markup improve rankings?',
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': 'Schema markup is not a direct ranking factor, but it can improve click-through rates by qualifying pages for rich results and helps Google understand entity relationships.'
      }
    }
  ]
}
</script>

Mismatched Schema and Visible Content

Google’s guidelines require that schema content be accessible to users on the page. Marking up a 4.9 star rating when no visible review content exists, or including an event date in schema that does not appear anywhere on the page, violates the spam policies and can result in rich result suppression or a manual action.

I have seen sites lose rich results entirely because a developer copied schema from a template and forgot to update the hardcoded values. A LocalBusiness block with a phone number from the original template site, or a Product block with a price that was correct eighteen months ago and never updated — both are mismatches. Always verify that schema values reflect what users actually see on the page at the time they visit it.

The fix: audit schema output against the visible page for every key template. Pay particular attention to review ratings, prices, dates, and phone numbers — these are the fields most likely to drift out of sync with the content.

Duplicate and Conflicting Schema Blocks

WordPress sites are particularly prone to this schema markup error pattern. Yoast generates an Organization block. A theme adds another. A schema plugin drops a third. Google receives three conflicting Organization entities and has to guess which one to trust — or ignores all of them.

A simple search for application/ld+json in the page source will show you how many blocks are present. On a typical WordPress site that has had multiple SEO plugins installed over time, I regularly find three to five blocks, often with conflicting property values for the same entity.

The fix: audit all active plugins and the active theme for schema output. Disable schema generation in every source except one authoritative source. If you are using Yoast as your primary schema source, disable schema output in Rank Math, your theme, and any other plugins that inject their own blocks. Then validate the consolidated output with the Rich Results Test. For the structural approach to avoid this, see schema markup best practices on the @graph pattern.

Incorrect @type Values

Schema.org has a strict type hierarchy, and using the wrong type produces errors or reduces the precision of the signal you are sending. Common mistakes:

  • Using Organization for a sole proprietor who should use Person
  • Using Product for a service offering (use Service instead)
  • Using Article when the content is a BlogPosting, NewsArticle, or TechArticle
  • Using a parent type like LocalBusiness when a specific subtype (Dentist, LegalService, Restaurant) is available
  • Using Review for an aggregate rating (use AggregateRating)

The fix: check Schema.org for the full type hierarchy before choosing a type. The most specific type that accurately describes the content is always the right choice. Specificity is free and gives Google finer-grained signals about your entity.

JSON Syntax Errors

A single trailing comma, an unescaped character, or a mismatched brace will cause the entire JSON-LD block to fail silently. The page renders fine, but the structured data produces no output. This is the schema markup error type that is easiest to miss because there is no visible symptom.

Common culprits in dynamically generated schema: apostrophes in business names (O’Brien’s Plumbing) that break JSON string delimiters; ampersands in category names (Health & Wellness); em-dashes from CMS auto-formatting; and trailing commas after the last property in an object (valid in JavaScript, invalid in JSON).

The fix: paste any schema block into JSONLint (jsonlint.com) before deploying to production. If you are generating schema dynamically from a CMS, test with real data that includes special characters. The Rich Results Test will also surface JSON parse errors, but catching them in JSONLint before pushing live prevents the gap in coverage while you wait for Google to re-crawl.

Deprecated Properties and Outdated Patterns

Schema.org deprecates properties over time, and Google’s requirements for rich results change. Properties that were recommended in 2020 may now be deprecated, replaced by a more precise equivalent, or simply no longer relevant to rich result eligibility. The Schema Markup Validator at validator.schema.org flags deprecated properties that the Rich Results Test does not — run both tools regularly.

Common outdated patterns I find in older implementations: using aggregateRating inside a LocalBusiness block without a corresponding visible review count; using priceRange as the sole price indicator on Product schema (Offer is required); and using description where Google now expects text for certain answer types. For a full audit of what you have and what needs updating, see how to test schema markup.

What to Do After You Fix Schema Markup Errors

After fixing errors, validate the updated output in both the Rich Results Test and the Schema Markup Validator. Then request indexing for the affected URLs in Google Search Console using the Inspect URL tool — this speeds up reprocessing rather than waiting for the next crawl. Monitor the Enhancements section of Search Console over the following two to three weeks to confirm the errors have cleared and valid items are increasing.

Schema errors tend to recur without a maintenance process. CMS updates, plugin changes, and template edits all introduce new breakage. I recommend a quarterly audit cycle as the baseline — see schema markup best practices for the full process. For a systematic review of your site’s structured data health from the ground up, a schema audit or ongoing schema markup consulting will surface these issues across every page template before they cost you rich result eligibility. You can also start with the mechanics and learn how to add schema markup correctly from the beginning.