audit_schema

Cost: 5 credits.

audit_schema reviews the structured data on the pages captured by your project's most recent crawl_site run. It is synchronous and returns its findings immediately. Run crawl_site first — with no crawl on record the tool says so and charges nothing.

What it does

Reports on the JSON-LD found across the site:

• Coverage — how many pages carry JSON-LD structured data and how many have none.
• Type spread — a site-wide count of the schema.org @type names in use (Organization, WebSite, Article, Product, and so on).
• Gaps — the URLs of pages with no structured data at all.
• Types that no longer produce a Google rich result — printed only when the site declares one. FAQPage and HowTo are no longer in Google's rich-result gallery, so the markup is reported as present and left alone: it is not checked for missing fields, because repairing it would buy nothing.

Detection is JSON-LD only — microdata and RDFa are not read at all, so a page marked up that way counts here as having no structured data.

Coverage is what this tool is for, and coverage is what it always reports. On a crawl that stored the JSON-LD bodies, it additionally checks the required fields of the types it knows — see below. On an older crawl that stored only the type names, it checks nothing of the sort and says so. The closing note of every reply tells you which of the two you just got, and names how many pages were checked; a reader should trust that line over any general statement, here or in the tool list.

What it checks in a stored JSON-LD body

For a short, fixed list of schema.org types — each one backed by a type Google's own gallery documents — it checks that the fields without which the markup says nothing are declared — a Product with no offers, an Article with no datePublished, a BreadcrumbList with no trail, a LocalBusiness with no address. A type not on that list is not judged at all: schema.org has hundreds of types, and inventing requirements for the ones nobody considered would produce findings you could not trust.

A block that is not valid JSON is reported, not skipped. A parser that cannot read it is a stand-in for a search engine that cannot read it either, and it is invisible in the rendered page — nobody finds it by looking.

This is not full structured-data validation. It is a required-field check over a handful of types, on the blocks that were stored. Only the first few blocks of a page are kept, and each is kept only up to a length cap, so a page whose markup was partly stored is listed as such and the reply says the fields were checked on the stored blocks only. Absence of a finding is not a clean bill of health.

Example

Ask your MCP client in plain language:

Run a structured-data audit for my example.com project.

Input

Returns

The JSON-LD coverage counts, the site-wide @type spread, and the list of pages with no structured data. Where bodies were stored, it also lists the pages missing a required field (naming the type and the fields), the pages whose JSON-LD could not be parsed, and the pages whose blocks were only partly stored. Each of those three sections is printed only when it has rows, so a crawl carrying no bodies returns exactly the coverage report it always did — an absent section is never a clean result.

The reply opens by naming the crawl it judged — a short job id, the date it was taken, how many pages it covered and how many URLs it skipped. If you did not pass job_id, it also says so and tells you how to choose a different crawl. That line exists because the newest crawl is not always the widest one: a narrow re-crawl of one section becomes the newest, and an audit that silently judged it would charge full price for a fraction of your site.

If this tool has already audited this same crawl, the reply says so and when. The report is deterministic, so a second run over an unchanged crawl returns the same findings — the note is there so that is a choice rather than a surprise. The price is unchanged either way.