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.

Website page beside organized identity cards, a magnifying glass and large cobalt braces.

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.

Three separate organizers hold identity cards, blue braces and a plain presentation card.

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.

A company card and person card connect above a source folio beside an empty fact slot.

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.

An owner badge stands in front of a page folio and source folders.

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.

A review notebook, source card and magnifier sit beside an amber update tab.

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.

Website page beside connected metadata tiles and a search result panel.

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.

Magnifying glass over grouped source pages and related subject markers.

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.

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.