Schema Validator

What it does

The Schema Validator is part of the SEO Suite. It parses pasted JSON-LD or full page HTML, extracts every <script type="application/ld+json"> block, and validates each against schema.org’s required and recommended field specifications per @type. The output is a per-block report showing which required fields are present and which are missing, plus the recommended-field coverage that affects rich-result eligibility on Google.

Common situations

You have just written or generated schema for a new article and want to verify it is structurally complete before deploying. The validator catches the missing-field errors that Google’s Rich Results Test will also catch, but instantly, without round-tripping through Google’s tester, and without disclosing the URL.

A schema block is in production but the page is not getting rich-result treatment in search. Paste the live page’s HTML, validate the schema, and identify the missing required field that’s keeping the page from eligibility. Most rich-result failures trace to one specific field being absent.

You are auditing a competitor’s structured data implementation to understand how they have configured their schema. Paste their page HTML, see every schema block they declare, the types they use, and the field coverage. Useful for understanding why a particular SERP feature is appearing for them but not for you.

A migration or CMS upgrade has changed your site’s schema output and you want to confirm the new format still validates. Paste a representative page’s HTML, check the schema blocks are intact and complete. This catches template-level breakage faster than waiting for Search Console to surface it.

You are reviewing schema someone else has written and need to spot-check the structure. The validator is faster than reading the JSON-LD by eye and spotting missing fields manually.

What you need to know

Schema.org defines a vocabulary of types (Article, Product, Organization, etc.), each with a set of properties. Every property is technically optional in pure schema.org terms. Google overlays its own required-field rules on top of the schema.org spec for rich-result eligibility, so a property that is “recommended” by schema.org might be “required” by Google for the page to qualify for a specific SERP feature.

The validator covers the most-used types and applies both schema.org’s structural rules and Google’s stricter requirements:

Article (and BlogPosting, NewsArticle): required headline; recommended author, datePublished, image, publisher. Google requires image for Article rich results in practice, so the validator flags it as required even though schema.org does not.

Product: required name; recommended image, description, sku, brand, offers (with priceCurrency, price, availability), aggregateRating, review. For Google’s product rich results (price snippets, ratings stars), the offer fields and rating fields are effectively required.

Organization: required name; recommended url, logo, sameAs, contactPoint. Organization schema does not award its own rich result but is foundational for entity identification.

LocalBusiness: required name and address; recommended telephone, url, openingHours, priceRange, geo. Address must be a PostalAddress sub-object, not a free-text string. This is a common mistake.

FAQPage: required mainEntity containing one or more Question items, each with acceptedAnswer containing an Answer with text. Missing the nested structure is the typical failure mode.

Event: required name, startDate, location. Dates must be ISO 8601. Location should be a Place sub-object.

Recipe: required name. Many fields are recommended; for Google’s recipe rich results, image, recipeIngredient, recipeInstructions, and aggregateRating are effectively required.

HowTo: required name and step. Each step should be a HowToStep with at least a text field.

BreadcrumbList: required itemListElement, an array of ListItem objects each with position, name, and item (URL).

VideoObject: required name, description, thumbnailUrl, uploadDate. Used for video rich snippets.

The validator reports both the schema.org-required fields (must be present for the schema to be structurally valid) and the recommended fields (boost rich-result eligibility but are not blocking). For types not in the validator’s coverage, it reports the type and lists the fields present but does not check field-level requirements.

Frequently asked questions

Is this a substitute for Google’s Rich Results Test?

No, they complement each other. This validator checks structural completeness fast, without disclosing the URL. Google’s Rich Results Test runs the actual rendering pipeline Google uses to decide rich-result eligibility. Use this for fast iteration during development; use Rich Results Test for the final eligibility check before shipping.

What schema types does the validator support?

Article, NewsArticle, BlogPosting, Product, Organization, LocalBusiness, FAQPage, Recipe, Event, HowTo, BreadcrumbList, VideoObject. Other types parse correctly but field-level validation is not performed: the validator reports the type and the fields present.

What does “missing required” mean?

The schema is missing a field that schema.org or Google declares required for that type. Pages with missing required fields are ineligible for the rich-result treatment associated with that schema type.

