Contextter Product Docs
Site Audit

Structured data and rich result validation

Structured Data turns retained markup into inspectable validation evidence. It shows what passed the configured ruleset, what needs attention, and where search-engine eligibility still remains a separate question.

Bounded crawl

Keep property, authorization, run, and crawl coverage visible.

Traceable evidence

Move from summaries to rules, URLs, links, assets, and raw facts.

Comparable verification

Confirm fixes with another crawl using an equivalent scope.

Know which pages and markup are evaluated

Successfully parsed HTML pages are checked for JSON-LD, Microdata, and RDFa. A run with rendering disabled validates fetched HTML. When a page is actually browser-rendered under an eligible or required policy, the rendered result can replace the retained structured-data evidence for that URL.

The report therefore describes the selected run and its per-page rendering path. It is not a promise that every discovered URL, script state, user interaction, or search-engine rendering was evaluated.

References are resolved before validation

JSON-LD nodes are collected into a graph so references by identifier can contribute properties to the evaluated item. Nested objects remain separate items where the markup defines them that way. Microdata and RDFa are collected from the parsed document and added to the same validation result.

Keep Schema.org and Google profiles separate

The current committed ruleset uses validator 2026-07-25.1, Schema.org 30.0, and Google profile 2026-07-24.3. The Schema.org catalog contains 933 known types and 1,521 properties, including deprecations, expected ranges, dates, times, numbers, URLs, durations, booleans, and closed enumeration values.

Google feature profiles add documented required, recommended, conditional, activation, and manual-review rules. A Schema.org-valid item can still lack a Google-required property, and a Google-profile match does not make the page eligible under every content policy.

Read the exact validation finding

  • Errors cover invalid context, missing type, empty property, invalid value shape, and missing required or conditional Google fields.
  • Warnings cover unknown or deprecated types and properties plus missing recommended Google fields.
  • Issues are deduplicated and capped at 100 per page; the run records when more existed.
  • Item snapshots and issue evidence have separate truncation flags.

Understand the 40 tracked Google profiles

The committed catalog tracks 40 Search Gallery or related profiles. Twenty-eight are automated or partially automated from page markup, eight are marked deprecated, two require manual handling, and two are not applicable to on-page markup. The UI reports feature keys emitted by the active automated and partially automated profiles.

Manual-review notes cover facts a crawler cannot prove, such as whether a job is real, a review is genuine, an event is bookable, or marked content matches the visible page.

Blocked, advisory, clean, and no evidence are different

StateMeaning
BlockedThe retained page has parse, validation, or required-field evidence that blocks the configured profile.
AdvisoryNo blocking item was counted, but warnings or recommended-field gaps remain.
CleanThe retained items passed the configured vocabulary and active profile checks.
No markupNo structured-data item was retained for the page.
No validation evidenceMarkup exists, but the run lacks the expected validation evidence and must not be called clean.

Use the sitewide summary with its denominator

The summary keeps evaluated pages, pages with and without markup, pages with blocking or advisory issues, clean pages, parse and validation pages, required and recommended gaps, total, valid, invalid, and Google-profile items, plus type, feature, and issue-group counts.

Type and issue-group lists are bounded and expose omitted counts or truncated evidence. Page totals and item totals have different denominators.

Move from site pattern to exact item

1
Confirm the selected run, evaluated-page count, ruleset versions, and evidence exactness.
2
Choose blocking, advisory, clean, or all rows and select attention, URL, or item-count order.
3
Open the recurring type, feature, or issue group and inspect representative pages.
4
Open a URL dossier to read the retained markup item and its attached finding.
5
Compare the stored snapshot with live source and rendered output before editing the template.

Rows and snapshots are deliberately bounded

The structured-data table uses server pagination with a current default of 20 rows. Search text is capped, type filters accept a bounded set, and the overview scan has its own ceiling. A URL snapshot keeps at most 25 items, about 4,000 JSON characters per item, and 30,000 across the page snapshot.

Trends use stored run snapshots

History can read up to 30 runs. It tracks markup coverage, clean, advisory, and blocked pages, valid and invalid items, eligible profile items, and stored type and feature counts. Charts display at most four categorical type or feature series selected by peak page count.

A rule-version change, missing summary, or inexact count needs qualification before a delta is presented as markup progress.

Ruleset identity makes drift visible

Every stored page and run summary can carry validator, Schema.org, and Google profile versions. A scheduled drift check compares the committed ruleset with its upstream catalogs and records internal findings instead of silently rewriting historical verdicts.

When a rule changes, rerun the site and explain the version boundary. Do not reinterpret an old saved verdict using a newer rule without new evidence.

Validation does not guarantee a rich result

A clean configured profile means the retained markup passed the checks implemented for that ruleset. Search engines can still withhold a rich result because of content policy, site quality, query context, trust, rendering differences, or product changes. Search Console and live search appearance remain separate observations.