Schema validator for JSON-LD, Microdata and RDFa

What does a schema validator check?

Structured data is markup that describes a page to machines: a product with a price, an article with an author, a business with an address. A schema validator parses that markup and checks it against schema.org and, for the types Google supports, against Google’s requirements.

For every item on the page, this tool shows the format, the errors and warnings with the property path (for example Product.offers.price), an eligibility note and the full property tree. Errors block eligibility: a required property is missing, a required value is invalid or the syntax is broken. Warnings point to recommended properties and optional values that look wrong.

Which structured data formats does Google support?

Google supports JSON-LD, Microdata and RDFa and recommends JSON-LD. All three are fine if the markup is valid. JSON-LD sits in its own <script type="application/ld+json"> block, while Microdata and RDFa add attributes to the visible HTML elements.

How do you validate schema markup?

1. 1

   Choose what to test

   Pick “Test a URL” for a live page, or “Paste code” for JSON-LD or an HTML snippet that is not published yet.

2. 2

   Run the validation

   Enter the page address or paste the code and press Validate. A page is fetched without running JavaScript, and the result appears in a few seconds.

3. 3

   Fix the errors first

   Read the property path and the message of each error, then correct the markup at its source. Groups with errors come first, and warnings follow the errors.

4. 4

   Read the eligibility note

   Each type says whether it can qualify for a Google rich result. Google has discontinued some, such as FAQ, how-to and the sitelinks search box, and the tool says so when it finds them. Google’s structured data gallery lists what it supports today.

5. 5

   Validate again

   Run the check after every fix, then confirm important pages in Google’s Rich Results Test.

What does valid JSON-LD look like?

This Product markup passes with no errors and no warnings. It is the example that the Load example button inserts. Place the JSON in a <script type="application/ld+json"> tag in the HTML of the product page.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "image": [
    "https://example.com/images/aero-42.jpg"
  ],
  "description": "A light trail running shoe with a grippy outsole and a breathable mesh upper.",
  "sku": "AERO-42",
  "brand": {
    "@type": "Brand",
    "name": "Aero"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/aero-42",
    "price": "89.90",
    "priceCurrency": "EUR",
    "priceValidUntil": "2027-12-31",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": 128
  }
}

In Serpel’s rules a Product needs a name and at least one of offers, review or aggregateRating. A brand, an image, a product identifier and the offer details are recommended.

Schema markup validator or Rich Results Test?

Google retired its Structured Data Testing Tool in favour of two tools. The Rich Results Test shows whether a page is eligible for Google’s rich results. The Schema Markup Validator checks schema.org markup in general and is not specific to Google features.

What are common schema markup errors?

Each example below shows the markup that fails and the fixed version.

Missing required property

A Product without a name fails with an error at Product.name. Add the property.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "image": "https://example.com/images/aero-42.jpg",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "image": "https://example.com/images/aero-42.jpg",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

Price as text with a currency symbol

The validator expects a plain number with a period as the decimal separator. Put the currency in priceCurrency as a three-letter ISO 4217 code.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "offers": {
    "@type": "Offer",
    "price": "€89,90",
    "priceCurrency": "EUR"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

Relative URL

Values such as image and url need a full URL that starts with https://, not a path.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "image": "/images/aero-42.jpg",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "image": "https://example.com/images/aero-42.jpg",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

Wrong date format

Dates use the ISO 8601 format described for Date on schema.org, such as 2026-10-10. A date like 10/10/2026 is flagged.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose trail running shoes",
  "datePublished": "10/10/2026",
  "author": {
    "@type": "Person",
    "name": "Alex Example"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose trail running shoes",
  "datePublished": "2026-10-10",
  "author": {
    "@type": "Person",
    "name": "Alex Example"
  }
}

Missing @context

Without "@context": "https://schema.org" the keys are not schema.org properties, so the validator reports an error at @context. The JSON-LD specification defines how a context maps keys to vocabulary terms.

{
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR"
  }
}

Trailing comma

JSON allows neither trailing commas nor comments (RFC 8259). One stray comma makes the whole block unreadable, and the validator reports a syntax error. Serpel’s site audit flags JSON-LD with syntax errors on every page it crawls.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "sku": "AERO-42",
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aero 42 trail running shoe",
  "sku": "AERO-42"
}

Does valid markup guarantee a rich result?

No. Google says valid markup does not guarantee a rich result, and a page is eligible only if the required properties are present. The markup must also match what visitors see. Google’s structured data policies ask you not to mark up content that is hidden from readers, to make the markup a true representation of the page and not to block pages with structured data from Googlebot.

What does this schema validator not do?

• It does not run JavaScript. It reads static HTML, so markup that a script adds after the page loads is not seen. Paste the rendered code into the “Paste code” tab instead, and read the JavaScript SEO guide for the background.
• It reads a limited page. It follows at most 5 redirects and reads the first 3 MB of a page.
• It cannot tell whether Google shows a rich result. Eligible here means the markup passes Serpel’s rules, not that Google will display it.
• It checks only the types Serpel has rules for. Every other schema.org type gets a syntax check only.
• It cannot compare the markup with your page. You have to make sure that it matches the visible content.

If you build with Next.js, the Next.js SEO guide shows how to add JSON-LD to a page safely.