What about “recommended” fields?

Recommended fields are not blocking for rich-result eligibility but increase the chance of richer presentation. An Article with image is more likely to get a thumbnail in the SERP than one without; a Product with aggregateRating shows stars where one without does not.

Will valid schema make my page rank higher?

Not directly. Schema is not a ranking signal. But pages with valid, complete schema get richer SERP treatments which improve click-through, which is loosely correlated with ranking signals. The direct ranking impact is zero; the indirect CTR benefit is real and measurable.

What if my schema uses @graph?

The validator handles @graph correctly. It flattens the graph into individual schema blocks and validates each one separately. A page with a single @graph containing an Organization, BreadcrumbList, and Article gets validated as three independent blocks.

Why does the validator fail on schema my CMS produced?

Common causes: the CMS is outputting an older schema vocabulary, missing newer required fields, using wrong nesting for sub-objects (address as a string instead of a PostalAddress), or omitting fields that have become required since the CMS plugin was last updated. Update the CMS or its SEO plugin.

Does the validator check that referenced URLs are valid?

It checks that fields containing URLs (image, url, logo, etc.) are present, but does not fetch them to verify they return 200. A schema can validate cleanly while pointing at a 404 image. Verify externally if it matters.

Common problems

Problem: Validator says required fields are present but Google’s Rich Results Test says they’re missing.

Google’s tester applies stricter rules than schema.org for some types. The fields the validator marks “recommended” may be required by Google specifically. If Rich Results Test reports a missing field that the validator says is present, supply it anyway. Google’s eligibility decision is what matters for SERP appearance.

Problem: Schema parses with no errors but the page has no rich result.

Eligibility is not the same as awarding. Pages with valid schema can still fail to receive rich-result treatment if Google decides the page is low quality, the topic is highly competitive, or the SERP for that query is already dense with rich results. Schema validates eligibility; SERP appearance is Google’s call.

Problem: Multiple schema blocks but the validator only shows one.

The page is using @graph to combine multiple types in a single block. The validator flattens the graph and reports each type separately. Check that the block count in the report matches your expectation.

Problem: The validator reports “no schema found” but JSON-LD is present.

Either the JSON-LD is malformed (parse error) or the script tag is using a non-standard type attribute (must be application/ld+json exactly; typos like application/json+ld or text/json-ld are not parsed). The validator prefers strict matching over loose detection to avoid false positives.

Problem: Validator reports unexpected error on hand-written schema.

Most common: trailing commas (valid in JavaScript, invalid in JSON), single quotes (must be double), unescaped double quotes inside string values. The JSON-LD parser is a strict JSON parser; small syntax mistakes that work in JavaScript do not work here.

Tips

• Validate during development, before deployment. The fastest debug loop is local validation; Rich Results Test is for the final pre-launch check.
• The recommended fields are not optional in any practical sense for rich-result performance. Treat them as required; the schema.org “recommended” label is a polite suggestion that practical SEO ignores.
• When generating schema with the JSON-LD Schema Generator, paste the output back into this validator before deploying. Catches edits and copy errors.
• Use @graph to keep multiple types in one block. It’s cleaner than three separate script tags and the validator handles both equally well.
• When debugging a missing rich result, validate then run Rich Results Test. If both pass and the rich result still doesn’t appear, the issue is page quality or query competition, not schema.

Related tools in this suite

The natural pairing is the JSON-LD Schema Generator: generate schema, validate it here, ship. The Page SEO Audit reports the schema types found on a fetched URL, useful for spot-checking what is currently being served.

What this looks like at scale

For a small site, validating schema page by page during development is fine. For a content site with thousands of pages emitting schema from templates, the validator should be part of CI. Every template change should run the schema for representative pages through the validator before deploy. Schema regressions caught at deploy are cheap; schema regressions caught by a Search Console alert two weeks later are expensive. The WP Beacon Plugin monitors schema presence and type consistency across every page on an ongoing basis, surfacing regressions without waiting for a deploy cycle.

Take it further

If your site’s schema implementation is inconsistent across templates or content types, the right scope is a one-off audit of every page type’s schema output. Start a conversation about what schema audit and remediation looks like.