Skip to content
Contact DA
Published

How to validate structured data without chasing rich results

Schema Markup Validator and Google Rich Results Test are often used for the same task, but they do not answer the same question.

Schema Markup Validator helps you check whether structured data can be parsed as Schema.org markup. Google Rich Results Test checks whether a page may be eligible for Google rich results based on Google’s supported structured data features.

For a Thailand business website, that distinction matters. A villa rental page, tour page, restaurant menu, clinic service page, product page, article, or contact page can have valid structured data and still not qualify for a Google rich result. The goal is not to force a special search appearance. The goal is to describe visible content accurately so search engines and other systems can understand the page with less ambiguity.

Structured data validation workflow with JSON-LD blocks, schema entity nodes, warning panels, rich result previews, and Thailand website context

The short answer

Use both tools, but use them for different decisions.

  • Use Schema Markup Validator to check whether your Schema.org markup is readable and structurally valid.
  • Use Google Rich Results Test to check whether Google recognizes markup for supported rich-result features.
  • Use the visible page itself to decide whether the structured data is honest, useful, and complete.

Passing either tool does not guarantee rankings, rich results, AI visibility, or better traffic. Structured data supports understanding. It does not replace useful content, crawlability, internal links, page speed, or a page that actually answers the search intent.

What Schema Markup Validator does well

Schema Markup Validator is useful when you want to inspect the structured data itself.

It helps with questions like:

  • Can the JSON-LD be parsed?
  • Are the expected entities present?
  • Are nested objects connected correctly?
  • Are required or recommended properties missing for the type you used?
  • Did a CMS plugin output multiple conflicting entities?
  • Does the markup describe Article, Product, LocalBusiness, Service, BreadcrumbList, or another type clearly?

This is useful for custom Astro, Laravel, PHP, or WordPress sites where structured data may be generated by templates, plugins, theme code, or a custom integration.

The main strength is that it is broad. It is not only asking whether Google has a rich-result feature for the markup. It is asking whether the Schema.org data can be understood.

Where Schema Markup Validator is limited

Schema Markup Validator does not tell you that Google will show a rich result.

It also cannot decide whether the markup is a good business decision. A page can have technically valid schema that is still misleading, incomplete, duplicated, or irrelevant. For example, a service page should not use product, review, FAQ, or local business properties unless the visible page actually supports those claims.

That means the validator is a technical check, not an SEO approval stamp.

What Google Rich Results Test does well

Google Rich Results Test is useful when the question is specifically about Google rich-result eligibility.

It can show whether Google detects structured data types that are supported for rich results, and it can flag errors or warnings that matter for those supported features. That makes it useful when you are checking markup for pages such as products, articles, breadcrumbs, events, recipes, videos, or other Google-supported rich result types.

For a Thailand site, I would use it when a specific page type has a realistic rich-result use case:

  • A product or offer page where price, availability, and visible product details are present
  • An article or guide where article metadata should be clear
  • A breadcrumb trail that matches the visible navigation
  • A local business page where address, phone, opening hours, and visible business details are consistent
  • A video or event page where the visible content genuinely matches the markup

The useful part is not the pass/fail status alone. It is whether Google reads the same meaning that the page is trying to communicate.

Where Google Rich Results Test is limited

Google Rich Results Test only focuses on rich-result features Google supports. It is not a full Schema.org validator, and it does not guarantee that a rich result will be shown.

Google may choose not to show a rich result even when the markup is valid. Eligibility depends on more than syntax: page quality, policy compliance, search intent, device, location, query, competition, and Google’s own presentation choices all matter.

The test is also not a substitute for checking the page manually. If the structured data says something that visitors cannot verify on the page, the markup is wrong even if a tool accepts the syntax.

The rule: markup visible truth

Structured data should describe what users can see and verify.

Good structured data is boringly accurate:

  • Article schema describes the actual article
  • Breadcrumb schema matches the visible or logical navigation path
  • Product schema matches a real product page with visible offer details
  • LocalBusiness schema matches visible business information
  • FAQ schema is only used when the page visibly contains real questions and answers
  • Review or aggregate rating markup is only used when the page legitimately shows those reviews

Bad structured data tries to manufacture search features. That creates risk and usually makes the page less maintainable.

For small business websites, the most common mistake is not broken syntax. It is adding schema because a plugin, checklist, or SEO tool suggested it without checking whether the page supports it.

A practical validation workflow

Start with the page, not the tool.

  1. Decide what the page actually is: article, service page, product page, location page, contact page, booking page, or something else.
  2. Check whether the visible content supports the structured data type.
  3. Run the page through Schema Markup Validator to check parsing and entity structure.
  4. Run the page through Google Rich Results Test if the page type has a relevant Google rich-result feature.
  5. Fix template-level problems before editing one page at a time.
  6. Recheck after deployment, especially when WordPress plugins, themes, or custom templates generate the markup.
  7. Watch Search Console for structured data reports where Google provides them.

This keeps validation connected to implementation instead of turning it into a hunt for green checkmarks.

Common mistakes

The most common structured data problems I see are ordinary template problems:

  • Markup describes hidden content that users cannot see
  • Organization, LocalBusiness, Article, and WebPage entities contradict each other
  • Breadcrumb URLs point to staging, old routes, or redirected pages
  • Product or service schema is added to pages that are not real product or service pages
  • Review markup appears without visible reviews
  • Multiple plugins output overlapping JSON-LD
  • Dates, authors, prices, availability, or opening hours are outdated
  • Danish or English pages keep structured data from the wrong market or language

On Thailand-focused sites, multilingual routes need extra care. The visible page, title, h1, metadata, canonical URL, language alternate, and structured data should all describe the same market and language version.

Structured data validation belongs inside a wider technical SEO workflow.

Use the guide on structure, semantics, and metadata for the HTML and metadata foundation behind the markup. Use crawlability and indexation when the question is whether search engines can find and process the page at all. Use Google Search Console and Bing Webmaster Tools to compare validation findings with search-engine reports.

For the wider diagnostic workflow, start with website analysis for SEO and development.

Official references

Structured data guidance changes over time, so exact eligibility and policy details should be checked against current documentation:

From validation to fixes

Useful structured data work usually becomes template work: cleaning JSON-LD generation, removing duplicated plugin output, fixing canonical URLs inside schema, matching language versions, keeping business details current, and making sure the markup follows the visible page.

If your Thailand business website has confusing structured data warnings, send me the URL and what the tools report. I can help separate real issues from tool noise and point to practical fixes.

More articles