Types, properties and values
Choose schema types and properties from supported facts.
Read the type hierarchy, the property’s owner and its expected content. Keep an evidence record so readable data also says something accurate.
Free learning from Semantec SEO.
Choose the thing before choosing its properties.
A type names the kind of thing being described. A property states something about that thing or connects it to another thing. A property’s content can be text, a number, a URL, a date, an enumeration or another typed node, depending on the term and the consuming system. Begin by identifying the thing, not by collecting attractive-looking fields.
Schema.org arranges types in an inheritance hierarchy. An Article is a kind of CreativeWork, which is a kind of Thing. It can use properties inherited from broader types as well as those associated with its more specific role. Some types have more than one parent: LocalBusiness relates to both Organization and Place. An inherited property still needs a truthful, relevant fact behind it.
Do not choose a more specific type merely because it offers a desired search appearance. A service explanation does not become a Product by adding a price field, and a person’s profile does not become the Person itself. When the visible purpose is unclear, settle that description before writing data. The Schema.org data model is the reference for how types and properties relate.
Read domains and expected types without overclaiming strictness.
On a property page, “Used on these types” indicates the kinds of subjects for which the property is intended. “Values expected to be one of these types” indicates the intended kinds of objects. These correspond to the vocabulary’s domainIncludes and rangeIncludes descriptions. Read both directions: which thing owns the property, and what kind of thing or literal should follow it?
Schema.org is deliberately flexible. Its introductory documentation allows text or URLs in places where a richer embedded description might be expected. Its expected types are not the same as a closed database constraint. A general checker accepting text does not mean the text expresses the intended relationship well or satisfies a platform feature’s stricter requirements.
For example, Article.author can describe a Person or Organization. A supported Person object with a name and stable ID communicates more precisely than an ambiguous byline string when that identity has been established. Do not create a detailed object with invented biography fields just to make it appear complete. Prefer the most faithful supported description and inspect current consumer requirements separately.
Distinguish identity, location and a descriptive label.
An @id identifies the node in JSON-LD. The url property gives the location of a page for the item. The name property supplies a label. These jobs differ even when they use similar strings. A person can keep one stable @id while being described on a profile page and credited on many article pages.
The url property expects a URL. A sentence such as “our award-winning agency homepage” is not a page address, and the adjective adds an unsupported claim. A syntactically plausible invented address is no better: the destination must be the approved location of the described item. Resolve canonical ownership and redirects before encoding it.
For external identity, sameAs points to a reference page that unambiguously identifies the same item. It does not mean “related topic,” “source I cited” or “prestigious site I would like associated with this business.” A founder’s profile and the founder’s employer are different things, even if their pages discuss one another.
Work through a URL property decision.
This example is fictional. A studio’s approved visible page says its name is Example Studio and links to its own homepage at https://example.com/. The draft proposes the name correctly but writes url as “the best creative studio online.” The issue is both semantic and evidential: the url field needs an address, while “best” is an unsupported superiority claim.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Studio",
"url": "https://example.com/"
}The corrected educational description uses the stipulated homepage URL and drops the unsourced adjective. It does not add sameAs because no external identity reference was supplied. It does not invent an address, award or registration number. The original phrase can remain outside the graph only if a separate editorial review finds a supported reason for it; fixing the property does not approve the marketing claim.
| Question | Evidence | Decision |
|---|---|---|
| Which entity owns url? | The described Organization is Example Studio | Keep the property on that organization node |
| What kind of content belongs here? | Schema.org url describes the item’s URL | Use its approved page address |
| Is the destination supported? | Fictional brief explicitly stipulates https://example.com/ | Use that reserved example address only in this illustration |
| Can we infer sameAs? | No external identity page supplied | Omit; do not guess |
| What remains to check before real use? | Real page and real owner are outside this example | Check final URL, visible identity and all emitters |
This is a deliberate URL example, not a claim that every Schema.org property forbids text. Read each property’s definition and expected types. An ISO date, a numeric amount, an enumeration URL and an organization node each carry different meaning; replacing all of them with loose prose would erase distinctions that the description needs.
Carry every proposed fact in an evidence ledger.
A useful property evidence ledger names the node, property, intended content, visible support, controlling source, applicable market or version, effective date, reviewer, status and expiry trigger. Keep a reason for accepting or holding a record. The ledger makes later changes inspectable rather than leaving the data author to reconstruct the source from memory.
The following is a fictional software page review. It preserves the practical distinction between supported product identity, a volatile offer and unsupported ratings. None of these rows describes a live Semantec offer or a real user rating.
| Node and property | Proposed content and support | State and reason | Owner and reopening trigger |
|---|---|---|---|
| SoftwareApplication.name | Example Planner; visible product heading agrees with approved product record | Accept identity field; no feature eligibility implied | Product owner; rename or product split |
| Offer.price | A stated price appears on a separate current pricing page; this product page does not show the offer scope | Hold until the correct offer page, currency, conditions and current source are confirmed | Pricing owner; price, market or access change |
| AggregateRating.ratingValue | Draft proposes 4.9; no visible review set or controlling source exists | Reject invented rating; do not manufacture reviews | No accepted rating owner; only new genuine permitted evidence can reopen |
| SoftwareApplication.operatingSystem | Draft says all systems; no tested compatibility list supports it | Hold compatibility claim; narrower supported facts may replace it | Technical owner; documented release and test evidence |
| Organization.url | Approved publisher identity links to its own homepage | Accept URL only after final destination and entity match checks | Site owner; move, redirect or ownership change |
A price row should retain currency, billing basis, market, availability and applicable conditions when they affect the offer. A correct number stripped of its scope can mislead. When sources conflict, hold the field and resolve the controlling record rather than averaging conflicting prices or choosing the most persuasive one.
Separate parsing, vocabulary fit and evidence approval.
Parsing checks if the data is structurally readable. Vocabulary review checks if types, properties and relationships express the intended thing. Evidence review checks if the asserted facts are true, current and within scope. A platform test checks the supported feature’s own requirements. None substitutes for the others.
A field can pass a syntax check and still belong to the wrong node. For example, founder is defined for an Organization and identifies a Person or Organization that founded it. Putting founder on the Person and pointing it at the employer reverses the intended relationship. Consult the current founder definition, not a copied block that merely parses.
Consumer-specific rules may be narrower than Schema.org’s broad model. Check the current search data policies and the relevant feature documentation before making eligibility claims. A vocabulary checker is not evidence of approval by a search platform, and no clean test guarantees display.
Keep the evidence and data in step as the page changes.
Assign source ownership to facts that can expire independently of the template. A product rename, price revision, staff departure, corrected author credit or changed URL can invalidate a previously accepted property. Record the trigger and review the affected graph references. Suppress a stale optional field while the evidence is unresolved rather than retaining confident old data.
For a real handoff, provide the accepted and held ledger rows, controlling sources, node IDs, reviewer, dates, exceptions and next responsible owner. The developer should receive decisions that can be checked, not a wish list of properties to fill. Test the final delivered output and inspect other emitters for conflicts after an authorized release.
The structured data hub connects this property-level work to formats and identity. The learning overview returns to page purpose and source context when the visible facts themselves need repair.