Published September 1, 2026.
Structured data is useful only when it describes the page a reader actually receives. This audit turns schema review into a small release control instead of a cleanup project after publication.
Inspect the rendered object
Build the site, open the requested route, and inspect the Article JSON-LD. Confirm headline, datePublished, author or publisher identity, image reference, and mainEntityOfPage. Each value should agree with visible content and the self-canonical URL.
Test identity before syntax
A syntactically valid object can still describe the wrong page. Check that the headline belongs to this route, the date is truthful, and the canonical does not point to an alias. Then run the relevant validator and retain its output.
| Layer | Evidence | | --- | --- | | Source | Approved front matter | | Build | Route generated without error | | Render | Visible title and date agree | | Schema | Parsed Article fields agree | | Live | Direct 200 response from intended host |
Escalate contradictions
Stop the release when schema changes public identity, implies an untrue date, or references another route. Lower-risk warnings can be logged with an owner, but the release record should never hide a known identity conflict.
Follow with the publication date checklist and Google’s Article structured data documentation.
Frequently asked questions
Does a passing rich-results test prove publication?
No. It shows that the tested markup can be interpreted. Production status and visible agreement require separate checks.
May an assistant alter schema fields automatically?
An assistant may correct deterministic mappings within an approved release. Conflicts involving authorship, dates, or public claims should go to the accountable editor.
