Structured data testing: tools and approaches that work

Adding Schema.org markup to your site is only half the job. The other half is verifying that it works correctly, that it stays correct as your site changes, and that agents can actually use it. Testing structured data has its own set of tools and techniques, and not all of them are obvious.

Start with validation

The first step is making sure your markup is syntactically valid. Invalid JSON-LD will be silently ignored by agents, and you will never know unless you check.

Google's Rich Results Test (search.google.com/test/rich-results) validates JSON-LD, Microdata, and RDFa. It shows which rich result types Google can generate from your markup and flags errors. The limitation is that it only validates Schema.org types that Google supports, which is a fraction of the full vocabulary.

Schema.org's own validator (validator.schema.org) checks against the complete Schema.org vocabulary. Use this when you are using types or properties that Google does not support but agents might still read.

JSON-LD Playground (json-ld.org/playground) is useful for debugging the JSON-LD format itself. It shows how the data is interpreted after context resolution, which can reveal unexpected behaviour with nested contexts or @id references.

Check for common errors

Validation catches syntax problems. These tools will not catch logical errors. You need to check for those manually.

Mismatched data. Does your structured data match what is on the page? If the JSON-LD says the price is 29.99 but the page displays 34.99, agents will get confused. This often happens when prices change in the CMS but the structured data is generated separately.

Write a test that compares key values:

// Example: compare JSON-LD price with displayed price
const jsonLd = JSON.parse(
  document.querySelector('script[type="application/ld+json"]').textContent
);
const displayedPrice = document.querySelector('[data-field="price"]').textContent;
const jsonLdPrice = jsonLd.offers?.price;

console.assert(
  displayedPrice.includes(jsonLdPrice),
  `Price mismatch: displayed "${displayedPrice}" vs structured data "${jsonLdPrice}"`
);

Missing required properties. Each Schema.org type has recommended properties. A Product without offers is technically valid but nearly useless to agents. Check the Schema.org documentation for each type you use and verify you have the important properties filled in.

Broken @id references. If you use @id to link entities across JSON-LD blocks, verify that every reference points to an @id that actually exists. A dangling reference creates a broken link in the agent's data model.

Automated testing in CI

Structured data should be part of your continuous integration pipeline. Here is a practical approach:

// structured-data.test.js
const { test, expect } = require('@playwright/test');

test('product page has valid structured data', async ({ page }) => {
  await page.goto('/products/wireless-keyboard');

  // Extract JSON-LD
  const jsonLdText = await page.$eval(
    'script[type="application/ld+json"]',
    el => el.textContent
  );
  const data = JSON.parse(jsonLdText);

  // Check type
  expect(data['@type']).toBe('Product');

  // Check required fields
  expect(data.name).toBeTruthy();
  expect(data.offers).toBeTruthy();
  expect(data.offers.price).toBeTruthy();
  expect(data.offers.priceCurrency).toBe('GBP');

  // Check price is a valid number
  expect(parseFloat(data.offers.price)).toBeGreaterThan(0);
});

Run this as part of your deployment pipeline. It catches regressions before they reach production.

Testing with actual agents

Validation tools tell you the markup is correct. Testing with agents tells you the markup is useful. There is a difference.

Set up a simple agent task that depends on your structured data:

1. "Find the price of [product] on [your site]"
2. "What are the opening hours for [your business]?"
3. "List all products in [category] that are in stock"

If the agent can answer these questions correctly using your structured data, you know it is working. If it struggles, watch where it fails. Common problems include: data that is technically valid but poorly structured, missing entity relationships, and properties with unhelpful values.

Monitoring over time

Structured data breaks silently. A CMS update might change the page template and drop the JSON-LD block. A developer might refactor a component and accidentally remove the structured data generation. You need ongoing monitoring.

Set up periodic checks. A weekly script that fetches key pages and validates their structured data will catch problems before they compound. Log warnings when:

• A page that previously had structured data no longer does
• The number of properties in a structured data block drops significantly
• Required properties are missing that were previously present

Track coverage. Know what percentage of your pages have structured data and what types are represented. A dashboard that shows "94% of product pages have Product markup" is more useful than checking individual pages.

Quick wins for better structured data quality

1. Validate every page type in your CI pipeline, not just the homepage
2. Compare structured data values against displayed content weekly
3. Monitor for pages that lose their structured data after deployments
4. Test at least one real agent task against your structured data monthly
5. Keep an inventory of which Schema.org types you use and where

Structured data testing is not glamorous, but it is the difference between markup that looks right in a validator and markup that actually helps agents do their job. Run an audit with Agent Checker to see how your structured data holds up, then build the tests, run them automatically, and check in on them regularly.