Organization Schema

TL;DR — Organization schema is a small block of code that tells search engines who your business is — your name, logo, official website, and social profiles. Unlike most schema, it describes your company itself, not the content on a page. It helps Google recognize and correctly identify your brand, and it may influence display elements like the info box (a “Knowledge Panel”) some brands get in search. It does not guarantee that panel, and it does not make you rank higher.

What Organization schema is

Most schema markup describes what’s on a page — a product’s price, a recipe’s cook time, a review score. Organization schema is different. It describes the business behind the whole site: your name, your logo, your official URL, your social accounts, sometimes your address and contact details.

It uses the shared schema.org vocabulary, written as a block of code (JSON-LD) that sits in the page without changing how it looks. When Google reads it, the message is essentially: “This is who we are.”

Why it’s worth adding

Its main job is helping search engines identify your brand and tell it apart from other companies with similar names. Google’s own language is deliberately bounded: adding this markup “can help Google better understand your organization’s administrative details and disambiguate your organization in search results,” and some properties “can influence visual elements in Search results” — things like which logo shows up, or details in the Knowledge Panel, the info box with a logo, links, and details that some brands get on the right side (or top) of search results.

“Can help” and “can influence” are not guarantees. Google doesn’t create a Knowledge Panel just because the markup exists — panel display depends on how well-known and well-corroborated the entity is across the web. Your markup is one input Google can use, not a switch that turns a panel on.

The things beginners get wrong

• It doesn’t guarantee a Knowledge Panel. Correct markup helps; it doesn’t force Google to show a panel.
• It’s not a ranking boost. Organization schema won’t move you up the results. Its purpose is identity and display, not ranking.
• Put it in one place, not everywhere. Google recommends the homepage or a single page that describes your organization, such as an “About” page, and says you don’t need it on every page of the site.
• The logo has a real minimum size: at least 112x112 pixels, and the image has to be reachable by Google (not blocked).

Want the full property list, the November 2023 expansion, how sameAs really works, and the exact failure modes? Switch to the Advanced tab.

TL;DR — Organization schema (schema.org/Organization, JSON-LD) describes the entity behind the site — name, logo, url, sameAs, plus administrative fields — and its documented job is disambiguation, and some properties can influence visual elements like Knowledge Panel/attribution UI — not ranking. Neither is guaranteed. Google says there are no required properties (add what’s relevant), and it recommends once on the homepage or an About page — Mueller compares site-wide duplication to review-markup spam. The logo needs to be ≥112x112px and crawlable/indexable. The November 2023 update folded the old Logo docs into Organization and added administrative fields (address, legalName, duns, leiCode, naics, iso6523Code, numberOfEmployees, foundingDate). The commerce-adjacent fields (hasMerchantReturnPolicy, hasMemberProgram, hasShippingService) came later, in separate 2024–2025 updates — not the 2023 batch. And the core myth to kill: markup ≠ guaranteed Knowledge Panel, and it’s not a ranking factor.

What Organization schema actually does

Google’s own framing is precise: adding Organization structured data to your home page “can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” Two words there matter — understand and disambiguate. This markup is how you tell an engine which “Acme” you are, separate from every other Acme, and hand it the administrative facts (logo, official links, identifiers) it uses to represent you.

Google also splits the properties by purpose: “Some properties are used behind the scenes to disambiguate your organization from other organizations (like iso6523 and naics), while others can influence visual elements in Search results (such as which logo is shown in Search results and your knowledge panel).” So the markup does two jobs — quiet identity confirmation, and a possible influence on visible UI like the logo and Knowledge Panel details. Neither of those is a ranking lever, and neither is a guarantee — Google’s own verbs are “can help” and “can influence,” not “will show” or “will rank.”

This is the entity layer of structured data. It sits alongside the Entity & Identity Schema hub, and its close relatives — LocalBusiness Schema (a subtype for businesses with a physical location and hours) and Person Schema (for individuals and authors) — do the same identity job for different entity types. Organization is the one you use for the company or brand itself.

No required properties — add what’s relevant

This surprises people: Google states “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.” A sparse-but-accurate block (name, logo, url, a few good sameAs) is legitimate and often better than a padded one stuffed with guessed identifiers. Google doesn’t name a defined “core,” but name, logo, url, and sameAs are a reasonable practical starting point — they’re the ones most tied to the visible/disambiguation elements Google describes.

Where to put it — and why not every page

Placement is a documented rule, not a preference: “We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don’t need to include it on every page of your site.”

