Audit JSON-LD by asking one question of every node and property: what visible page evidence makes this statement true? Keep markup that describes the page accurately, consolidate duplicate identities and remove claims the user cannot verify. Passing a syntax test is useful, but it does not make unsupported ratings, offers, qualifications or relationships acceptable.
Create an inventory of every markup source
Collect structured data from the rendered page, not only from a source template. Themes, plugins, tag managers, application code and server components can all emit JSON-LD. Record the source, page pattern, entity type, identifier and owner of each block. Then group pages by template so the team can see whether one setting creates a site-wide error.
Build a small claim ledger. For each property, note the visible text, image, link or business record that supports it. The method used in checking invented metrics fits this task directly: a precise-looking value is still unsupported when its source, scope or update path is unknown.
Pay special attention to identities. Several organization nodes with different names, URLs or identifiers can describe one company as if it were unrelated entities. Choose a stable identifier for the organization and reuse it where the page genuinely refers to that entity. Do the same for authors, products and other recurring objects.
Test meaning before eligibility
Separate three checks. First, parse the JSON-LD and confirm valid vocabulary. Second, compare the rendered graph with the visible content. Third, use the relevant search testing tool to understand eligibility and errors. Eligibility is not a guarantee that a special result will appear, and a warning is not permission to invent the missing information.
- Remove ratings or reviews that users cannot see and verify.
- Do not mark navigation questions as a visible FAQ.
- Keep prices, availability and offers synchronized with the page.
- Use dates and authors only when the page presents them accurately.
- Avoid relationships that exist only to make the graph look complete.
Review images and assets as evidence too. A generic logo URL, stale product image or inaccessible author picture can break the connection between markup and page. The website asset risk audit provides a parallel lesson: provenance and deployment must agree, even when the file itself is technically valid.
Remove duplication and prevent template drift
After correcting individual pages, crawl representative templates and compare entity counts, identifiers and property sets. Look for duplicated plugin output, markup from hidden components and stale values inherited from older designs. Store approved patterns alongside tests so a theme update cannot silently restore removed claims.
Assign ownership by source. A content editor may own visible FAQ text, while an engineer owns the serializer and a product owner controls offer data. A useful workflow routes a mismatch to the person who can correct the source of truth. The agency automation case offers adjacent evidence for converting repeated checks into a review process, without treating automation as proof that the markup is true.
Track findings such as unsupported properties, duplicate identities, template coverage and unresolved owners. Do not report a rich-result uplift unless a named measurement design and observation period exist. The safe outcome of this audit is a smaller, more coherent graph that matches what people can see.
Company evidence on this page is limited to AI4SALE providing AI product development, public evidence in digital-product delivery and maintained open-source AI tooling. It does not prove rich-result visibility, conversion or a product outcome from structured-data changes.
Frequently Asked Questions
No. Valid syntax and eligibility are necessary checks, but search systems decide whether to show a special result and do not guarantee display.
Only include entities relevant to the page and connect recurring organizations through a stable identifier. Avoid generating unrelated duplicates on every template.
Structured data should match content visible to users. Marking questions that are absent or hidden solely for search presentation creates an evidence mismatch.
Maintain a ledger that maps each block and property to its template source, visible evidence, stable identifier, owner and regression test.
For a product site that needs an evidence ledger, stable entity model and automated regression checks, discuss the scope through AI4SALE AI product development. Treat honest structured data as part of the product contract, not as decorative SEO inventory.