The problem
Structured data (JSON-LD embedded in a <script> tag, or microdata attributes woven into the HTML itself) is how you tell a search engine explicitly what a page is — a product, an article, a recipe, an event — instead of leaving it to infer that from the text. It's also easy to get subtly wrong. A block can be syntactically valid JSON and still fail: a required field missing for the declared type, a value of the wrong type, or a schema that's technically present but empty of anything a search engine can actually use. None of that shows up as an error in the browser — the markup renders fine, the page looks correct, and the only sign anything's wrong is that the rich result never appears. Structured-data bugs are invisible until you go looking for them at scale.
Do it in RacingRoach
Structured-data validation is a Premium check — it requires a $59.99/yr license and doesn't run on the free tier. We gate it because it's genuinely expensive to do right: real per-type schema validation (not just "is this valid JSON") against a growing set of Schema.org type definitions is ongoing work to build and maintain, and licensing is what funds that. Everything else about crawling — the crawl itself, the 1,000-page free tier, the other 90-plus checks — is unaffected either way.
With a license active, start a crawl as normal. RacingRoach extracts every JSON-LD block and microdata item from each page during the same pass that pulls titles, links, and everything else — there's no separate structured-data tool to run afterward. Each block gets checked against the rules that matter for its declared @type: does it parse, does it declare a type Schema.org recognizes, and does it carry the properties that type actually requires. The results land on the Issues screen alongside every other check, filterable and exportable to CSV like the rest of the crawl.
Interpret the results
"Invalid" covers three different failures, and they call for different fixes:
- Broken syntax — the JSON-LD doesn't parse at all (a trailing comma, an unclosed brace). Search engines silently ignore the whole block; there's no partial credit.
- Missing required properties — the type is declared correctly but a property Schema.org requires for it isn't there. A
Productwithout anoffersblock, or anArticlewithout aheadline, are both syntactically fine and functionally useless for rich results. - Type mismatches — a property is present but holds the wrong kind of value: a
priceas free text instead of a number, adatePublishedthat isn't a real date. These are the hardest to catch by eye because the markup reads as plausible at a glance.
A fourth case is worth calling out on its own because it won't throw an error at all: markup that's syntactically valid and structurally complete but semantically empty — a Product schema present on the page with no price or availability anywhere in it. Nothing is malformed; there's just nothing there for a search engine to build a rich result from. That's a content gap wearing the shape of valid markup, and it's exactly the kind of thing a one-off manual spot-check misses and a full-crawl check catches.
Fix it
Fix each flagged block against what its declared type actually requires, not against a generic "is this valid JSON" bar. Add the missing required property, correct the mismatched value type, or fill in the property that made the block semantically empty — a price and availability for that bare Product, for instance. Then re-crawl the affected pages to confirm the fix registered; because structured-data checking runs on every crawl rather than as a one-time audit, there's no separate validator to remember to re-run — the next full crawl (or a scoped list-mode crawl of just the pages you touched) picks it up automatically. Treat it the same way you'd treat any other issue on the Issues screen: fix, re-crawl, confirm clean.