John Mueller has reinforced this directly. His guidance is that Google only needs to find it somewhere obvious — the home page or contact/About page — and he warned against the site-wide instinct by comparison to review-markup spam: putting company markup on every page in the hope of getting an enhancement everywhere is the wrong mental model, the same mistake as sprinkling review stars across a whole site. (Paraphrased from Mueller’s comments as reported by Search Engine Journal; treat as a paraphrase, not a verbatim quote.)

The practical takeaway is unchanged: one instance, on the homepage or About page.

The full property list (and the November 2023 expansion)

Google’s supported Organization properties, as documented:

address · alternateName · contactPoint · description · duns · email · foundingDate · globalLocationNumber · hasMerchantReturnPolicy · hasMemberProgram · hasShippingService · iso6523Code · legalName · leiCode · logo · naics · name · numberOfEmployees · sameAs · taxID · telephone · url · vatID

The administrative batch — legal name, address, contact info, business identifiers (duns, leiCode, naics, iso6523Code), numberOfEmployees, foundingDate — arrived in November 2023, when Google folded the old standalone Logo structured-data page into the Organization documentation and expanded well beyond the original logo + url pair. Sites that already had logo + url markup didn’t need to change anything. (The November 2023 expansion is summarized from Google’s blog announcement, which couldn’t be re-fetched verbatim during research — treat the specifics as paraphrase.)

The commerce-adjacent objects are not part of that 2023 batch — each landed in its own, later update, confirmed against Google’s live search-updates history:

• hasMerchantReturnPolicy (organization-level return policies) — added June 11, 2024.
• hasMemberProgram (loyalty programs) — added June 10, 2025.
• hasShippingService (shipping policies) — added November 12, 2025.

Each of those has its own documentation, availability rules, and precedence behavior against product-level markup and Merchant Center settings. Valid Organization markup doesn’t by itself guarantee Merchant Center acceptance or Search display for any of them.

Group the rest roughly like this:

• Core identity: name, alternateName, legalName, url, logo.
• Contact / location: address, contactPoint, telephone, email.
• Business identifiers (disambiguation): duns, leiCode, naics, iso6523Code, globalLocationNumber, taxID, vatID.
• Profiles: sameAs.
• Org-level facts: numberOfEmployees, foundingDate.
• Commerce & membership (separately dated, see above): hasMerchantReturnPolicy, hasShippingService, hasMemberProgram.

sameAs: what it’s for, and what belongs there

sameAs is the identity-confirmation lever. Google’s own description: it’s “the URL of a page on another website with additional information about your organization” — its example is a social media or review-site profile page. Schema.org’s broader definition is a bit stricter: a reference page that “unambiguously indicates the item’s identity,” like a Wikipedia page, a Wikidata entry, or the official website. In practice, point it at pages that reliably represent your organization — official social accounts, Wikipedia, Wikidata, Crunchbase, LinkedIn — but neither definition requires you to literally own every URL; a page you don’t operate (a verified Wikipedia entry, for example) still qualifies if it unambiguously identifies you. The job is disambiguation, not link-building.

Two cautions. First, sameAs is not itself a ranking factor and does not guarantee a Knowledge Panel — it’s one corroborating signal among the many Google weighs. Second, a sameAs pointing at the wrong profile (a different company’s page, an unrelated Wikipedia entry) can actively confuse the entity match. Test your sameAs values as carefully as you’d test a canonical.

sameAs also gets confused with knowsAbout, which is a different property entirely: sameAs = identity (which entity you are), while knowsAbout = topical expertise (what the entity is knowledgeable about). They aren’t interchangeable and don’t do the same job.

Logo requirements and common failures

The logo has hard requirements: per Google’s docs, “the image must be 112x112px, at minimum. The image URL must be crawlable and indexable.” Where this silently fails:

• Too small — under 112x112px and it won’t qualify even if the JSON-LD validates.
• Blocked — the image URL is disallowed in robots.txt or behind a redirect chain Google can’t resolve, so it can’t fetch it.
• Wrong image — the markup points at something that isn’t your actual on-page logo.

A JSON-LD block can validate perfectly and still fail to produce the logo you wanted because the image didn’t meet these conditions.

Example JSON-LD

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Co",
  "legalName": "Example Company, Inc.",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.crunchbase.com/organization/example"
  ]
}

Place that once — homepage or About page. Add address, contactPoint, and identifiers only where they’re accurate.

Reusing the Organization node across your graph (optional)

If your site emits multiple JSON-LD nodes — a WebSite, a Person/author node, an Article publisher — you can give the Organization a stable @id and reference that same @id from the other nodes instead of repeating the full object:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Co",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

