How to Fix Common Schema Markup Validation Errors

When you run a page through Google's Rich Results Test and it comes back with errors, the natural reaction is to assume something is badly broken. Usually it isn't. Most validation errors fall into a short list of predictable categories — wrong date format, missing required field, mismatched type — and they all have straightforward fixes.

This guide covers the most common errors you'll encounter when working with schema markup, what they actually mean, and exactly how to resolve them.

Errors vs. warnings: the difference matters

The Rich Results Test reports two severity levels:

Errors prevent rich results entirely. If a required field is missing or a value has the wrong type, Google will not generate the rich result for that schema item. Fix errors first.

Warnings reduce eligibility or demote the quality of the rich result. A page with only warnings can still get rich results, but may lose certain features (like the video duration chip or the review star rating). Fix warnings after errors are resolved.

The distinction is visible in the test UI — errors appear with a red indicator, warnings with yellow.

The 10 most common validation errors

1. "Missing field 'X'" (required field)

What it means: A property that Google requires for a given rich result type is absent from your JSON-LD.

Which fields are required depends on the schema type. For FAQPage, Google requires at least one Question with an acceptedAnswer. For VideoObject, name, description, thumbnailUrl, and uploadDate are required. For Article/BlogPosting, headline, image, datePublished, and author are required.

Fix: Add the missing field. Google publishes required fields for each rich result type in its Search Central documentation. Cross-reference there rather than schema.org, because Google's requirements are stricter than the spec.

2. "Invalid date format"

What it means: A date value doesn't conform to ISO 8601.

Common mistakes:

• November 14, 2025 — natural language, not valid
• 11/14/2025 — US date format, not valid
• 2025-11-14T — incomplete datetime, not valid

Valid formats:

• 2025-11-14 — date only (acceptable for datePublished, uploadDate)
• 2025-11-14T09:00:00+00:00 — full datetime with timezone offset
• 2025-11-14T09:00:00Z — UTC datetime

Fix: Convert all date values to YYYY-MM-DD or full ISO 8601 datetime format. If your CMS outputs dates in a different format, fix the template that generates the schema rather than the individual page.

3. "Invalid URL"

What it means: A property that expects a URL contains something that isn't a valid absolute URL.

Common causes:

