Structured Data

Correct material facts before expanding markup

Start by resolving a material conflict between the visible page, markup, and the record that owns the fact. Choose a type only when the page subject, maintained facts, and intended consumer make it applicable; defer additional types and properties that do not serve that purpose. The initial work is complete when the live, rendered page and markup agree, and the applicable consumer check has been recorded.

On this page

• Separate vocabulary, format, and consumer rules
• Model facts and relationships
• Choose only supportable types
• Generate markup from maintained facts
• Validate four different questions
• Avoid common implementation failures

Separate vocabulary, format, and consumer rules

Layer	What it answers	Check it against
Schema.org vocabulary	Which types and properties describe the subject?	The vocabulary definition and the real relationship
JSON-LD format	Is the graph encoded as valid JSON-LD?	A parser and Schema.org Validator
Consumer rules	Is the markup eligible for a documented use?	The current documentation and test for that consumer

Google recommends JSON-LD when practical, but Google Search feature requirements are its own rules. Valid Schema.org markup can be meaningful outside a Google feature, while a valid object can still be ineligible for that feature or be factually wrong. (Google’s introduction to structured data, Google Search Gallery)

Model facts and relationships

Start with the subject a visitor came to see. A Product is not its price or seller; those are properties of an Offer. An Article can identify a Person author and an Organization publisher. A WebPage can belong to a WebSite. A stable absolute @id lets the same entity be referenced consistently across those descriptions.

Use the most specific accurate type, then add only relationships that the page and maintained records support. A generic Organization is preferable to a location subtype that is not true. Several clearly connected objects are preferable to one object that blends page, author, publisher, product, and offer into an unclear identity.

Choose only supportable types

The type-selection reference has 26 entries, some of which cover related types together. It is a decision aid, not a list of required markup. Start with the site purpose and page subject, then follow the question that fits:

If the page is primarily about…	Start with
The publisher, its website, a public person, or a page relationship	Organization, WebSite, WebPage, and Person choices
A product, selectable variants, an offer, or a local location	Product, offer, and local choices
An editorial article, visible FAQ, review, or rating	Editorial and audience-content choices
A video, event, job, recipe, course, dataset, or other specialist item	Specialized-content choices

Do not mark up every noun. Each additional property is another fact that can drift from the page, feed, content system, or operational record.

Generate markup from maintained facts

Material values need an owner and an authoritative source. Compare product price, currency, availability, selected variant, and seller with the live page and commerce system. Compare article headline, author, dates, and image with the rendered article. Compare local-business name, address, telephone, hours, and location identity with the public location page and its maintained record.

Where possible, generate visible copy and JSON-LD from the same fields. A hand-written block is fragile for price, stock, hours, or other changing data when a separate commerce or content system already owns the fact. If the page, feed, and markup disagree, choose the correct source, repair it upstream, republish every dependent output, and then validate again.

A submitted merchant feed adds a third copy of the same commerce facts, with its own regeneration trigger and its own failure mode. Product feeds for AI answer engines covers which companies accept one and what they require; the merchant feed readiness checklist reviews a feed against the live page and its markup before submission.

Validate four different questions

1. Syntax: Does the JSON parse, and is the JSON-LD structure readable?
2. Vocabulary: Do the types, properties, values, and links accurately use Schema.org?
3. Consumer eligibility: Does the intended consumer recognize the required fields for its documented feature?
4. Page truth and delivery: Does the live, rendered page contain the markup, and do material values match what visitors can verify?

The new live-page validation tutorial gives a complete run through these checks, including how to interpret errors, warnings, no detected items, and a passing rich-results test. A provider test describes that provider’s features; it is not a universal semantic verdict.

Avoid common implementation failures

The code describes a fact the page does not provide. Remove unsupported ratings, claims, prices, or identity facts, or add the information through the normal content workflow when it belongs on the page.

A type was chosen for a hoped-for display. Begin with the real subject and model, then check whether a documented consumer feature applies.

Visible and generated facts drift apart. Trace the page, feed, plugin, cache, and template to their sources. Assign one maintained record to each material value.

Markup was copied without customization. Replace every example URL, identifier, name, price, and placeholder. Remove properties the page cannot support.

Validation stopped at a green result. A tool may recognize an object that remains wrong, missing from some templates, or unavailable to a consumer because rendering failed. Compare the live page and establish recheck triggers.

Structured data is ready to release when it accurately describes the delivered page, uses coherent identities, meets the requirements of the intended consumer, and has an owner for changing facts. The type-selection reference, templates, and live-page validation tutorial cover those decisions in order.