S SCHEMA.BIZ

Last updated:

Schema Markup Validator

Check a page by its URL, or paste JSON-LD or a page's HTML source, to check every block of structured data for syntax errors, unknown types and properties, invalid values and Google rich result eligibility. Results are grouped by block. Every issue comes with an explanation, and a Fix panel copies corrected JSON with the safe fixes applied.

Paste JSON-LD, with or without its <script> wrapper, or a page's HTML source.

Checks every JSON-LD block, Microdata and RDFa item

What this tool does

Rich results — the star ratings, recipe cards, and product snippets that take up so much of the results page for commercial queries — 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 kinds of checks run when you click Validate. First, parsing: every JSON-LD block in pasted HTML is read, along with Microdata and RDFa, and syntax errors are reported with the line and column in the text you pasted, with plain-English explanations for curly quotes and HTML-escaped JSON. Second, schema.org checks: every @type and property is looked up in the schema.org vocabulary, with a suggestion when a name is misspelled, and every value is checked against what its property expects, such as ISO 8601 dates and durations, absolute URLs (every sameAs link included) and values like https://schema.org/InStock. Third, Google's search features: each schema is checked against the required and recommended properties of the Google features that apply to it, and the eligibility panel shows which it's eligible for, which are missing something, and which Google has retired, such as FAQ rich results. Every check runs in your browser; the schema you paste isn't uploaded.

To check a live page, enter its address in the Check a URL tab, or link straight to a check: https://schema.biz/markup/validator/?url=https://example.com/page runs it when opened. Our server fetches the page as SchemaBizBot, following up to 5 redirects and reading up to 5 MB within 10 seconds, and sends its HTML back to your browser, where the same checks run. Above the results you see the address that was fetched, its HTTP status, any redirects, the page's size, how long the fetch took and any X-Robots-Tag header. The fetch doesn't run JavaScript: when a page has no JSON-LD in its HTML but shows signs of adding it with a script, such as Google Tag Manager or a Next.js app, the results say so. Google's Rich Results Test renders JavaScript, and "Also open in Google Rich Results Test" runs it on the same address.

Results are grouped by block, each labelled with its format (JSON-LD, Microdata or RDFa) and its types. Every issue shows its code (such as VALUE_DATE), the property, its line in the text you pasted and, when expanded, its JSON path and a link to Google's documentation. For JSON-LD blocks, the Fix panel applies the fixes that can't change what the markup says: it adds a missing @context or upgrades an http one to https, trims spaces around values, and turns an author given as plain text into a Person. It shows the changes as a diff, and "Copy corrected JSON" copies the result. "Fix in Generator" opens a block's markup in the JSON-LD Generator to fill in the rest.

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: the eligibility panel shows which required property is missing, and the issue list flags values of the wrong kind.

Reviewing markup an agency or client handed you. External markup is rarely well-aligned with current Google guidance. Validate it, and the gaps between "valid JSON-LD" and "has what the rich result needs" 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. Checking their page by its URL 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's header reads "Valid — eligible for Article", because Google's Article markup has no required properties, but the issue list has six warnings and a note. The note: the @context uses HTTP rather than HTTPS; Google still understands it, but the canonical schema.org URL is HTTPS. The warnings: datePublished is a human-readable string ("March 14, 2026") rather than an ISO 8601 date; the publisher has no @type; its logo is a relative URL rather than an absolute one; author is a bare string, which schema.org allows but Google's documentation describes as a Person or Organization object with a name; and image and dateModified, which Google recommends, are missing.

Open the block's Fix panel and "Copy corrected JSON" handles two of them for you: the @context becomes https, and author becomes a Person named Sam Patel. The others need information only you have, such as the real date and the logo's full URL. Fix them too (expand each issue for an explanation) 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": 512,
      "height": 512
    }
  }
}

