A business page may describe an organization, a location, an article, or a product in ordinary visible text. Structured data adds explicit machine-readable relationships to that information. Understanding it requires separating the vocabulary from the format that carries it, and separating both from a search platform’s feature rules. This reference explains those layers through Schema.org, the W3C JSON-LD 1.1 Recommendation, and Google Search documentation. It covers entities, properties, identifiers, business types, validation, and documented eligibility limits. It does not prescribe a search strategy or promise ranking changes. Google’s implementation requirements are platform-specific and can change independently of the underlying Schema.org vocabulary. Google Search Central — Introduction to structured data markup
Vocabulary, types, and properties
A vocabulary gives terms shared meanings. Schema.org organizes its vocabulary around types and properties: a type describes a kind of thing, and a property expresses an attribute or relationship. An Organization can have a name; an address can be represented as a related PostalAddress rather than as an undifferentiated sentence. These terms describe information, not visual page components. Schema.org data model
Schema.org permits types to inherit properties from broader types. LocalBusiness is both an Organization and a Place, reflecting organizational and location-related characteristics. A property’s documented expected types describe the kinds of values associated with it. Those vocabulary descriptions are not identical to a search engine’s required-property checklist. A term can be valid in Schema.org without enabling any particular search appearance. LocalBusiness vocabulary
Formats and JSON-LD 1.1
Google documents support for JSON-LD, Microdata, and RDFa. These are ways of expressing structured information, not competing business classifications. JSON-LD commonly appears in a script element with the application/ld+json media type; Microdata and RDFa can express annotations through HTML attributes. The vocabulary supplies the terms while the serialization determines how those terms and values are written. Google Search Central — Introduction to structured data markup
JSON-LD 1.1 is a W3C Recommendation dated 16 July 2020. Its @context maps terms to identifiers, @type identifies a node’s type, and @id can identify a node. A JSON object can therefore express more than an arbitrary collection of field names. These are JSON-LD language concepts; a consumer may support only the portions relevant to its own documented processing. JSON-LD 1.1
A context can let short property names stand for full identifiers. For example, the same familiar word could have different meanings under different contexts, so reading the property name without its context can lose information. JSON-LD processing resolves that mapping; it does not independently certify the statements expressed by the resulting graph. JSON-LD 1.1
Entities, identifiers, and relationships
An entity is the thing being described; a page is a document that may describe one or several entities. A hypothetical company and its physical office can be related without being treated as interchangeable. A stable identifier can distinguish that company from another organization with the same display name. This example illustrates representation only and does not describe an actual client or deployment.
In JSON-LD, a node with an @id can be referenced by that identifier elsewhere in the graph. This makes it possible to express relationships without repeating a full description every time. An identifier does not prove that claims about the entity are correct, and it does not force a search engine to merge records. Representation and factual verification remain separate matters. JSON-LD 1.1
Organization and LocalBusiness descriptions
Organization describes an organizational entity, while LocalBusiness adds the meaning of a particular physical business or branch. Schema.org defines more specific LocalBusiness subtypes, including Restaurant and Store. A type communicates what the described thing is; it is not a request for a particular search layout. The visible page and the entity description still need to refer to the same subject. LocalBusiness vocabulary
Google maintains separate documentation for Organization and LocalBusiness. Its Organization reference currently lists no universally required properties, while its LocalBusiness reference identifies name and address as required properties for that documented feature. Other properties and subtype-specific rules are described separately. These are consumer-specific requirements, not a claim that Schema.org itself makes every business property mandatory. The verified pages display updates dated 8 September 2026. Organization documentation Google Search Central — Local business structured data
Implementation and content correspondence
Implementation places machine-readable statements where a consumer can process them. Google can process supported JSON-LD in a page’s head or body, and it documents handling dynamically injected markup when that markup is available during rendering. The method of insertion does not remove the requirement that the information describe the page accurately. A syntactically correct object can still contain false or irrelevant statements. Google Search Central — Introduction to structured data markup
Google’s general policies require structured data to represent the page’s main content and prohibit misleading markup. Information described in the markup ordinarily needs to be available to readers, subject to the feature’s documented rules. Markup for unrelated or hidden claims can therefore fail policy requirements even when a parser accepts it. Technical accessibility and content correspondence are distinct checks. Structured data policies
Syntax, vocabulary, and feature validation
Validation occurs at several layers. JSON parsing checks whether the serialization is well formed. Vocabulary validation examines recognized types, properties, and values. A feature-specific test checks the requirements of a particular consumer. These questions overlap but are not equivalent: a recognized Schema.org type can be outside Google’s supported rich-result features, and valid JSON can express an incomplete entity description.
The Schema Markup Validator examines Schema.org markup, while Google’s Rich Results Test evaluates eligibility for supported Google rich-result types. A test result is evidence about the submitted code or fetched page at that time, not proof of all sitewide implementations. Google also notes that automated tests cannot detect every quality issue. A passing result does not establish the truth of business facts. Schema Markup Validator Rich Results Test Structured data policies
Search-feature requirements and limitations
For Google features, required properties, applicable policies, and access to the page are separate prerequisites. Recommended properties can add information without becoming universal requirements. Google explicitly does not guarantee rich-result display even when markup passes testing. Search context and other platform decisions affect presentation, so eligibility describes a possible outcome rather than a promised appearance. Google Search Central — Introduction to structured data markup
Search-feature documentation changes independently of Schema.org releases and JSON-LD versions. An implementation can remain meaningful vocabulary while a consumer changes feature support. The crawling reference separately explains retrieval and indexing controls; neither operation is guaranteed by structured data. The search visibility service describes commercial work outside this reference’s scope. The distinctions here concern documented representation and eligibility, not which marketing discipline to prioritize.
Frequently asked questions
Is Schema.org the same as JSON-LD?
No. Schema.org supplies a vocabulary of types and properties. JSON-LD is a format that can express that vocabulary and other linked-data vocabularies. Schema.org data model JSON-LD 1.1
Does valid markup guarantee a rich result?
No. Google distinguishes technical validity, policy compliance, and search presentation. Passing a test does not guarantee an enhanced result. Structured data policies
Can LocalBusiness represent an individual branch?
Yes. Schema.org describes LocalBusiness as a particular physical business or branch of an organization, combining Organization and Place characteristics. LocalBusiness vocabulary
Does Organization have the same required fields as LocalBusiness?
Not in Google’s documented requirements. Its Organization page lists no required properties; its LocalBusiness feature requires name and address. These are platform-specific requirements. Organization documentation Google Search Central — Local business structured data
Can a validator confirm that business information is true?
No. Validation can inspect syntax, vocabulary, and supported feature requirements. It does not independently verify that an address, opening schedule, or organizational relationship matches reality. Content accuracy remains a separate condition.