Free Schema Markup Validator

How to Use This Tool

1. 1

   Choose Validate URL or Paste Schema Code

   URL mode fetches the page server-side and reads what it really publishes. Paste mode checks markup before it is deployed. Use paste while writing, URL after shipping.

2. 2

   Read the page analysis first

   How many JSON-LD blocks, how many entities, and how many scripts failed to parse. A block that is not valid JSON is skipped entirely by search engines, so that count matters before anything else does.

3. 3

   Clear the errors

   Missing required properties, unparseable JSON, invalid dates, prices carrying currency symbols, wrongly cased type and property names. These stop markup being used at all.

4. 4

   Then work the warnings

   Missing recommended properties will not break anything. They are usually the difference between markup that is merely accepted and markup that is genuinely useful.

5. 5

   Check the extracted JSON

   The tree view shows exactly what was parsed out of the page. It is the fastest way to catch a template writing something you did not expect, and you can copy or download it.

What Schema Markup Is

Schema markup is a vocabulary for labeling what is on a page so machines do not have to guess. A price is marked as a price, a date as a publication date, a person as an author. Without it, a search engine sees a number on a page and has to infer from context whether it is a price, a rating, or a phone number.

The vocabulary is Schema.org, a shared standard maintained collaboratively by Google, Microsoft, Yahoo and Yandex. It defines the types — Article, Product, Organization, Event — and the properties each one can carry. It is not owned by Google, which matters more than it used to: Bing, DuckDuckGo and the AI crawlers all read the same vocabulary.

There are three ways to write it. JSON-LD puts everything in a single script tag, separate from the HTML, and is what Google recommends and what almost all new markup uses. Microdata weaves attributes through the HTML itself. RDFa Lite does something similar and is rarer. This validator reads all three, because plenty of real sites still run the older two — usually because a theme was built that way years ago and nobody revisited it.

JSON-LD wins on maintenance rather than capability. Because it sits apart from the layout, a redesign cannot break it by accident. Microdata is the opposite: the data and the markup are the same thing, so moving an element in a template can silently destroy the structured data with no visible symptom at all.

Schema Validation Is Not JSON Schema Validation

Worth settling early, because these two share a name and solve unrelated problems, and searches for "schema validator" return both.

JSON Schema is a standard for describing the shape of JSON data. It is used to validate API request bodies, configuration files, and message payloads — the kind of thing you reach for in Postman, REST Assured, Python or MongoDB. It has nothing to do with search engines.

Schema.org markup, usually written as JSON-LD, describes the meaning of content on a web page so search engines and AI crawlers understand it. That is what this tool validates.

If you arrived here looking for a way to validate an API payload against a JSON Schema document, this is the wrong tool and no amount of configuring will make it the right one. If you are trying to work out why your product page is not showing a price in search results, you are in the right place.

How This Validator Works

In URL mode, the page is fetched server-side, which means it works on any public URL without a browser extension and without being logged in anywhere. The HTML is parsed, every JSON-LD script is read, and Microdata and RDFa attributes are converted into the same structure so one set of rules can check all three.

Every object carrying an @type is then validated on its own, at any depth. This matters more than it sounds: an Offer nested inside a Product has its own required properties, and a missing price on that Offer is usually the actual reason a price is not appearing. Reporting only the outer Product would hide the failure that matters.

In paste mode, nothing is fetched. Your JSON-LD is parsed and validated directly, a surrounding script tag is stripped if you left one in, and the same rules apply. Nothing is stored.

One limitation stated plainly: markup injected by JavaScript after the page loads is not visible here. That is also what a crawler sees on its first pass, so server-rendered markup is the only kind reliably read. Google's own Schema.org validator does render JavaScript, so if your structured data is script-injected, use that one — and consider moving the markup server-side regardless.

What This Validator Checks

• JSON syntax — whether each block parses at all, with the line and column of the failure. An unparseable block is discarded whole by search engines; nothing inside it is read.
• @context — present on every top-level block, and actually pointing at schema.org. Nested entities correctly inherit it and are not flagged.
• @type — present, a string or array of strings, and a type the vocabulary recognizes.
• Required properties — missing ones are errors, because the type is incomplete without them.
• Recommended properties — missing ones are warnings, because the markup works but does less than it could.
• Value shapes — dates in ISO 8601, prices as bare numbers, URLs absolute rather than relative, numbers that are actually numbers.
• Casing — schema.org names are case sensitive, so "datePublished" works and "datepublished" does not. Reported only when the name matches a known property case-insensitively, which makes it a real mistake rather than a guess.
• Duplicate markup — the same type declared more than once where that is usually accidental. Repeated ListItem or Question entries are normal and are not flagged.
• Empty values — a property present but blank, which is treated as absent and is better removed or filled in.

