Schema Markup Validator Guide: Check Structured Data Before Search Engines Do

Schema markup is a layer of structured data added to a web page that describes the page's content in a standard vocabulary: this page is an article, written by this author, published on this date; this page is a product, sold at this price, currently in stock. Search engines read that layer to understand pages more precisely, and it is the foundation for rich results and other enhanced displays. The Schema Markup Validator checks a markup block for structural correctness, field by field, so errors are found by you in an editor rather than by a search engine after publication, or by a visitor who never sees the benefit the markup was meant to provide.

Validation matters because markup fails quietly. A page with broken markup looks exactly the same as a page with working markup to a human visitor, because the markup is invisible in the rendered page. The failure only shows up indirectly: a rich result never appears, a search listing shows less information than a competitor's, or a testing tool reports an error months after the page went live. Validating before publication catches those failures at the cheapest possible moment, when the fix is a small edit rather than a cleanup project across dozens of pages.

It also matters because markup has a grammar, and grammar errors are easy to make. A missing comma, a field nested at the wrong level, a value written as text where a structured item is required, a type name misspelled by one letter: each of these is a small mistake that invalidates a block or changes its meaning. Human eyes are poor at spotting such errors in a block of structured text, especially when the block was copied from another page and edited in a hurry. A validator is not a luxury for markup work; it is the equivalent of a spellchecker for a language where every spelling mistake changes the meaning.

How schema markup is validated

Validation starts with the markup block itself, usually written in JSON-LD, a script block embedded in the page that contains a structured object. The validator first checks that the block is well-formed: that its brackets balance, its commas are in place, and its text is parseable at all. A block that fails this step cannot be interpreted, and the validator reports the position of the problem so it can be fixed. This is the simplest class of error and the most common one in hand-written markup.

The second step checks the structure against the vocabulary. Every item declares a type, such as Article, Product, or FAQPage, and every type allows certain properties and requires some of them. The validator checks that the declared type exists, that the properties used belong to that type, and that required properties are present. It also checks that property values have the right shape: a date should look like a date, a price should be a number rather than a sentence, and a nested item such as an author or an offer should itself be a properly structured item rather than a bare string. A value with the wrong shape is a frequent cause of markup that parses cleanly but fails in a search engine's stricter reading.

The third step is the one that requires judgement rather than rules. A validator can confirm that markup is structurally correct, but it cannot confirm that it is truthful. Markup that declares a five-star rating for a product with no reviews, or a price that differs from the price shown on the page, will pass structural validation and still be wrong, and search engines treat misleading markup seriously. Validation is therefore necessary but not sufficient: after the validator passes, a human still needs to check that the markup matches the visible page, field by field.

Worked example

Consider a blogger who adds article markup to a new post. The block declares the type Article, with a headline, an image, a publication date, and an author. The validator reports three problems. First, the author is written as a plain name, while the vocabulary expects an author item with its own type, such as a Person item containing the name. Second, the publication date is written in a casual format, 9 July 2027, rather than the standard date format the vocabulary requires. Third, the image field points to a file path that is relative to the page, while the vocabulary expects a complete address.

The fixes are small and mechanical. The author becomes a Person item with a name inside it. The date is rewritten in the standard format, 2027-07-09. The image address is completed to a full address. Re-running the validator shows a clean block. The blogger then checks the visible page against the markup and finds one more issue the validator could not catch: the headline in the markup differs slightly from the headline on the page, because the page headline was edited after the markup was written. Aligning the two removes a mismatch that could have confused a search engine's reading of the page.

The example shows the typical pattern of markup errors: a shape problem, a format problem, and an address problem, followed by a truthfulness check that only a human can do. None of the four problems was visible on the rendered page, and all four would have survived indefinitely without validation. The blogger adds validation to the publishing checklist, so every new post's markup is checked before publication rather than discovered to be broken months later.

Mistakes to avoid

The first mistake is publishing markup without validating it, on the assumption that a block copied from a working page will work on a new one. The second is fixing only the first error a validator reports and not re-running it, when one fix often reveals the next error underneath. The third is writing values in casual formats, such as dates in everyday wording or prices with currency symbols attached, instead of the structured formats the vocabulary requires. The fourth is letting markup drift from the visible page, so the structured layer describes a price, a date, or a headline that no longer matches what visitors see. The fifth is adding markup for content that is not on the page at all, which passes structural validation but risks being treated as misleading.

Putting it into practice

Validate every markup block before publication, and re-validate after any edit to the block or to the page content it describes. Fix errors one at a time and re-run the validator after each fix, because errors hide behind each other. After the validator passes, read the markup against the visible page once, checking headline, dates, prices, images, and authors for agreement. For pages that share a template, validate one page from each template rather than assuming all pages built from it are identical, because a single page with an unusual field can break the pattern.

For related checks, the Rich Result Eligibility Checker tests whether valid markup qualifies for enhanced search displays, the Open Graph Checker reviews the preview data used when a page is shared, and the companion guides on structured data with JSON-LD and schema mistakes that pass validation but fail rich results go deeper into the markup itself. Validation is the step that turns structured data from a hope into a verified part of the page.

Key points

• Schema markup is a structured layer describing a page's content in a standard vocabulary, and it fails invisibly when it is wrong
• A validator checks well-formedness, vocabulary structure, and value shapes, field by field
• The most common errors are wrong value shapes, casual date and price formats, and incomplete addresses
• Structural validation cannot catch untruthful markup, so a human must still check the markup against the visible page
• Validate before publication, re-run after each fix, and re-validate whenever the page content changes

In short: validate the block, match it to the visible page, and never let structured data go live on the assumption that it works.