Schema Markup Validator: How to Test Your Structured Data

A schema markup validator is what you reach for when structured data is on the page but nothing has changed in search. Here is what each validator actually checks, how to read the results, and the order of testing that saves the most time.

Why test something nobody can see

Structured data is a block of information in a page's code. It tells a search engine that the page is a product, an article, an organization or a job posting. Visitors never see it, so a page with broken markup looks perfectly normal. The only way to find the problem is with a machine reader, which is what a validator is.

Small things break it: an extra comma in JSON-LD, a price written with the word "sum" next to it, an image link without the domain. The search engine then ignores the whole block or picks up only part of it. That is why testing is needed both before publishing and after.

Which schema markup validator checks what

There is no single tool for every case. The validators complement each other rather than replace each other.

One subtlety: Google's tool only knows the types that have rich results. If you mark up a clinic's service in Tashkent and the tool says it found no valid items, that is not a markup error. It is a limit of the tool, and the Schema.org validator is the right check for those cases.

  • Google Rich Results Test: judges whether a page qualifies for rich results such as products, articles, breadcrumbs, reviews, jobs and events. It accepts a live URL or pasted code and shows the page as Google's crawler renders it.
  • Schema Markup Validator (validator.schema.org): checks syntax and vocabulary for any type, including Service and Organization. It does not tell you whether you will get a rich result.
  • Yandex Webmaster markup validator: checks a page or snippet against the formats Yandex supports, such as Schema.org and Open Graph. Useful if your site gets traffic from Yandex.
  • Search Console reports: work after publishing and show the whole site at once, with how many pages have valid markup, warnings or errors.

Errors vs warnings: where to start

An error means a required property is missing or a value is wrong. That markup cannot produce a rich result, so fix it first. A warning means a recommended property is absent: the markup works but is incomplete.

Treat warnings with judgment. If the data really exists, such as a rating built from genuine reviews, add it. If it does not, do not invent values just to clear a yellow flag. Markup must describe what is actually visible on the page, otherwise it breaks search engine guidelines.

The most common breakages

Most problems repeat from site to site. These come up most often:

  • A trailing comma after the last item or an unclosed quote in JSON-LD
  • A price with a currency symbol or spaces between thousands: price takes a plain number, and the currency goes in a separate property (UZS for the sum)
  • A date not in ISO 8601 format
  • A relative image URL instead of a full address
  • A misspelled property name or wrong letter case
  • The same object added twice by different plugins
  • Markup that describes content missing from the page

Testing order, and when to repeat it

Repeat the checks after a theme change, a plugin update, a redesign of product cards or a move to a new CMS. A typical case: an online store changes the layout of the price block and the price property stops being filled. The page looks fine, but the markup is empty. A rising error count in Search Console will flag it in time.

Because these errors usually come from templates, one fix in the template repairs every page of that type.

  • First, paste the code into the Schema Markup Validator for syntax and vocabulary.
  • Next, test the published page in Google's Rich Results Test.
  • Then run the Yandex validator if that search engine matters to you.
  • After publishing, watch the Search Console reports once the crawler has had time to revisit the pages.

Valid markup does not guarantee a rich result

Even flawless code does not oblige Google to show a rich result. The decision depends on site quality, the query and the format of the results page. If the validator is green and the snippet is missing, that is normal, not a reason to rewrite the code endlessly.

So judge markup in the context of your wider strategy: which page types matter most, where a rich result genuinely brings enquiries, and where the time is better spent on content, site speed or product cards. These are the questions we work through at markdev as part of marketing strategy and consulting for businesses in Uzbekistan.

If you want to know which markup your site needs and whether it is worth the effort right now, talk it over with the markdev team. We will look at your site and suggest an order of work.

FAQ

If I can only use one schema markup validator, which one?

Use the Schema Markup Validator to check that the code itself is correct. If a Google rich result is the goal, use the Rich Results Test. Ideally use both, and add Yandex if it sends you traffic.

The validator shows no errors, yet there is no rich result in search. Is something broken?

No. Valid markup only makes a rich result possible. The search engine decides whether to show it, based on site quality, the query and the layout of the results.

Google's tool found no items for my markup. What now?

The type probably has no rich result in Google, as with Service. Check the code in the Schema Markup Validator, which shows structure and syntax errors regardless of the search engine.

How often should markup be tested?

More than once. Repeat the checks after theme or plugin updates, changes to product cards or a CMS migration, and keep an eye on the Search Console reports.

Let’s look at your task for free

Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.