Re-validate and the issue list is empty, with the Article still eligible. 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 for the site as a whole. 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. The validator checks every block and resolves @id references between them, so paste the whole page source.

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 doesn't fetch these URLs, but it warns when url, sameAs, logo, image or any other URL property isn't an absolute http(s) URL, and it notes an @id reference that doesn't match any object in the markup.

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, but Google documents author as a Person or Organization object. Wrap authors in a Person object with at least 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. Search engines can't read "March 14, 2026" or "14/03/2026" reliably, and the validator flags both, along with dates that don't exist, such as 2026-02-30.

Product price without currency or availability. Merchant listings, Google's shopping results, need an Offer with a price above 0 and a priceCurrency (an ISO 4217 code); availability is recommended. Product snippets need only the price, and 0 is allowed. The shape that works for both: 

{
  "@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 relative path. A logo can be a URL string or an ImageObject with a url, but the URL must be absolute: a relative path such as /static/logo.png can't be resolved reliably, and the validator flags it. Google's Organization documentation asks for a logo of at least 112×112px.

FAQ

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

For the features it checks, it applies the requirements in Google's documentation (checked September 26, 2026): required properties, value formats such as prices and dates, and rules such as breadcrumbs needing two items and events needing a physical address. Retired rich results, such as FAQ, How-to and the sitelinks search box, are reported as retired, never eligible. Google's Rich Results Test reads the rendered page, including markup added by JavaScript, and checks things this tool can't, such as whether images load, so treat it as the final word on eligibility.

Can I check a page by its URL?

Yes. Enter the address in the Check a URL tab, or open a link such as schema.biz/markup/validator/?url=https://example.com/page, which runs the check when it opens. Our server fetches the page as SchemaBizBot, following up to 5 redirects and reading up to 5 MB within 10 seconds, and your browser checks its HTML exactly like pasted source. The results show the address that was fetched, its status, any redirects, its size and how long the fetch took. The fetch doesn't run JavaScript, so markup a script adds after the page loads isn't checked; the results say so when a page shows signs of it, and "Also open in Google Rich Results Test" runs Google's test, which renders JavaScript, on the same address.

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

All three. Paste a page's HTML and the validator reads every JSON-LD block, every Microdata item (itemscope/itemprop) and every RDFa item (vocab/typeof), builds each into a full object with its nested items, and checks it the same way as JSON-LD. JSON-LD 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 the page's HTML and every <script type="application/ld+json"> block is checked, along with any Microdata and RDFa. A JSON array of schemas or an @graph document works too. Results are grouped by block, with each block's format and types. @id references are resolved across blocks, and each issue shows the line it's on in the text you pasted.

Can I share a result, or check it in Google's Rich Results Test?

Yes. After you validate pasted code, the page address holds your input after the #, for inputs up to 32 KB; open that link and the validator runs again. For a page checked by its URL, "Copy a link to this check" gives a ?url= link that runs the check when it's opened. "Test in Google" copies pasted code and opens Google's Rich Results Test: choose its Code tab and paste, because Google's tool doesn't accept code in a link. For a page checked by its URL, it opens Google's test of that address. The Schema.org validator link next to it checks the same code against schema.org alone.

Is the code I paste sent anywhere?

Your code is processed in your browser and never uploaded. When you check a URL instead, the address goes to our server, which fetches the page and sends it back for your browser to check; the page is kept only in a 10-minute cache (see Checking a URL). We record anonymous usage metadata about each check to improve the tools: the schema types, the issue codes and counts found, and the address of the page being checked (the markup's canonical link, og:url, url or @id, or the address of a page checked by URL), without the query string. See the privacy policy for the full list.

Does it check that BreadcrumbList items match the URL hierarchy?

It checks what Google requires of a breadcrumb trail: at least two ListItems, a position and a name for each, no repeated positions, and an item (the URL of that level) on every breadcrumb except the last. It doesn't visit the URLs or compare them with your site's structure; Google's Rich Results Test or a crawler can confirm those.

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. Fill in the recommended fields too, then check the result here.
  • Schema Audit — checks every JSON-LD block in a pasted page in one pass and suggests schema types the page could add. Use it for a page-level markup health check.
  • 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.