Organization schema is the schema.org type used to describe a company, institution, agency, or other group as a single entity, normally published as JSON-LD on the organization’s home page. One well-formed Organization node with a stable identifier does two jobs: it states the facts a search engine would otherwise have to infer from page text, and it becomes the node every other piece of markup on the site references as publisher, employer, seller, or provider.
The property set that matters
schema.org defines well over a hundred properties on Organization through inheritance from Thing. A small subset carries almost all of the value.
Identity and naming. name is the legal or commonly used name. legalName is the registered form where it differs (“Northgate Analytics Ltd” against a trading name of “Northgate”). alternateName include acronyms, former names, and the abbreviations people actually search, and accept multiple values. description is a plain sentence or two about what the organization does. url is the canonical home page, and it should be the single canonical form, with or without www, matching the site’s own canonical tags.
Images. logo takes a URL or an ImageObject and is the property Google reads for the organization logo feature. image is the more general property for photographs of the organization or its premises. Keeping them distinct avoids a cropped office photo being treated as a logo.
Identifiers. sameAs links the entity to reference pages that identify it, which is the property covered in detail in sameAs schema. Alongside it, schema.org defines specific registry properties: vatID for a VAT registration number, taxID for a national tax identifier, duns for a D-U-N-S number, leiCode for a Legal Entity Identifier, naics for a NAICS industry code, globalLocationNumber for a GS1 GLN, and iso6523Code for an ISO/IEC 6523 identifier of the form ICD:identifier. For anything without a dedicated property, identifier accepts a PropertyValue with propertyID and value.
Contact and location. address takes a PostalAddress, never lose fields on the Organization itself. telephone and email are available directly on Organization, but a contactPoint holding one or more ContactPoint nodes is the better structure once there is more than one route in, because each point can carry contactType, areaServed, and availableLanguage.
Structure and history. founder takes a Person (or another Organization), foundingDate takes an ISO 8601 date, and foundingLocation takes a Place. numberOfEmployees takes a QuantitativeValue, so it expresses a range rather than a bare number. parentOrganization and subOrganization model corporate hierarchy, and memberOf covers trade bodies and accreditors. knowsAbout states subject expertise and is available on Organization as well as Person.
Two notes on properties people expect and will not find. There is no socialProfile property; social accounts go in sameAs. And aggregateRating on an organization describes ratings the organization collected about itself, which is exactly the self-serving review markup search engines discount, so it is best left off.
Choosing the right subtype
Organization works for anything, and the more specific type works better. schema.org types inherit, so CollegeOrUniversity is an EducationalOrganization, which is an Organization, which means every consumer that understands Organization still understands the narrower type, while consumers that understand the subtype gain extra properties and a sharper class assignment.
| Type | Use for | Adds |
|---|---|---|
Organization | Anything that does not fit a subtype, holding companies, non-trading entities | Base property set |
LocalBusiness | Any entity serving customers at a physical location | openingHoursSpecification, priceRange, geo, hasMap |
Corporation | Publicly traded or incorporated companies | tickerSymbol |
EducationalOrganization | Schools, colleges, universities, training providers | alumni, plus CollegeOrUniversity and HighSchool subtypes |
NGO, GovernmentOrganization | Non-profits and public bodies | Class assignment only |
OnlineStore | Retailers with no physical premises | Retail-oriented properties on OnlineBusiness |
Picking the specific subtype matters because the type is a claim about what kind of thing the entity is, and that claim is the part a knowledge graph uses to decide which other entities it resembles and which properties make sense on it. It also decides eligibility: local business features depend on a LocalBusiness type with an address, and no amount of correct Organization markup substitutes. Where a type is genuinely two things, such as a university that also runs a hospital, an array of types (["CollegeOrUniversity", "MedicalOrganization"]) is valid JSON-LD. Use it sparingly, since it makes the entity harder to reason about, not easier.
The @id convention
The Organization node should be declared once, on the canonical home page, with an @id built from that URL plus a fragment:
{ "@id": "https://example.com/#organization" }
The fragment matters. https://example.com/ identifies a web page; https://example.com/#organization identifies the organization, which is a different kind of thing. Without the fragment, markup ends up asserting that a company is a WebPage. #organization is the widely used convention, and any stable fragment works as long as it never changes, because changing it creates a second entity.
Every other block on the site then references the node instead of repeating it:
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/blog/data-contracts/#article",
"headline": "Writing data contracts that hold up",
"datePublished": "2026-04-02",
"publisher": { "@id": "https://example.com/#organization" },
"author": { "@id": "https://example.com/authors/jane-doe/#person" }
}
Because consumers merge every JSON-LD block on a page into one graph, and merge across the site by identifier, the reference resolves to the full node. Repeating the whole Organization object on every page instead produces near-duplicate copies whose small differences read as contradictions, and the usual cause is two plugins each emitting their own version. Pick one source of truth for the node and disable the other. JSON-LD covers the mechanics of nodes, references, and merging, and the underlying model uses triples: subject, predicate, object.
Complete example
The block below is the full pattern for a fictional company, published on the home page inside a <script type="application/ld+json"> tag. Every value is illustrative.
{
"@context": "https://schema.org",
"@type": "Corporation",
"@id": "https://example.com/#organization",
"name": "Northgate Analytics",
"legalName": "Northgate Analytics Limited",
"alternateName": ["Northgate", "NGA"],
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/assets/logo.png",
"width": 512,
"height": 512
},
"image": "https://example.com/assets/office.jpg",
"description": "Northgate Analytics builds data quality tooling for public-sector reporting.",
"foundingDate": "2014-03-11",
"founder": {
"@type": "Person",
"@id": "https://example.com/about/team/dana-reyes/#person",
"name": "Dana Reyes"
},
"numberOfEmployees": {
"@type": "QuantitativeValue",
"minValue": 50,
"maxValue": 100
},
"vatID": "GB123456789",
"iso6523Code": "0060:123456789",
"identifier": {
"@type": "PropertyValue",
"propertyID": "Companies House",
"value": "09123456"
},
"address": {
"@type": "PostalAddress",
"streetAddress": "12 Northgate Street",
"addressLocality": "Leeds",
"addressRegion": "West Yorkshire",
"postalCode": "LS1 4AB",
"addressCountry": "GB"
},
"contactPoint": [
{
"@type": "ContactPoint",
"contactType": "customer support",
"telephone": "+44-113-496-0100",
"email": "support@example.com",
"areaServed": ["GB", "IE"],
"availableLanguage": ["English"]
},
{
"@type": "ContactPoint",
"contactType": "sales",
"telephone": "+44-113-496-0101",
"email": "sales@example.com"
}
],
"parentOrganization": {
"@type": "Organization",
"@id": "https://parent.example.org/#organization",
"name": "Northgate Group"
},
"knowsAbout": ["Data quality", "Public sector reporting", "Data contracts"],
"sameAs": [
"https://www.wikidata.org/wiki/Q00000",
"https://www.linkedin.com/company/northgate-analytics/",
"https://github.com/northgate-analytics"
]
}
Minimal example
Most of the value is in the first six properties. A site with nothing else should publish this and stop:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Northgate Analytics",
"url": "https://example.com/",
"logo": "https://example.com/assets/logo.png",
"sameAs": ["https://www.linkedin.com/company/northgate-analytics/"]
}
Adding properties with uncertain or stale values is worse than leaving them out. An employee count from four years ago and a phone number that rings out are both statements the site is making about itself.
Merchant and return policy properties
schema.org and Google both define Organization-level properties aimed at retailers. hasMerchantReturnPolicy attaches a MerchantReturnPolicy to the organization so a return window applies across a catalog rather than being repeated on every Offer, and Google’s merchant listing documentation describes how organization-level shipping and return details are consumed. These are meaningful for a store selling products. For a consultancy, a university, or a publisher, they describe nothing, and adding them because a checklist mentioned them produces markup with no referent.
The wider point applies to every property here. What a search engine currently supports, and which properties are required, recommended, or ignored for a given feature, changes over time and is documented per feature rather than per type. The documentation is the source of truth; a page like this one describes the vocabulary and the patterns. Nothing in Organization markup is a ranking factor, and none of it guarantees a rich result. Features such as the organization logo or a merchant listing are eligibility, and eligibility depends on Google’s current supported-features list plus its own quality assessment.
For developers
Generate the node from the same configuration that renders the site footer and contact page, so a changed address changes in one place. Hand-maintained JSON-LD drifts from the visible page within a release or two.
Because the node is RDF, you can validate it structurally rather than by eye. Loading the site’s markup into a graph and running a SHACL shape that requires name, url, logo, and a well-formed PostalAddress turns a review step into a test. The schema.org vocabulary is itself published as RDF, so a check can confirm every property used is actually declared on the type in use rather than merely spelled plausibly. That approach, and the tools for it, are covered in structured data testing tools.
For SEOs
An Organization node anchors entity work on a site. It gives the organization one identifier, one name, one address, and one set of external identifiers, and it gives every article, product, and service page something to reference. Without it, each page implies its own faint version of the publisher.
Two checks catch most problems. First, search the rendered HTML of several page types for "@type": "Organization" and confirm exactly one node with the canonical @id appears per page. Second, compare name, address, and telephone in the markup against the business profile, the footer, and the main external directories. Consistency across sources is what makes an entity resolvable, as described in entity SEO and what is an entity.
Related pages
FAQ
What is Organization schema used for?
Organization schema describes a company, institution, or other group as a single entity in machine-readable form, normally as JSON-LD on the home page. It explicitly states the name, URL, logo, address, contact details, and external identifiers, and it creates one node that the rest of the site’s markup can reference as publisher, employer, or seller instead of repeating those facts.
Should Organization schema go on every page?
Declare the full node once, on the canonical home page. Other pages should reference it by @id rather than repeat it, because duplicate copies with small differences read as conflicting statements about the same entity. Some setups emit the node site-wide with an identical @id, which is harmless as long as every copy is byte-identical.
Organization or LocalBusiness: which type should I use?
Use LocalBusiness when the entity serves customers at a physical location, since local features depend on that type, and it adds opening hours, price range, and geo coordinates. Use Organization, or a subtype such as Corporation or EducationalOrganization, when there is no customer-facing premises. LocalBusiness is a subclass of Organization, so choosing it doesn’t lose anything.
Does Organization markup get you a knowledge panel?
No. Organization markup makes a site’s claims about itself explicit and consistent, which helps a search engine match the site to an entity, but panels come from entities Google holds and corroborates across independent sources. Markup is one input among many; it is not a ranking factor, and no property guarantees a panel or a rich result.
Sources and further reading
- schema.org, Organization: https://schema.org/Organization
- schema.org, ContactPoint: https://schema.org/ContactPoint
- schema.org, PostalAddress: https://schema.org/PostalAddress
- Google Search Central, Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
- Google Search Central, Local business structured data: https://developers.google.com/search/docs/appearance/structured-data/local-business
- Google Search Central, Structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies