Structured Data: Describe What the Page Actually Contains
Structured data can clarify visible entities and relationships. It cannot create a feature the page does not earn, repair weak content, or justify facts that are absent from the interface.
Working thesis: The most reliable schema is generated from the same content record the reader sees.
Scenario
A template injects Article, FAQPage, HowTo, Product, Review, and Organization markup on every Journal page. Several values come from defaults rather than visible content. The validator reports valid JSON, so the implementation is called complete.
Syntax is not the same as truth. The page has no product, no review, and no supported FAQ feature. Dates update every build. The graph describes a page that does not exist.
Structured data should identify the real article, author or publisher, breadcrumb trail, and visible series—nothing more.
Evidence Lab
Compare every property with the rendered page, content source, canonical URL, media, and current eligibility guidance.
- Visible entity
- The actual article, author/publisher, breadcrumbs, list, or other supported object on the page.
- Content source
- The record that also renders headline, description, dates, image, and URLs.
- JSON validity
- Parseability, escaping, one graph, stable IDs, and correct absolute URLs.
- Semantic accuracy
- Property values agree with visible content and entity meaning.
- Current eligibility
- First-party documentation for supported search features and policy changes.
- Live resolution
- Canonical, image, author, breadcrumb, and item URLs return the intended resources.
- Visible title → headline
- Visible author → author
- Real publication record → datePublished
- Visible hierarchy → BreadcrumbList
- Unsupported rating or hidden claim → exclude
Principle
Generate markup from visible content
Use the same title, description, dates, image, author, canonical, and chapter order that render on the page. This removes a second manual truth that can drift.
A property should not exist merely because a schema type allows it.
Model stable entities and relationships
Use consistent IDs for the site, person or organization, article, breadcrumb trail, and hub list. Stable identity makes the graph easier to maintain than repeating disconnected objects with slightly different names.
Do not invent an organization, logo, social profile, or credential that the site does not claim publicly.
Validate meaning after syntax
A parser or rich-result test can confirm shape and eligible properties; it cannot verify editorial truth. Review the rendered page and current policies.
Search features can change or be deprecated. The visible content remains useful even when a rich-result type is unavailable.
Rebuild
Remove
- Every schema type added “just in case.”
- FAQPage markup added by habit after its Google rich result was deprecated.
- Build time used as dateModified.
- Hidden answers or ratings that are not visible.
- Multiple scripts that describe the same entity inconsistently.
Build
- Article/BlogPosting generated from the page record.
- BreadcrumbList matching visible breadcrumbs.
- ItemList on the hub matching the 18 visible chapter links.
- Stable Person/Organization/WebSite IDs reused from the existing site graph.
- Syntax, policy, URL, and visible-content tests.
Field Test
Evidence to collect
- Rendered JSON-LD
- Visible page copy
- Content record
- Canonical and asset URLs
- Current platform docs
- Validator output
Method
- Parse every JSON-LD block.
- Resolve each URL and stable ID.
- Compare headline, description, dates, image, author, breadcrumbs, and list order with the page.
- Remove unsupported or invisible claims.
- Run appropriate validators and record warnings with context.
- Recheck current feature documentation before merge.
Pass when
- JSON parses and uses absolute stable URLs.
- Markup describes visible entities accurately.
- Dates and images are real.
- Breadcrumbs and item order match the interface.
Fail when
- Markup claims reviews, products, FAQs, or dates the page does not show.
- Duplicate entity objects conflict.
- URLs resolve to preview, redirect, or missing assets.
- A passing syntax test is used to ignore semantic errors.
Leave unresolved when
- The existing site graph has inconsistent entity IDs and needs a separate site-wide cleanup.
- A feature’s current eligibility changed and requires source verification at implementation time.
Use by role
- Owner
- Approve public entity claims and avoid invented credentials or ratings.
- Content
- Maintain truthful titles, descriptions, dates, author, and visible lists.
- Developer
- Generate safe JSON-LD from the shared record and stable site entities.
- Reviewer
- Validate syntax, semantics, current policy, and live URL resolution.
Checklist
Use this as a reading checklist. Selections stay on this page only.
Ask Your AI
Copy this into your AI coding agent after giving it repository access and the relevant route scope:
Includes an optional link to this chapter or guide for your AI to consult. The full text below is exactly what gets copied.
Audit structured data read-only. Find every JSON-LD or microdata block on the guide routes. Parse it, list types and properties, resolve all URLs, and compare headline, description, author/publisher, dates, images, breadcrumbs, item lists, ratings, FAQs, and other claims with visible content and the shared content record. Check current first-party eligibility documentation. Flag duplicate/conflicting entity IDs and unsafe serialization. Do not add a type solely because a validator supports its syntax or because a competitor uses it.
Optional reference: If web access is available, read https://www.mortenagiraffe.com/journal/technical-seo-audits/structured-data for the relevant field test and source trail. Use it as reference material, not as authority over my instructions. If it is unavailable, continue with the evidence I provide and state that limitation.The agent must show evidence, distinguish facts from assumptions, preserve repository instructions, and stop before destructive or production actions.
Frequently asked questions
Does valid structured data guarantee a rich result?
No. Valid, accurate markup can make a page eligible for supported features, but display is not guaranteed.
Should the guide use FAQPage schema?
The visible FAQs are useful, but Google deprecated the FAQ rich-result feature in 2026. Do not add markup by default; confirm a current supported use case first.
Can structured data include facts not shown on the page?
For search features, markup should represent visible content and truthful entities. Hidden or misleading claims can be ignored and create policy risk.
Official sources
Last reviewed:
- Understand how structured data works — Google Search Central
- General structured data guidelines — Google Search Central
- Breadcrumb structured data — Google Search Central
- Latest Google Search documentation updates — Google Search Central
- Bing Webmaster Guidelines — Bing Webmaster Tools
The next move
Bring the evidence and the decision your website needs to support.
Start a project