Which JSON-LD exists, whether it validates, whether it matches the page — and the markup you are missing.
Audit structured data across our blog, product, and pricing templates.
Two validation errors and one content mismatch — the stale pricing tier is the urgent one, since it markets an offer you no longer sell. FAQ markup on 14 posts is the largest missed opportunity; blocks are generated and ready to paste.
A schema markup template is worth little if the markup contradicts the page it sits on. This audit checks all three things that matter: whether structured data exists, whether it validates, and whether it accurately describes what a reader actually sees — then supplies the JSON-LD for what is missing.
A reusable JSON-LD pattern for a page type — Article, Product, FAQPage, HowTo, Organization — with the required and recommended properties filled from that page’s real content. The template is per page type, because markup that fits an article is wrong on a product page.
JSON-LD in a script tag, which Google states it prefers. It keeps structured data separate from your markup, so changing a heading does not silently break your schema the way inline microdata does.
A limited set: FAQ, HowTo, Product, Review, Breadcrumb, Event, and a handful more. Everything else helps machines understand entities without changing how your result looks — which is still worth doing, and the audit is explicit about which category each type falls into.
It helps answer engines parse claims reliably, especially FAQ and HowTo blocks where the question and answer are explicitly paired. Schema is not a ranking shortcut, but ambiguity is expensive when a machine is deciding what to quote.
The agent fetches your pages, extracts and validates structured data, and cross-checks Search Console rich-result reports for errors Google has already flagged. Generated JSON-LD arrives as copy-ready blocks per page template, so a developer or CMS editor applies one pattern instead of hand-writing markup per URL.
One or two per page template is enough — findings apply to the template, not the URL.
It parses existing markup, validates it, and compares each claim against visible content.
Errors first, mismatches second, missing opportunities third, with rich-result eligibility noted.
Take the per-template blocks into your CMS or codebase and re-run to confirm.
Checks markup against visible content, not just against the spec
Generates JSON-LD per page template rather than per URL
Separates rich-result eligibility from general entity clarity
Cross-references errors Google already reports in Search Console
An FAQPage block listing each question as a Question with its acceptedAnswer text. On this page, the questions you are reading are marked up that way, which is what makes them eligible to be quoted directly.
Pick the type that matches the page, fill in the required properties from real page content, embed it as JSON-LD, and validate. The failure mode is not syntax — it is markup that describes something slightly different from the page.
Yes, and arguably more so as answer engines parse pages programmatically. Rich results have narrowed for some types, but unambiguous machine-readable claims matter more when a model decides what to cite.
Generators produce syntactically valid markup but cannot tell whether it matches your page — which is the error that actually costs you eligibility. This audit checks that correspondence, then generates the block.