This isn’t a Google requirement — their docs don’t mandate an @id or any particular graph shape. It’s a graph-hygiene practice: one canonical Organization definition that other nodes point to, instead of several slightly different copies drifting out of sync. It doesn’t change ranking or eligibility on its own.

What Bing does

Bing supports schema.org markup (JSON-LD, Microdata, RDFa) and validates it against the declared types — if a value doesn’t match the expected data type, Bing’s crawlers ignore that annotation, so verify before publishing. Bing doesn’t appear to publish a dedicated Organization-specific reference comparable to Google’s; its general structured-data help is the closest official source. Treat the Bing side of this topic as modest in scope. (Bing’s guidance here is paraphrased from its Webmaster Tools help, which couldn’t be re-fetched verbatim during research.)

Validate before you ship

• Rich Results Test — checks the logo/organization elements Google can surface.
• Schema Markup Validator — validates the Organization type and all its properties, rich result or not.
• Google Search Console — monitor for structured-data errors post-deploy.

Validation confirms the markup is well-formed. It can’t confirm you’ll get a Knowledge Panel — that’s earned through broader corroboration, not markup alone.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/Organization (JSON-LD) describes the entity behind the site — name, logo, url, sameAs, plus administrative fields — not a page’s content.
• What it does: Google says it helps “understand your organization’s administrative details and disambiguate your organization in search results.” Some properties can influence visual elements like Knowledge Panel and attribution UI — without guaranteeing either. It is not a ranking factor.
• No required properties: Google explicitly says add what’s relevant; core recommended set is name, logo, url, sameAs. Sparse-but-accurate beats padded.
• Placement: once, on the homepage or About page — not every page. Mueller likens site-wide duplication to review-markup spam (paraphrased).
• Logo: must be ≥112x112px and crawlable/indexable; validating JSON-LD doesn’t help if the image is too small or blocked.
• November 2023 expansion: folded the old Logo docs into Organization and added administrative fields — address, legalName, duns, leiCode, naics, iso6523Code, numberOfEmployees, foundingDate. The commerce-adjacent objects came later, in separate updates: hasMerchantReturnPolicy (June 2024), hasMemberProgram (June 2025), hasShippingService (November 2025).
• sameAs: links to pages that reliably represent the organization (Wikipedia, Wikidata, LinkedIn, Crunchbase, official socials) for identity confirmation — not strictly limited to pages you own; not a ranking factor, doesn’t guarantee a panel, and a wrong target can conflate entities. Distinct from knowsAbout (topical expertise, not in Google’s current Organization property table).
• Knowledge Panel: earned through corroboration across trusted sources — markup is one input, never a guaranteed trigger.
• Related types: Entity & Identity Schema (hub), LocalBusiness Schema (physical location), Person Schema (individuals/authors).
• Validate: Rich Results Test + schema.org Validator + Search Console.

Official documentation

Primary-source documentation from the search engines.

Google

• Organization structured data — the core reference: definition, placement guidance, the “no required properties” line, disambiguation-vs-visual split, the full property list, and the 112x112px logo requirement.
• Introduction to structured data — JSON-LD recommendation and how Google uses structured data to understand entities.
• Expanding markup support for Organization details (Nov 2023) — the announcement that folded the Logo docs into Organization and added the administrative fields.
• Rich Results Test — checks the surfaceable organization/logo elements.
• Schema Markup Validator — validates the Organization type and every property.
• schema.org/Organization — the vocabulary itself.

Bing / Microsoft

• Bing Webmaster Tools — structured data help — Bing’s general support for schema.org / JSON-LD and its type-validation behavior.

Quotes from the source

On-the-record statements from Google’s Organization structured-data documentation. These were verified against the live docs page during research.

Google docs — what it’s for

• “Adding organization structured data to your home page can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” — Google Search Central, Organization structured data.
• “We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don’t need to include it on every page of your site.”
• “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.”
• “Some properties are used behind the scenes to disambiguate your organization from other organizations (like iso6523 and naics), while others can influence visual elements in Search results.”
• “The image must be 112x112px, at minimum. The image URL must be crawlable and indexable.” (on the logo)

Organization schema property reference

Recommended core (identity match + possible visual-element influence)

Other identity / contact properties

Business identifiers (disambiguation, added/expanded Nov 2023)

Org-level facts (added/expanded Nov 2023)

Commerce & membership (each added separately, later — not the Nov 2023 batch)

Fast facts

• No required properties — add what’s relevant; recommended core is name, logo, url, sameAs.
• Placement: Google recommends once, homepage or About page — not every page.
• Logo: ≥112x112px, crawlable and indexable.
• Purpose: disambiguation; some properties can influence visual elements like Knowledge Panel/attribution UI — not ranking, and neither is guaranteed.
• No guaranteed panel: markup is one input; panels are earned via corroboration.
• sameAs ≠ knowsAbout: identity vs. topical expertise (knowsAbout isn’t in Google’s current Organization property table).
• Validate: Rich Results Test + schema.org Validator.

Common mistakes (myths in practice)

The failure modes I see most often — each is a real way to waste effort or quietly break the markup.

1. Expecting a guaranteed Knowledge Panel. Correct, complete Organization schema does not force Google to create or update a Knowledge Panel. Panels are earned through corroboration across independent, trusted sources; your markup is one input, not a trigger. Ship the markup, then keep building the entity’s real-world footprint.

2. Putting it on every page. This is the most common structural mistake. Google’s docs say one instance — homepage or About page — is enough, and Mueller has compared the site-wide instinct to review-markup spam (paraphrased). Duplicating it everywhere buys you nothing.

3. A logo that fails silently. The JSON-LD validates, but the logo is under 112x112px, blocked in robots.txt, behind a broken redirect, or simply the wrong image. Google can’t use what it can’t fetch — validation of the markup says nothing about the image.

4. Wrong sameAs targets. sameAs should point at pages that reliably represent your organization (Wikipedia, Wikidata, LinkedIn, Crunchbase, official socials) — not strictly limited to pages you own. Pointing it at a different company’s page or an unrelated entry can conflate your entity with someone else’s — worse than leaving it out.

5. Treating it as a ranking lever. Organization schema’s documented purpose is disambiguation and visual/display elements, not organic ranking. Adding it (or filling every property) won’t move positions.

6. Padding every property with guessed data. There are no required properties. A sparse-but-accurate block beats one stuffed with invented identifiers or values you’re not sure about. Add what’s true and relevant; leave the rest out.

7. Marking up the wrong entity or page. Organization is for the company/brand itself. For a physical location with hours, use LocalBusiness Schema (a subtype); for an individual or author, use Person Schema. And put the block on a page that represents the organization (home/About), not on an arbitrary content page.

Validation tests

Test the published entity graph

Test to run — parse the live JSON-LD with the Schema Validator. Expected result — one coherent Organization identity with valid URLs and only supportable properties. Failure interpretation — plugins/templates emit duplicates or malformed values. Monitoring window — immediate. Rollback trigger — revert if the change breaks parsing or creates competing organization identities.

Test logo and identity references

Test to run — fetch the declared logo URL and review url and sameAs destinations. Expected result — every URL is public, successful, and belongs to the organization represented. Failure interpretation — an asset moved or an identity link is stale/unsupported. Monitoring window — immediate and after brand/domain changes. Rollback trigger — remove unsupported references rather than leaving misleading identity claims.

Test yourself: Organization Schema

Five quick questions on Organization schema, what Google uses it for, and the mistakes that break it. Pick an answer for each, then check.

Organization Schema

Organization schema (schema.org/Organization) is structured data that describes the business or entity itself — name, logo, official URL, social profiles, contact info, and identifiers — rather than a page's content. Google says it can help disambiguate your brand and some properties can influence visual elements like Knowledge Panel/attribution; it has no required properties and doesn't guarantee a Knowledge Panel.

Related: Schema Markup, Entity & Identity Schema, LocalBusiness Schema, Person Schema

Organization Schema

Organization schema is the schema.org/Organization structured-data vocabulary you add to a site — usually as JSON-LD — to describe the business or entity itself rather than any single page’s content. It carries your name, logo, official url, social and profile links (sameAs), contact and address details, and business identifiers like taxID, vatID, leiCode, and naics. Its documented job is to help Google disambiguate your organization from similarly named ones, and some properties can influence visual elements like Knowledge Panel and search-attribution UI — not to rank a page.

Two things trip people up. First, there are no required properties — Google says to add as many as are relevant to your organization, so a sparse-but-accurate block is fine. Second, placement is once, not everywhere: put it on your homepage or a single page that describes your organization (an About page), not on every template page. The logo you reference must be at least 112x112px and crawlable/indexable.

Organization schema does not guarantee a Google Knowledge Panel and is not itself a ranking factor. sameAs links help confirm your identity via authoritative equivalent profiles, but Google still needs corroboration across independent trusted sources before it creates or updates a panel.

Related: Schema Markup, Entity & Identity Schema, LocalBusiness Schema, Person Schema

Changelog