How do I check if my schema markup is correct?

Check three things in order. First that it parses — a trailing comma invalidates the whole block and search engines treat an unparseable block as absent. Second that required properties for the declared type are present. Third, and most importantly, that every value matches something a visitor can actually see on the page. The third is where most real failures are, and it is the one syntax validators do not test.

Why is my structured data valid but not showing rich results?

Valid markup makes you eligible for a rich result, not entitled to one. Common reasons for eligibility without appearance include the page not being indexed, the markup describing content not visible on the page, a manual action, or simply the search engine choosing not to display it for that query.

Is there a free schema markup validator?

Yes. Our structured data checker is free and needs no account for your first scan. It expands your JSON-LD to real schema.org IRIs rather than matching type names as strings, so aliased and prefixed vocabularies resolve correctly instead of being reported as missing.

Structured Data27 July 20267 min read

Free schema markup validator: valid is not the same as correct

Most structured data problems are not syntax errors. They are markup that parses perfectly and describes a page that does not exist.

By Sapun Lamichhane · Arcetis

Structured data fails in two ways that look nothing alike. One is a syntax error, which every validator catches. The other is markup that parses flawlessly and describes a page that does not exist — and almost nothing catches that except a human reading both.

The failure that gets sites penalised

Search engine guidelines are explicit: structured data must describe content visible on the page. Marking up a rating nobody can see, a price that is not shown, or an author who appears nowhere is a violation, and it is grounds for a manual action that removes your rich results entirely.

This is rarely deliberate. It happens when a template outlives the content it was written for — the product page stops showing reviews, and the aggregateRating block stays behind because nothing connected the two.

Why type names should not be string-matched

JSON-LD allows the same entity to be expressed several ways. A page may declare a custom @context, alias a term, or use a vocabulary prefix, and all of these are correct. A validator that matches the literal string "Organization" will report a perfectly good Organization entity as missing.

Expanding the document first — resolving every term against its @context to a full schema.org IRI — is the difference between checking what a page means and checking how it happens to be spelled.

One accurate type beats five speculative ones

There is a persistent belief that more types means more coverage. It does not. Speculative types risk contradicting each other, and a page carrying Article, NewsArticle and BlogPosting simultaneously has told a search engine three things about itself, at least two of which are guesses.

Pick the type that genuinely describes the page. Add Organization and WebSite site-wide, BreadcrumbList wherever there is a hierarchy, and FAQPage or HowTo only where the content actually takes that shape.

Why this matters more for AI than for search

For search, structured data is an enhancement — it changes how a result is displayed. For an assistant, it is the difference between a fact and an inference. A price in prose has to be interpreted; a price in an Offer is stated. That distinction decides how confidently a model repeats it, and how likely it is to repeat it wrongly.

What free means here

Our structured data checker is free, with no account needed for your first scan. It expands your JSON-LD properly, reports the entity types and properties it finds, and treats absence as detection rather than failure — a law firm is not defective for lacking Recipe markup, and an audit that says otherwise is wasting your attention.