• A relative path (/logo.png instead of https://example.com/logo.png)
• A URL with spaces or unencoded characters
• An empty string where a URL should be
• A URL that starts with http:// where the field expects https:// (less common, but some validators flag this)

Fix: Ensure all URL properties use fully qualified absolute URLs starting with https://. Use encodeURIComponent() or your framework's URL utility for any dynamic values.

4. "Item 'X' is missing required field 'Y'" (nested item)

What it means: An object nested inside your schema is missing a required property. This is different from a top-level missing field — it refers to a property inside a nested @type.

Example: Your author property contains {"@type": "Person"} but no name. Google requires author.name for Article schema.

// Wrong
"author": {
  "@type": "Person"
}

// Correct
"author": {
  "@type": "Person",
  "name": "Jane Doe"
}

Fix: Look at the nested object the error references and add the missing property to that object, not to the top-level schema.

5. "Type mismatch"

What it means: A property received a value of the wrong data type. Schema.org properties are typed — some expect a Text, some expect a URL, some expect a Number, some expect an ImageObject.

Common examples:

• Passing a string where an ImageObject is expected
• Passing a number as a string: "duration": "4" instead of using ISO 8601 ("duration": "PT4M")
• Passing an array where a single value is expected (or vice versa)

Fix: Check the schema.org documentation for the property type. The most frequent case is image: Google expects either a URL string or an ImageObject. Both are valid, but you can't pass an integer or an unformatted path.

6. "Duplicate IDs"

What it means: Two schema items on the same page share the same @id value. The @id property is used to link schema entities together (e.g., connecting an Article to its author entity). If two items share the same @id, Google can't determine which one the reference points to.

Fix: Each entity should have a unique @id. Convention is to use the canonical URL of the entity:

• For a webpage: https://example.com/my-page/
• For an organization: https://example.com/#organization
• For a person/author: https://example.com/#jane-doe

7. "The value of field 'X' must be one of [list]"

What it means: The property only accepts values from a defined enum. You've passed a string that's not in the allowed set.

Common examples:

• itemListOrder: must be ItemListOrderAscending, ItemListOrderDescending, or Unordered
• inLanguage: must be a valid BCP 47 language tag like en or en-US, not English
• Day-of-week fields: must be full day names like Monday, not Mon or 1

Fix: Replace the value with the exact string from the allowed list. Case matters — monday is not the same as Monday.

8. "Missing 'author.name'"

This is a variant of error #4 that deserves its own entry because it's so common with Article and BlogPosting schema. Google requires that author be either a Person or Organization with a name property. A blank author or an author with only a URL fails validation.

// Wrong — no name
"author": {
  "@type": "Person",
  "url": "https://example.com/about"
}

// Correct
"author": {
  "@type": "Person",
  "name": "Jane Doe",
  "url": "https://example.com/about"
}

If you're adding schema to a Shopify blog, see how to add BlogPosting schema to Shopify — this error comes up frequently there because Shopify's default author object needs augmentation.

9. "Invalid value for property 'duration'"

Duration errors almost always come from VideoObject schema. The ISO 8601 duration format is not intuitive.

Wrong:

• "4:30" — video player format, not valid
• "4m30s" — informal, not valid
• "P4M30S" — mixing period and time without the T separator

Correct:

• "PT30S" — 30 seconds
• "PT4M30S" — 4 minutes 30 seconds
• "PT1H4M30S" — 1 hour 4 minutes 30 seconds

The P starts the duration. T separates date components from time components. Since video durations are always in hours/minutes/seconds (time components), they always start with PT.

For more VideoObject-specific guidance, see how to add VideoObject schema for YouTube embeds.

10. "Homepage schema should use sameAs for social profiles"

This is technically a warning, not an error, but it's worth addressing. If your Organization or LocalBusiness schema on the homepage lacks sameAs links, Google can't confidently connect your schema entity to your social profiles, which weakens Knowledge Panel consolidation.

Fix: Add sameAs as an array of all official profile URLs — LinkedIn, Twitter/X, Facebook, Instagram, Crunchbase, Wikipedia (if applicable). For the full decision between Organization and LocalBusiness, see Organization vs LocalBusiness schema for your homepage.

Why "Item missing field X" appears even when the field looks present

This is one of the most frustrating validation results. You have the field. The test says it's missing. Common causes:

Escaping issues. If your schema is generated server-side and a field value contains unescaped quotes or angle brackets, the JSON becomes invalid and the parser may silently skip the malformed property. Run your output through a JSON linter first.

Wrong property name casing. JSON-LD property names are case-sensitive. DatePublished is not the same as datePublished. Always use camelCase as specified in the schema.org documentation.

The value is null or an empty string. Some CMS templates output "image": "" or "image": null when no image is set. Google treats these as missing. Either omit the property entirely when there's no value, or fix the data source.

The property is present on a different @type than the one being tested. If you have two JSON-LD blocks on the page and the error refers to the Article block, check the Article block specifically — not the Organization block that also happens to have an image property.

Rich Results Test vs. Schema Markup Validator: different tools, different jobs

Rich Results Test (search.google.com/test/rich-results) — Checks whether your page's structured data makes it eligible for Google's specific rich result features. Use this when you want to know if your schema will produce a rich result in Google Search. This is the primary tool for SEO purposes.

Schema Markup Validator (validator.schema.org) — Checks conformance to the schema.org specification. Flags issues the spec considers invalid, even if Google doesn't care about them. Use this when you want strict spec compliance or when you're building schema for non-Google contexts (social sharing, voice search, etc.).

The two tools can give different results on the same page. A page might pass the Rich Results Test (Google is happy) but fail the Schema Markup Validator (the spec is stricter). For ranking purposes, the Rich Results Test verdict is what matters.

Monitoring for errors at scale with Search Console

The Rich Results Test works one URL at a time. For ongoing monitoring across your full site, use Google Search Console.

Navigate to Enhancements in the left sidebar. You'll see a report for each rich result type Google has found on your site — Articles, Videos, FAQs, Products, etc. Each report surfaces:

• The number of valid pages
• Pages with warnings
• Pages with errors, grouped by error type
• A list of affected URLs for each error

Search Console is the right tool for finding schema errors introduced by CMS updates or template changes that affect many pages at once. A single template bug can generate hundreds of identical errors — that shows up clearly in the grouped view.

Quick reference: errors vs. fields

Most schema errors come down to the same root cause: the JSON-LD was written by hand or generated by a template that hasn't been updated to match Google's current requirements. Regenerating your schema from a validated template — rather than patching individual fields — is often faster than fixing each error in isolation.