Organization Schema

How to implement Organization schema, what it actually does (disambiguation, not a guaranteed Knowledge Panel or a ranking factor), and the mistakes that quietly break it.

First published: Jul 1, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #10 in Structured Data#31 in On-Page#168 in Technical SEO#226 on the site

Organization schema (schema.org/Organization) is the JSON-LD block that tells search engines who your business is — name, logo, official URL, sameAs profiles, and identifiers. Google says it can help disambiguate your organization and that some properties can influence visual elements like a Knowledge Panel or attribution UI — it isn't a ranking factor and doesn't guarantee either. Google says there are no required properties (add what's relevant), and it recommends placing it once on your homepage or About page, not on every page. The logo needs to be at least 112x112px and crawlable. The big myth to kill: markup does not guarantee a Knowledge Panel and isn't a ranking factor. Google's November 2023 update folded the old Logo docs into Organization and added administrative fields (address, legalName, duns, leiCode, naics, numberOfEmployees, foundingDate); the commerce-adjacent fields (return policy, shipping, loyalty/membership) came later in separate 2024–2025 updates, not the 2023 batch.

TL;DR — Organization schemaOrganization 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. (schema.org/Organization, JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.) 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 PanelThe Knowledge Graph is Google's database of entities — people, places, organizations, and things — and the factual relationships between them. It's separate from any single website's structured data: your schema markup is one of many possible inputs to the graph, not the graph itself./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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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\"Entity & identity schema\" is a practitioner label — not an official Google or schema.org category, and not exhaustive of identity-capable schema.org types — for the three main types that declare who or what is behind a site: Organization, LocalBusiness, and Person. hub, and its close relatives — LocalBusiness SchemaLocalBusiness schema (schema.org/LocalBusiness) is structured data — usually JSON-LD — that describes a physical business to search engines: its name, address, phone, hours, geo-coordinates, and price range. Google requires only name and address, consumes about a dozen recommended properties, and treats it as a corroborating signal, not a substitute for a Google Business Profile. (a subtype for businesses with a physical location and hours) and Person SchemaPerson schema (schema.org/Person) is structured data that marks up an individual — most often an article's author, but also founders, staff, or the subject of a bio page. It helps search engines disambiguate which person an identity refers to and connect their content across the web; it is not a ranking factor and doesn't itself confer E-E-A-T. (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.

Evidence for this claim Google has no required Organization properties and recommends adding properties that apply to the organization. Scope: Google Search Organization documentation; accurate applicable data is preferred over irrelevant completeness. Confidence: high · Verified: Google: Organization structured data

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.

Evidence for this claim Google recommends placing Organization information on the home page or a single organization-focused page rather than every page. Scope: Google Search Organization implementation guidance. Confidence: high · Verified: Google: Organization structured data

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 CenterGoogle Merchant Center (GMC) is a free platform where retailers upload and manage product data so their products can appear across Google — Shopping, organic Search product grids, Images, Lens, and AI surfaces. Since 2020 it powers free (organic) product listings, not just paid Shopping ads. 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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor.’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-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. validates.
  • Blocked — the image URL is disallowed in robots.txt or behind a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. 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 crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — 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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.