Structured data and entity identity
Describe the facts your page supports.
Structured data expresses information in a defined format. Start with the page’s subject and supported facts, choose suitable vocabulary, then test the description for its intended use.
Free learning from Semantec SEO.

Separate the layers
Vocabulary, format and presentation are different decisions.
Schema.org supplies types and properties for describing things. JSON-LD, Microdata and RDFa are ways to express structured information. A search feature is a possible use of qualifying data. The vocabulary, expression and consumer requirements are connected, but they are not interchangeable.
A type describes a category of thing. A property expresses a characteristic or relationship. A format organizes those descriptions. Neither a suitable type nor valid syntax establishes that a detail is true.
The Schema.org data model explains its types and properties. Start with the subject and purpose, rather than choosing a search appearance and forcing the page into an unsuitable type.

A worked example
Keep the page, organization and person distinct.
Imagine a fictional company page whose approved information names the company, its website and its founder. This illustration is not a customer record or evidence of a search result.
- Company
- Describe the approved organization name and website. Do not infer an address or founding date to fill an empty field.
- Person
- The founder is a distinct subject. Confirm the intended person rather than relying on a matching name.
- Relationship
- A founder statement connects person and organization. Keep the direction and meaning of that accepted relationship.
- Page
- The page has its own URL and purpose. It is not the same thing as the organization it describes.
- Identifier
- A stable reference can connect descriptions of the same subject. It does not establish external recognition or a knowledge panel.
Use stable identifiers and organization and person descriptions for the focused tasks.

Begin with visible content
Code cannot repair an unsupported fact.
Check names, roles, dates, prices, availability and relationships against the accepted sources and what people can read on the page. A validator cannot tell you that a service is unavailable or that a review was invented.
Google’s structured data introduction describes markup as information about the page where it appears. Do not create a description of content the visitor cannot find there.
Choose applicable types and properties only after confirming the facts. Keep unknown values unknown. More nodes and properties do not automatically produce a more accurate or useful description.
The property evidence article connects proposed values with their supporting facts.

Find the publisher
Know which component controls each description.
A theme, SEO plugin, commerce system and custom component can each emit markup. A visible page edit may leave older values in another component’s output. Two descriptions can be syntactically valid while disagreeing about the same fact.
Inspect the current output before adding another publisher. Identify the component, its page scope, the subject it describes and the values it controls. Resolve the underlying factual conflict and maintenance responsibility.
A plugin’s presence does not establish which settings are active or what visitors receive. Check the published page and retain the source of each detail. Use markup ownership and graph conflicts for the operational review.

Run different checks
Syntax, facts and eligibility need separate answers.
- Syntax and vocabulary
- Can the description be parsed, and are the chosen types and properties appropriate? This does not verify the facts.
- Visible and factual agreement
- Does the description accurately reflect supported information on the published page, including relevant conditions?
- Consumer requirements
- Does the intended use meet the relevant consumer’s current requirements and content policies? Eligibility does not guarantee selection or display.
Record the exact candidate or URL, tool, date, output and unresolved warnings. An old result cannot certify a changed page. A planned validation is not a completed test.
The validation process and validity and rich result eligibility explain those separate checks.

Maintain the description
Recheck dependent values when the facts change.
A changed role, name, offer, price or date can invalidate an earlier description while the code remains well formed. Find the values and components that depend on the change, then update and inspect their published output together.
Keep the previous version and the reason for the correction. If a detail becomes disputed, do not manufacture consistency by repeating its old form. Assign who can resolve the question and what should prompt another review.
Use the type that fits the real content: a page, article, person, organization, product or service can have different requirements. Useful questions and processes can remain readable content without a search feature promise.
Use evidence and expiry for maintenance, and return to entity identity and facts when the underlying subject is unclear.

Choose your next question
View the focused articles.
Choose the explanation that matches the decision in front of you. You can enter at any point.
structured data purpose and formats
Continue with the focused explanation and examples for this task.
stable entity identifiers
Continue with the focused explanation and examples for this task.
person and organization identity
Continue with the focused explanation and examples for this task.
facts and property evidence
Continue with the focused explanation and examples for this task.
Page, site and breadcrumb descriptions
Continue with the focused explanation and examples for this task.
article descriptions
Continue with the focused explanation and examples for this task.
real products and services
Continue with the focused explanation and examples for this task.
Generator ownership and conflicts
Continue with the focused explanation and examples for this task.
validation process
Continue with the focused explanation and examples for this task.
validity and rich result eligibility
Continue with the focused explanation and examples for this task.
FAQ and process markup
Continue with the focused explanation and examples for this task.
evidence and expiry
Continue with the focused explanation and examples for this task.
Identity across pages
Maintain the descriptions that share a fact.
Work with Semantec SEO
Commission a structured data review
Semantec SEO can examine supported page facts, current markup and its publishers, then agree the descriptions, changes and validation work your project needs.
