Structured Data Testing — Validate Schema Markup for Google

Schema markup is one of the few SEO investments where the payoff is direct and visible: implement it correctly and Google rewards you with rich results that take up significantly more real estate in the SERP. Implement it incorrectly and nothing happens — no error message, no console warning, just the same plain blue link you started with. The silent failure mode is what makes validation so important.

The challenge is that there are two separate bars to clear. First: is the JSON-LD syntactically valid according to the schema.org specification? Second: does it meet Google's stricter, implementation-specific requirements for rich results? A schema can pass the first test and fail the second. This guide explains both bars, the tools for testing each, and the specific errors most likely to be blocking your rich results.

Google's Rich Results Test

The Rich Results Test is Google's primary structured data validator. It accepts either a live URL (which it fetches in real time) or a raw code snippet you paste directly — the latter is useful for testing schema changes before you deploy them.

For each page or snippet it analyses, the tool reports:

• Which schema types were detected (Article, Product, FAQPage, etc.)
• Which types are eligible for rich results in Google Search
• Which required properties are present and which are missing or invalid
• The distinction between ERRORs (which block the rich result entirely) and WARNINGs (which may reduce the richness of the result, such as missing a recommended but not required property)

The key distinction to understand: "Valid item detected" means the schema is syntactically correct JSON-LD. "Eligible for rich results" means all of Google's required properties are present and correctly formatted. You can have a valid item that is not eligible — the most common scenario when rich results never appear despite seemingly correct markup.

For example, a Product schema without offers (containing price and priceCurrency) is valid JSON-LD but not eligible for product rich results. A Review schema without itemReviewed is the same — valid but ineligible. The Rich Results Test will catch both.

Common Structured Data Errors and Fixes

Missing required properties

The most frequent cause of ineligibility. Each schema type has a set of properties that Google requires for rich results — these are stricter than schema.org's own required/recommended classifications.

Wrong @type

Using a less specific type when a more specific one applies. Google treats Article, NewsArticle, and BlogPosting differently for rich result eligibility. A tutorial or how-to article should use HowTo, not Article. A product review should use Review with a nested itemReviewed, not a bare Article describing the product. Using the most specific applicable type ensures Google can match your content against the right rich result template.

Date format errors

Dates must be in ISO 8601 format. "datePublished": "June 22, 2026" is invalid — it will be ignored or flag an error. Use "datePublished": "2026-06-22" or the full datetime form "datePublished": "2026-06-16T10:00:00Z". The same applies to dateModified, startDate, endDate, and any other date property.

Relative URLs

The @id, url, and image properties must contain absolute URLs. "url": "/blog/my-post/" is invalid — it must be "url": "https://www.example.com/blog/my-post/". Google needs the full URL to deduplicate entities and associate structured data with the correct page in its index.

Image object vs. image URL

Some schema types require an ImageObject with url, width, and height to be eligible for rich results — a bare URL string is insufficient. For Article/BlogPosting, Google recommends: "image": {"@type": "ImageObject", "url": "https://...", "width": 1200, "height": 630}. The Rich Results Test will warn you when an ImageObject is expected and a plain URL is provided.

JSON-LD Best Practices

Use @graph for multiple types on one page

When a page has multiple schema types — for example a blog post with BlogPosting, BreadcrumbList, and WebPage — wrapping them in a single @graph array in one <script> block is cleaner than multiple separate script blocks. Both approaches are valid, but @graph makes the relationships between entities explicit (via @id references) and is easier to maintain:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "...",
      "author": {"@type": "Person", "name": "Sunny Pal Singh"},
      "datePublished": "2026-06-22"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [...]
    },
    {
      "@type": "WebPage",
      "name": "...",
      "speakable": {"@type": "SpeakableSpecification", "cssSelector": [".speakable"]}
    }
  ]
}

Required properties for common types

A quick reference for the properties Google requires for rich result eligibility (not just schema.org validity):

• Article / BlogPosting: headline, author (with name), datePublished, image
• Product: name, offers (with price and priceCurrency)
• LocalBusiness: name, address (PostalAddress with streetAddress, addressLocality, addressCountry)
• FAQPage: mainEntity array of Question objects, each with name and acceptedAnswer
• BreadcrumbList: itemListElement array of ListItem objects, each with position, name, and item (absolute URL)
• HowTo: name, step array of HowToStep objects with text
• Event: name, startDate, location

Using Google Search Console for Site-Wide Validation

The Rich Results Test validates one page at a time. For site-wide visibility into structured data health, Google Search Console's Enhancements section is the right tool.

GSC groups schema errors by type across your entire site. If you have a blog with 200 posts and the author property is missing from the BlogPosting template, GSC will show that error against all 200 URLs at once — not just the one you tested. This aggregated view makes it immediately obvious when a template error is affecting your entire content library.

The workflow for fixing site-wide errors:

1. Identify the error — GSC shows the error message, affected URL count, and example URLs
2. Fix the template — in a CMS or static site generator, fixing the template fixes all pages at once; no need to edit individual pages
3. Verify with Rich Results Test — paste one of the affected URLs into the Rich Results Test to confirm the fix is live
4. Use "Validate Fix" in GSC — this notifies Google the issue is resolved and triggers a re-crawl of a sample of affected URLs; Google typically processes the validation request within 1–2 weeks

One important caveat: GSC structured data errors reflect Googlebot's crawl, which may lag 1–2 weeks behind your live site. If you deploy a fix today, GSC may continue showing the error for up to two weeks. The "Validate Fix" button accelerates this, but does not make it instantaneous.

Manual JSON-LD Inspection

For debugging complex structured data — particularly on JavaScript-rendered pages or CMS-generated content — manual inspection in browser DevTools is often faster than running the Rich Results Test repeatedly.

In Chrome DevTools, you can use the console to extract and inspect all JSON-LD on a page:

Array.from(document.querySelectorAll('script[type="application/ld+json"]'))
  .map(s => JSON.parse(s.textContent))

This returns an array of parsed JSON-LD objects that you can inspect directly. Common issues visible this way:

• Relative URLs appearing where absolute URLs are required
• Template variables not replaced (e.g. "datePublished": "{{post.date}}" appearing literally)
• Malformed JSON that would cause a parse error (syntax errors in the raw text)
• Missing properties because a CMS field was left blank and the template omitted the property entirely

For JavaScript-rendered content, remember that the Rich Results Test renders JavaScript — it will see schema injected by client-side code. But Googlebot's actual crawl behaviour for JS rendering is slower and less consistent than the test tool implies. Where possible, include structured data in the server-rendered HTML rather than injecting it via JavaScript after page load.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.