Required Properties and Recommended Properties

This distinction is the most useful thing a validator can give you, and it is the thing most tools blur by presenting one undifferentiated list of problems.

A required property is one the type is not meaningful without. An Offer with no price is not describing an offer. An Event with no startDate is not describing an event. Search engines will either discard the entity or treat it as incomplete, so these are errors.

A recommended property is one the markup is valid without but weaker for. A Product without an image is valid; it is also much less likely to be presented usefully anywhere. These are warnings.

The tables below show the split for the types that come up most. Properties inherited from a parent type are included, so BlogPosting carries everything Article requires.

• Article and BlogPosting — required: headline. Recommended: image, datePublished, dateModified, author, publisher, mainEntityOfPage.
• Product — required: name. Recommended: image, description, offers, brand, sku, aggregateRating, review.
• Offer — required: price, priceCurrency. Recommended: availability, url, priceValidUntil.
• Organization — required: name. Recommended: url, logo, sameAs, contactPoint, description.
• LocalBusiness — required: name, address. Recommended: telephone, openingHoursSpecification, geo, priceRange, image.
• Event — required: name, startDate, location. Recommended: endDate, description, image, offers, performer, eventStatus, eventAttendanceMode.
• BreadcrumbList — required: itemListElement, with each ListItem needing position and name.
• JobPosting — required: title, description, datePosted, hiringOrganization, jobLocation. Recommended: employmentType, validThrough, baseSalary, identifier.

Schema Validation Versus Google Rich Results

These answer two different questions, and conflating them is where structured data tools most often oversell themselves.

Validation asks whether the markup is correct. Google's Rich Results Test asks whether a page qualifies for one of the specific enhanced result formats Google supports. A page can be perfectly valid and qualify for nothing, and that is not a failure.

Google retired the old Structured Data Testing Tool and handed it to the Schema.org community, where it now runs as the Schema.org validator. What replaced it inside Google is narrower by design. Legitimate markup that is not tied to a supported rich result — Organization details, WebSite declarations, Person markup, Service descriptions — returns nothing at all in the Rich Results Test, which is why a general validator is still worth running.

Valid markup is necessary for a rich result and nowhere near sufficient. Google also weighs the query, the page's quality, whether the markup matches content a visitor can actually see, its own policies for each result type, and its judgment about whether an enhanced result helps the searcher. Almost none of that is visible from outside Google.

FAQ markup is the clearest recent illustration. Google stopped showing FAQ rich results on 7 May 2026 and is removing the associated Search Console reporting through 2026. The FAQPage type was not deprecated — the markup is still valid, causes no errors, and is still read by Bing and by AI crawlers. Perfectly correct FAQ markup now produces no Google rich result at all, and no validator anywhere can change that.

The workable division of labor: use a validator to confirm the markup is correct, the Rich Results Test to check eligibility for a specific format, and Search Console's enhancement reports to see what Google actually did with your pages over time. Only the last one reflects reality on your own site.

Common Schema Markup Errors

These are the mistakes that come up repeatedly on real pages, roughly in order of how often they appear.

• A missing @context. Without "@context": "https://schema.org" the block is not read as Schema.org at all, no matter how correct everything inside it is.
• Prices written as "$19.99". The price property must be a bare number — "19.99" — with priceCurrency carrying "USD" separately.
• Dates in a human format. "March 5, 2026" is invalid; ISO 8601 is required, so "2026-03-05". Events and videos also need the timezone offset, as in "2026-03-05T09:00:00-05:00".
• Relative URLs. Properties like url, image, logo and sameAs need the full absolute address including https://.
• author as a plain string. "author": "Jane Doe" is accepted but weak; a nested Person object is what search engines can connect to an actual entity.
• Wrongly cased names. "datepublished", "aggregaterating" and "@type": "article" all fail silently — nothing in the page or the browser will tell you.
• Two plugins writing markup. A theme and an SEO plugin both emitting Organization leaves search engines choosing between versions that often disagree. This is the most common source of duplicate markup.
• Markup describing something not on the page. Ratings with no visible reviews, or FAQ markup for questions that do not appear in the content, is a policy violation rather than a syntax error — and no validator can catch it, because validators only read markup.

