Organization Schema: The Full Property Guide

Organization schema is the entity that everything else on your site ultimately references — the Article's publisher, the Person's employer, the LocalBusiness's parent brand. Get it right once, at the site level, and every other schema type on the site inherits a stable, verifiable identity to point back to. Get it wrong or leave it out, and every other type is left making claims about an organization that never disambiguated itself.

This guide covers the properties that actually matter, which ones are required versus optional in practice, and how to wire Organization schema into the rest of your site's entity graph rather than treating it as an isolated block.

Organization schema should be site-wide, not page-specific — it describes the entity behind the whole domain, not the entity behind any one page. The standard implementation pattern is one Organization node, defined once, given a stable @id (typically a URL fragment like https://example.com/#organization), and referenced by @id from everywhere else it's relevant: an Article's publisher property, a Person's worksFor property, a LocalBusiness's parentOrganization property. Repeating a full inline Organization object on every page is redundant and, worse, creates an opportunity for the values to drift out of sync between pages.

name is the organization's official name, matching what appears in your Google Business Profile and other verified listings — consistency across surfaces matters here, since mismatched names across a Knowledge Panel, GBP, and schema markup is a disambiguation problem, not a stylistic one.

url is the canonical homepage URL, and should match exactly what's set as canonical elsewhere on the site.

logo should be a full ImageObject (not just a bare URL string) with explicit width and height, hosted on your own domain rather than a CDN that could change. Google's Knowledge Panel logo requirements are specific about minimum dimensions and aspect ratio, so check current guidance before finalizing the asset rather than reusing whatever logo file happens to exist already.

sameAs is an array of URLs to the organization's verified profiles elsewhere — LinkedIn company page, X/Twitter, Crunchbase, Wikipedia if one exists, industry directories. This is the property doing the actual disambiguation work: it's what tells Google (and any AI system reading the page) that this entity and the entity behind those external profiles are the same thing, not just similarly named.

founder references a Person entity — ideally by @id if that Person also has their own schema elsewhere on the site — establishing the organization-to-individual relationship in both directions.

foundingDate adds a verifiable fact that strengthens the entity's overall profile, particularly useful for younger or lesser-known organizations trying to establish credibility.

address, using a nested PostalAddress type, matters more than it might seem for a purely online business, because it's one more verifiable, checkable fact tying the schema claims to a real-world entity rather than an anonymous domain.

contactPoint lets you specify support or sales contact details with a specific contactType, useful if the organization has structured contact routing worth surfacing to a search engine or AI system parsing the page.

description should be a concise, factual summary — not marketing copy — since this is one of the fields most likely to be pulled directly into a Knowledge Panel or AI-generated summary of the organization.

An Organization schema generator tool can be a reasonable starting point for a first draft — it saves typing out the JSON-LD skeleton by hand and reduces basic syntax errors. But treat generator output as a first draft, not a finished implementation. Most generators produce a generic template that won't include the @id referencing pattern needed to connect the Organization node to the rest of your entity graph, won't prompt you for a complete sameAs array, and won't know which properties matter most for your specific subtype (a ProfessionalService generator output looks different from a Product-brand Organization in practice, even though both start from the same base type). Run generator output through the Schema.org validator, then manually add the @id, the full sameAs array, and any subtype-specific properties the generator didn't ask about before treating it as done.

A well-built Organization schema markup block is one of several signals that can influence whether Google surfaces a Knowledge Panel for your organization name, alongside verified profiles like Google Business Profile and Wikipedia. Schema alone doesn't guarantee a Knowledge Panel — that decision depends on independent verification and entity prominence Google evaluates well beyond your own site's structured data — but a Knowledge Panel that does appear pulls fields directly from your Organization structured data where available: the logo, the description, some of the sameAs links surfaced as "profiles." Getting name, logo, and description right in the schema increases the odds those fields render correctly if and when a panel does appear, rather than Google falling back to whatever it scrapes from elsewhere.

The organization name property deserves its own note: consistency matters more than most people expect. If your Organization schema states one legal or trading name while your Google Business Profile, Wikipedia entry, and social profiles use a slightly different variant, that inconsistency is itself a disambiguation problem — it's one of the signals search engines and AI systems weigh when deciding whether separate mentions across the web refer to the same organization or different ones. Pick one canonical name string and use it identically everywhere the entity is referenced.

This is where implementations most often go wrong: picking the wrong subtype. Organization is the generic parent type and is always valid, but schema.org defines more specific subtypes — LocalBusiness for a business with a physical location customers visit, ProfessionalService for a services business (consultancies, agencies, professional practices) that may or may not have a public-facing location, Corporation for larger structured entities. Using the most specific accurate subtype rather than defaulting to generic Organization gives search engines and AI systems more precise signal about what kind of entity they're dealing with, which matters for eligibility on certain rich-result types that are subtype-specific (LocalBusiness-linked rich results, for instance, require a LocalBusiness type or subtype, not a bare Organization).

The value of a well-built Organization schema compounds specifically because of how many other types reference it. An Article's publisher, a Person's worksFor, a Product's brand or manufacturer, a Review's itemReviewed if the review target is the organization itself — all of these should point at the same @id rather than each carrying their own inline, potentially inconsistent copy of the Organization data. This is the same @graph pattern that applies across schema generally: one canonical node, referenced everywhere, rather than the same facts duplicated and gradually drifting out of sync across dozens of pages.

A handful of errors show up repeatedly in real audits. Duplicating the Organization block on every page with slightly different property values — often because different developers added it to different templates at different times — is the most common, and it directly undermines the disambiguation benefit schema.org Organization data is supposed to provide, since a search engine parsing conflicting copies of the "same" entity has to guess which one is authoritative. Leaving logo as a bare string URL instead of a full ImageObject is a frequent validator-flagged issue. Pointing sameAs at redirects, dead pages, or someone else's profile after a rebrand is a silent failure that only a manual link check catches. And using generic Organization when a more specific subtype clearly applies underuses the type system schema.org actually provides for exactly this situation.

Companies operating multiple distinct brands, or a parent company with several separately-branded subsidiaries, need more than one Organization node — flattening everything into a single generic Organization loses the actual corporate structure a search engine or AI system could otherwise use. The pattern that holds up: one parent Organization node with its own @id, and a subsidiaryOf or parentOrganization relationship linking each brand-level Organization back to it. Each brand-level node gets its own name, logo, sameAs array, and (where relevant) LocalBusiness locations, while still being explicitly connected to the parent entity rather than existing as an unrelated island. This is the same @graph and @id pattern used throughout structured data generally, applied at the corporate-structure level rather than the single-entity level — and it's worth the extra setup time for any company where the brand relationship isn't obvious just from the domain name alone.

Run the homepage (or wherever the Organization node lives) through the Schema.org validator and Google's Rich Results Test. Beyond basic validity, manually check that every sameAs URL actually resolves to a live, correctly-branded profile — a sameAs array pointing at a dead LinkedIn URL or the wrong company's Crunchbase page does active harm to disambiguation rather than helping it. This is a property that's easy to get syntactically right and factually wrong, and only a human check catches the second kind of error.