S SCHEMA.BIZ

Last updated:

Schema Markup Validator

Paste your JSON-LD structured data to validate it against schema.org and Google's rich result requirements. Get detailed error explanations and fix suggestions.

Paste your JSON-LD structured data below. You can include the <script> wrapper or just the JSON.

Supports JSON-LD (with or without <script> tags)

What this tool does

Rich results — the star ratings, FAQ accordions, recipe cards, and product snippets that take up half the SERP for any commercial query — depend on structured data that Google can parse without complaining. The feedback loop for getting that markup right is uncomfortably slow if you discover the problem after deployment: Google's crawler has to revisit the page, the indexing pipeline has to re-evaluate eligibility, and your competitors keep their richer SERP presence in the meantime. This validator collapses that loop into the few hundred milliseconds between paste and result.

Three layers of checks run on every paste. JSON syntax validation catches the trailing commas and unquoted keys that prevent the schema from parsing at all. Schema.org compliance verifies that the @type is real, the properties are valid for that type, and the values match the expected ranges. Google's rich result requirements — which are stricter than schema.org's baseline — flag what is missing for each rich result family the schema could qualify for. Every check runs locally against your browser's bytes; no schema, however unreleased, leaves your machine.

When to use the Schema Markup Validator

Pre-deploy QA on a new page template. A new template that emits structured data should not ship until the markup it produces validates clean. Render a representative page locally, copy the rendered JSON-LD, paste, and verify before merging the PR.

Debugging why a page is not getting the rich result you expected. The structured data is on the page, the page is indexed, the rich result never shows up. Paste the markup into the validator and the eligibility panel will tell you exactly which required field is missing or which value type is wrong.

Reviewing markup an agency or client handed you. External markup is rarely well-aligned with current Google guidance. Validate it against the rich-result family it claims to qualify for, and the gaps between "valid schema.org" and "actually eligible for the rich result" become explicit.

Sanity-checking competitor markup you saw with a third-party SEO tool. Reverse-engineering competitor markup is a reasonable way to see what types they target. Pasting their markup into the validator tells you whether their implementation is well-formed (worth copying patterns from) or sloppy (do not).

Walkthrough with a real example

Paste this Article markup, which has the kind of mistakes that show up in nearly every audit: 

{
  "@context": "http://schema.org",
  "@type": "Article",
  "headline": "Why we rebuilt our checkout flow",
  "datePublished": "March 14, 2026",
  "author": "Sam Patel",
  "publisher": {
    "name": "Example Co",
    "logo": "/static/logo.png"
  }
}

The validator flags five distinct problems. The @context uses HTTP rather than HTTPS — Google still understands it, but the canonical schema.org URL has been HTTPS for years and modern guidance is unambiguous. The datePublished is in a human-readable format ("March 14, 2026") instead of ISO 8601, which schema.org requires. The author is a bare string, which technically validates against the schema.org range (Person OR Organization OR Text) but disqualifies the article from Google's rich result, which requires a Person or Organization object with a name property. The publisher is missing its @type, leaving Google to guess, and its logo is a relative URL inside a string instead of an ImageObject with absolute url and dimensions. And the schema is missing image entirely, which is a strict requirement for any Article-family rich result.

Apply the suggested fixes — the validator's "Fix" panel produces these as a copyable diff — and the schema becomes: 

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Why we rebuilt our checkout flow",
  "image": [
    "https://example.com/posts/checkout-rebuild-1x1.jpg",
    "https://example.com/posts/checkout-rebuild-4x3.jpg",
    "https://example.com/posts/checkout-rebuild-16x9.jpg"
  ],
  "datePublished": "2026-03-14T09:00:00-04:00",
  "dateModified": "2026-03-15T14:22:00-04:00",
  "author": {
    "@type": "Person",
    "name": "Sam Patel",
    "url": "https://example.com/team/sam-patel"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Co",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/static/logo.png",
      "width": 600,
      "height": 60
    }
  }
}

Re-validate and the eligibility panel flips to green for Article rich results. Notice what changed beyond the obvious: @context is HTTPS; dates are full ISO 8601 with timezone; author is a Person object with a name and a profile URL (the URL is what feeds Google's entity graph); publisher is a properly typed Organization with a logo that is itself an ImageObject with explicit dimensions; and the article now has three image aspect ratios provided as an array, which is the pattern Google recommends so the rich result template can pick the right ratio for the surface where it renders.

Schema.org and rich results concepts you should know

The schema.org type tree. Schema.org is hierarchical. At the root is Thing; everything else descends from it. CreativeWork is a child of Thing, Article is a child of CreativeWork, NewsArticle is a child of Article. Each level adds properties; a NewsArticle inherits everything from Article, which inherits from CreativeWork, which inherits from Thing. Use the most specific type that fits the content; Google uses type specificity as a relevance signal.

JSON-LD, @context, and @type. JSON-LD is JSON for Linked Data. The @context property declares the vocabulary in use (https://schema.org for everything in this domain). The @type declares which schema.org type the object instantiates. Anything else is a property defined on that type. The @id property gives the resource a stable identifier across pages and sites — useful for entity linking but not required.

Required versus recommended versus optional properties. Schema.org marks no properties as strictly required at the spec level, but Google's rich result documentation declares specific properties as required, recommended, or optional for each rich result type. The validator surfaces the Google-side requirement separately from the schema.org definition, because passing schema.org validation while failing Google's eligibility check is the most common confusion among first-time implementers.

The pipeline from markup to rich result. Googlebot crawls the page and extracts the JSON-LD. The indexing pipeline evaluates eligibility against the rich result rules for each detected type. Eligible pages enter the candidate pool for that rich result. The ranker decides whether to actually display the rich result on a given query, weighing eligibility against page authority, query relevance, and a hundred other signals. Eligibility is necessary, not sufficient — a perfectly valid Article schema on a page with weak signals will not produce the rich result.

Multiple schemas on one page. A typical page hosts several schemas at once: an Article (or Product, Recipe, etc.), a BreadcrumbList for navigation, an Organization for the publisher, a WebSite with SearchAction for sitelinks search box. They can be separate <script type="application/ld+json"> blocks or a single block with an @graph array. Both are valid; the @graph form is easier to keep in sync because cross-references between objects (publisher, author, mainEntityOfPage) can use @id within the same document.

Why URL identity matters. Properties like url, sameAs, and @id are how schema.org connects entities across pages and sites. An Author Person with a stable url property is recognizable as the same author across every article they write; an Organization with sameAs entries pointing to its Wikidata, LinkedIn, and Crunchbase pages is recognizable as the same entity in Google's Knowledge Graph. The validator does not fetch these URLs but flags when they are missing or use relative paths.

Common mistakes

Using HTTP for the @context URL. "@context": "http://schema.org" still parses but is the deprecated form. Always use "https://schema.org". The same applies to enum values like availability on Product offers — use the full HTTPS URL form (https://schema.org/InStock) rather than the bare token.

Author as a bare string. Schema.org allows it; Google's rich result rules do not. Always wrap authors in a Person object with at minimum a name, and ideally a url pointing at an author profile page that exists.

Date formats other than ISO 8601. Schema.org dates are strict. 2026-03-14 for date-only, 2026-03-14T09:00:00-04:00 with timezone for date-time. "March 14, 2026" or "14/03/2026" are rejected silently — they validate as a string but disqualify the rich result.

Product price without currency or availability. A Product schema with an offers object needs all three of price, priceCurrency (an ISO 4217 code), and an availability URL to be eligible for the merchant listing rich result. The shape that works: 

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aurora Field Notebook",
  "image": "https://example.com/notebook.jpg",
  "offers": {
    "@type": "Offer",
    "price": "24.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/aurora-notebook"
  }
}

Logo as a string instead of an ImageObject. Organization logos used inside publisher must be ImageObject instances with absolute URLs and ideally explicit width and height — Google has documented size requirements (under 600x60 with a transparent background works on every surface). A relative path or a bare string fails the rich result eligibility check even when the schema parses.

FAQ

Does this validator give the same verdict as Google's Rich Results Test?

For the schema types Google supports for rich results, the eligibility verdict matches in almost all cases — both check the same required and recommended properties. Differences usually come from the validator catching schema.org-level issues that Google ignores (an unrecognized property, for example) or from Google's tool deferring to live page rendering, which the validator does not do. Use both, and treat Google's tool as the final word for rich-result eligibility.

Can it validate Microdata and RDFa, or only JSON-LD?

JSON-LD is the primary input. If you paste full HTML containing JSON-LD blocks, every block is extracted and validated. Microdata (itemscope/itemprop) and RDFa (vocab/typeof) on the same page are detected and surfaced as "present" so you know which formats coexist, but the structured validation rules run only against JSON-LD — that is the format Google recommends for new implementations.

Does the validator check for AI search readiness in addition to Google rich results?

Schema-level validation focuses on the schema.org spec and Google's rich result rules. AI search readiness — entity clarity, citation signals, freshness, sameAs density — is a separate scoring dimension covered by the AI Search Optimizer. Use the validator to confirm the schema is well-formed, then run it through the optimizer to see how it scores for AI engines.

Can I validate multiple JSON-LD blocks from a single page at the same time?

Yes. Paste either an HTML page that contains multiple <script type="application/ld+json"> blocks, or a JSON array of schemas, or several @graph entries inside one document. Each schema is validated independently and the results panel groups errors by block, so you can find which one is the source of a particular issue.

Does it check that BreadcrumbList items match the URL hierarchy?

The validator confirms the BreadcrumbList structure (items array, position numbering, item URLs) and flags duplicated positions, missing names, and items that point at non-resolvable URLs. It does not crawl your site to confirm the breadcrumb URLs actually exist — that is a job for a crawler — but the structural checks catch the mistakes that produce broken breadcrumbs in the SERP.

Related tools and guides

  • JSON-LD Generator — the cleanest way to produce valid markup is to generate it from a form rather than hand-write it. The generator emits markup that passes this validator on the first try.
  • Schema Audit — validates every schema on a page in one pass and surfaces missing schema types you should also add. Use this for site-wide markup health checks.
  • AI Search Optimizer — once a schema validates, run it through the optimizer to see how well it communicates entity clarity, freshness, and citation signals to AI search engines.
  • Schema Markup Beginner's Guide — the conceptual foundation: what structured data is, how Google uses it, and which types matter most for which content.
  • Structured Data for AI Search — the new layer of optimization on top of traditional rich-result eligibility, covering how AI engines interpret your markup.