NEW CASE
Antana

We create digital solutions that work for businesses


Give us a call +38 (066) 35-14-529

Let's take the first step towards your website — write to us

Close
Tools

Schema Validator

JSON-LD syntax, required properties per type and logical errors.

What the validator checks

Broken markup fails silently: the rich result simply never appears, and working out why without a check is hard.

JSON syntax A trailing comma, single quotes instead of double, comments — any one of these makes the whole block unreadable.
@context і @type Without a context the block is not tied to the schema.org vocabulary. Without a type there is no telling what you are describing.
Required properties Each type has its own set. A LocalBusiness without an address or a Product without a name is pointless.
Recommended properties Markup works without them but the result is thinner. We list them separately so the difference is clear.
Logical errors A rating of 7 out of 5, a price in words, a date as 15/01/2026, a relative URL — formally valid, functionally broken.
Nested entities Markup often nests entities: an Offer inside a Product, a Question inside a FAQPage. We check each one separately.

One caveat: valid markup does not guarantee a rich result in Google. That decision is always the search engine’s, and no third-party validator can predict it.

Common types and what they need

Organization Only name is required. But without logo, url and sameAs there is little benefit — those tie the site to the company profiles.
LocalBusiness Requires name and address. For local results add telephone, openingHours and geo coordinates.
Article headline is required. Author, publication date and an image are what give a full appearance in results.
Product The name is required; offers with a price, an image and a rating are what actually appear in results.
FAQPage Needs mainEntity with a list of Question items, each with an acceptedAnswer. The answers must exist on the page itself.
BreadcrumbList An itemListElement list with positions. It replaces a long URL in the result with a readable path.

Why Google removes a rich result

Data does not match the page The markup says 500, the page says 900. That counts as deception, and the penalty removes rich results across the whole site, not just that page.
A rating with no reviews AggregateRating on a page with no reviews at all. The most common trigger for a manual action over markup.
FAQ with no answers on the page The questions exist only in the markup and not in the page text. Google checks this and discards the markup.
Marking up content that is not there Describing a product that is not on the page, or someone else’s reviews. Formally valid but against the rules.

How to work through markup

1 Syntax first If the JSON is invalid nothing else matters: the block is unreadable and affects nothing.
2 Then required properties Without them the type is incomplete. Add the recommended ones only once the required are in place.
3 Check against the page Every value in the markup must be visible to a person on the page. That is the core rule, and breaking it is what gets penalised.
4 Verify with Google Our validator catches code errors, but only the search engine’s own tool can give a final answer about rich results.

FAQ

Does valid markup guarantee a rich result?
No. Error-free markup is necessary but not sufficient. Google decides based on page quality, site trust and query type. No third-party validator can predict that, and promises otherwise deserve scepticism.
What earns a manual action over markup?
Most often a rating on a page with no reviews, or data that contradicts the page — one price in the markup, another on screen. The penalty removes rich results site-wide, not just on that page, so the risk far outweighs the gain.
JSON-LD or microdata in attributes?
Google recommends JSON-LD: it sits in its own block, separate from the markup, so it is easier to edit and harder to break during a redesign. Microdata works too, but this validator covers JSON-LD.
How many markup blocks may one page have?
There is no limit, and several blocks are normal: Organization, BreadcrumbList and Article coexist happily. But describe only what is actually on the page — extra entities add no benefit and increase the chance of error.
Why flag an error when Google accepts the markup?
We separate required from recommended properties. Google may accept a block without the recommended ones, but the result is thinner: without an image and date an article looks plainer in results. We only call something an error when the type is incomplete per the specification.
Telegram Viber Call us