JSON-LD schema audit lab
Paste a URL or some markup. It pulls the JSON-LD, parses each block, then walks the graph nodes and the nested types so you can actually see what is in there. You also get a property coverage read for the usual schema patterns. Honestly the part I lean on most is the plain report you can skim before any of this hits a production template.
URL extraction reads the JSON-LD script blocks. Paste mode? That is for drafts, raw plugin output, a lone snippet you are testing, or any page that just refuses a browser fetch.
Valid JSON is only the first schema check
Here is the thing nobody tells you. A block can parse clean and still be junk structured data. Wrong type. Or it skips the one property that actually explains the entity. Sometimes it marks up stuff a visitor never sees on the page, which is its own kind of problem. And sometimes the graph is just a mess of identifiers and nested objects that nobody will want to maintain six months from now. So a schema markup validator that is worth your time, I think, has to show you the syntax and the graph shape at once, plus the content coverage that everyone forgets about.
So the tool reads JSON-LD from public HTML or from whatever you paste. It lists each block, walks the arrays and the @graph nodes, notes the nested @type values, and looks over the usual schema families: Article, FAQPage, BreadcrumbList, Product, SoftwareApplication, Organization, WebSite, WebPage. The checks stay readable on purpose. They are a second pair of eyes. Not a stand-in for Google’s feature docs or the Schema.org vocabulary, and you should not treat them that way.
What to review before publishing structured data
- Syntax: every block should parse, no hidden copy-paste damage sneaking in.
- Type fit: the type should match the page and entity a visitor actually sees.
- Coverage: fields like headline, itemListElement, acceptedAnswer, publisher. These have a way of quietly vanishing from a template, and you only notice later.
- Graph shape: the
@idreferences and nested nodes should still make sense once you reuse them site-wide. - Policy fit: do not promise content or reviews the visitor cannot find.
A practical schema workflow
- Pull the live URL right after a WordPress or SEO plugin change. Theme edits too. That is usually where things break.
- Open the graph node table. Check that the main page entities are actually there.
- Read the property coverage tab for whichever page type you care about.
- Paste a draft snippet if you want to test markup before it lands in the template.
- And when real eligibility or vocabulary validation matters, go run the official rich-result or Schema.org tools.
Common questions
Does valid schema guarantee a rich result?
No. Valid markup that meets the current requirements can make a page eligible, sure. Whether the feature actually shows up is a different call, and that one sits with the search systems and their own feature rules. Eligible is not the same as displayed.
Why does this tool focus on JSON-LD?
Because that is what most modern CMS and SEO plugins spit out, and you can inspect it without tangling annotations into your visible HTML. Microdata and RDFa are still around, I know. They just sit outside this audit, which is JSON-LD only.
Should every page use as many schema types as possible?
No, and honestly that instinct backfires. A small graph that describes the page accurately is far easier to live with than a bloated one you stuffed full of types just to chase features.