How to Fix Schema Validation Errors

A repeatable order of operations, because fixing these out of sequence wastes time.

Start with blocks that failed to parse. Nothing inside an unparseable block is read, so its contents cannot be assessed until the JSON is valid. The usual culprits are a trailing comma before a closing brace, an unescaped quotation mark inside a string, and a template variable that rendered empty and left a syntax hole behind.

Next, fix missing @context and @type. These are cheap, mechanical, and they gate everything else — an entity with no recognizable type cannot be checked against any property rules.

Then work required properties, using the path each error reports. A path like offers.price tells you the failure is on the nested Offer, not on the Product wrapping it, which is usually where people look first and waste ten minutes.

Then value formats: reformat dates to ISO 8601, strip currency symbols from prices, make relative URLs absolute. These are quick and they are the errors most likely to make a search engine discard an otherwise-good entity.

Then recommended properties, but only where you have real data. Adding an aggregateRating with invented numbers to clear a warning is worse than leaving the warning: it is a policy violation, and manual actions for structured data spam are real.

Finally, find where the markup is actually generated. If the same error appears on hundreds of pages, it lives in a template or a plugin setting, and editing pages one at a time means the next content update undoes your work. Fix it at the source, then re-validate a sample of pages to confirm it took.

Which Schema Types Are Worth Adding

More markup is not better markup. Every type you add is another thing to maintain and another thing that can drift out of sync with the page.

Almost every site benefits from Organization and WebSite, declared once on the homepage. They describe the entity behind the site, they are cheap to keep accurate, and they are what search engines and AI systems use to work out who you are.

Beyond that, add what genuinely matches the page. Articles and blog posts want Article or BlogPosting. Shops want Product with a properly formed Offer. A business with premises wants LocalBusiness with a real PostalAddress rather than an address squashed into one string. Recipes, Events, VideoObject and JobPosting each unlock a specific result format when the underlying content is real.

BreadcrumbList is the underrated one. It is small, easy to get right, and it turns the URL line in search results into something a person can read.

This validator carries property specs for those types plus the nested types they depend on — Offer, Rating, AggregateRating, Question, Answer, ListItem, PostalAddress and others. Types it has no spec for are reported as unchecked rather than as errors, because Schema.org has hundreds of types and an unfamiliar one is far more often valid markup than a mistake.

Why Validate, and What Good Practice Looks Like

Structured data is not a ranking factor. Adding markup does not move a page up the results, and any tool suggesting otherwise is selling something.

What it does is make a page eligible for presentation formats that are not otherwise available, and make the facts on it legible to systems that summarize rather than link. That second point has grown considerably: AI crawlers read Schema.org markup, and it is one of the few mechanisms for stating facts about your content in a form that does not depend on a model inferring them from prose.

Broken markup gets you neither, silently. That is the real argument for validating — not that it improves anything, but that markup fails without any visible symptom, and a page can carry structured data that no search engine has read for two years while looking entirely fine.

• Validate before deploying, not after. Paste mode exists for exactly this, and a mistake caught in a template is one mistake rather than ten thousand pages of it.
• Only mark up what a visitor can see. This is a Google policy, not a style preference, and violations can attract a manual action.
• Prefer JSON-LD for anything new, and keep it server-rendered.
• Use one source of markup. Pick the theme or the plugin, not both.
• Re-check after any migration, redesign or plugin update. These are when markup breaks, and nothing will tell you.
• Keep dates current. A dateModified that has not moved in three years is worse than no dateModified.
• Watch Search Console's enhancement reports over time. They are the only view of what Google actually did with your markup.

Where This Fits With Your Other Checks

Structured data is one signal among several, and it is worth confirming the basics are sound before optimizing the markup on a page nobody can reach. Our SEO Analyzer covers titles, headings and canonicals, and the HTTP Header Checker will show whether an X-Robots-Tag or a redirect chain is stopping the page being indexed in the first place.

If you are writing markup from scratch, our Schema Generator produces JSON-LD for the common types with the right syntax, and this validator checks the result once it is live. The Open Graph Preview covers the other set of meta tags — the ones that decide how a link looks when it is shared rather than how it is understood.

Frequently Asked Questions

Related Tools