Direct answer

Define one accurate Organization object on the homepage or principal organization page, give it a stable identifier, and reference that same identity from relevant Article, WebSite, Product and publisher objects.

What to remember
  • Use the most specific accurate organization type rather than the type with the most attractive feature.
  • Generate organization facts from one controlled source of truth.
  • Reuse one stable organization identifier across relevant structured-data objects.
  • Keep logos, profile references, addresses and merchant policies accurate and crawlable.

01

Definition

Organization structured data describes the business, institution, publication, nonprofit, or other organization responsible for a site or service.

Google’s current Organization documentation says homepage markup can help it understand administrative details and distinguish an organization from similarly named entities. Some properties support disambiguation, while others can influence visual elements such as a logo in search features or a knowledge panel. Google lists no universally required Organization properties and recommends adding the properties that are relevant and accurate. Organization structured data[1]

The objective is not to publish every field schema.org permits. It is to define one stable entity and reuse that identity consistently.

A minimal graph can be modeled as:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Example Company",
  "url": "https://www.example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://www.example.com/media/logo.png"
  }
}

02

Mechanism

Choose the most specific accurate type

Possible types include:

  • Organization
  • Corporation
  • EducationalOrganization
  • GovernmentOrganization
  • NewsMediaOrganization
  • NonprofitOrganization
  • OnlineBusiness
  • LocalBusiness and its subtypes

Use the most specific supported type that accurately describes the entity. Do not select a type because its search appearance looks attractive.

Create one stable identity

A stable @id allows other page objects to refer to the same organization.

Example:

https://www.example.com/#organization

That identifier is not necessarily a public page fragment users must visit. It is a graph identifier under the organization’s canonical domain.

Reuse it in relevant objects:

{
  "@type": "Article",
  "publisher": {
    "@id": "https://www.example.com/#organization"
  }
}

Avoid generating different organization identities on every page:

/page-a/#publisher
/page-b/#organization
/about/#company
/home/#brand

unless those identifiers truly describe different entities.

Use one source of truth

Generate the organization object from controlled data:

  • Legal or public name
  • Alternate name
  • Canonical URL
  • Logo URL
  • Contact information
  • Address
  • Founding date
  • Tax or business identifiers when appropriate
  • Industry classification
  • Same-as profiles
  • Merchant policies

The visible About, Contact, footer, policy, and merchant information should agree with the object.

Google’s general guidelines require structured data to remain accurate, current, visible where applicable, and nonmisleading. General structured data guidelines[2]

Place the principal definition deliberately

Google recommends Organization data on the homepage or a single page describing the organization rather than requiring it on every page.

A practical pattern is:

  • Full Organization object on the homepage
  • References to its stable @id from Article, WebSite, Product, or other relevant objects
  • No duplicate full objects from multiple plugins

Sitewide duplication is not automatically harmful, but it increases the chance of conflicting names, logos, addresses, and IDs.

Treat the logo as a real crawlable asset

Use a stable image URL that:

  • Returns successfully
  • Is crawlable and indexable
  • Represents the organization
  • Is not a tiny tracking asset
  • Has sufficient resolution
  • Remains available across redesigns
  • Uses the preferred host and protocol

Google currently recommends a logo at least 112 by 112 pixels and supports common image formats. The image should look correct on a white background unless a feature documents another treatment. Organization structured data[1]

Use sameAs carefully

Link to profiles or identity pages that genuinely represent the same organization.

Good candidates:

  • Official social profile
  • Official business registry profile
  • Authoritative knowledge or directory entry controlled by the organization
  • Official app-store publisher page

Do not add every citation, review, news article, reseller, or unrelated directory page.

03

Examples

Publication entity

A news publisher can use NewsMediaOrganization with:

  • Stable organization ID
  • Publisher name
  • Canonical homepage
  • Logo
  • Contact or ethics pages where relevant

Articles then reference the publisher ID.

Local company with several locations

The parent company may be an Organization, while each public location is a LocalBusiness with its own address, telephone, hours, map, and stable ID.

Do not represent every branch as the same single local address.

Brand and legal entity differ

A company may operate under a public brand.

Use:

  • name for the primary public identity when appropriate
  • legalName for the formal entity
  • alternateName for established variants

Keep the visible site language and business records coherent.

Plugin conflict

One SEO plugin emits:

Example Incorporated

Another emits:

Example Co.

A theme emits a third logo and a different @id.

The page may remain parseable while the graph becomes ambiguous. Assign one component ownership of the principal entity and remove conflicting duplicates.

Merchant policies

Google’s product guidance recommends nesting applicable return-policy and loyalty-program data under Organization markup. Keep those policies generated from the same system used on visible policy pages and commerce feeds.

04

Boundaries

Organization markup cannot:

  • Guarantee a knowledge panel
  • Force Google to use a particular logo
  • Verify a business by itself
  • Replace legal registration
  • Hide conflicting public information
  • Turn an unrecognized brand into a known entity instantly
  • Control every search feature

The audit should evaluate the complete public identity rather than treating the JSON object as an isolated technical artifact. Conflicts between markup, visible policies, business profiles, merchant feeds, and canonical pages are operational evidence that the source data lacks clear ownership.

Audit these failure cases:

  • Different @id on every page
  • Staging hostname in IDs or image URLs
  • Logo blocked by robots or authentication
  • Outdated address
  • Fake sameAs links
  • Organization type selected for appearance rather than accuracy
  • Local branch details attached to the parent entity
  • Publisher references point to a missing object
  • Several plugins emit conflicting organizations
  • Merchant policy differs from the visible policy
  • Home page canonical points elsewhere

Use Product Structured Data when merchant identity connects to offers, shipping, returns, and product eligibility. Use Breadcrumb Structured Data for navigational hierarchy, and JSON-LD vs. Microdata vs. RDFa for implementation ownership.

A strong entity graph is boring in the best way: one organization, one stable identifier, consistent facts, and clear references from the pages it actually publishes or operates.

References

Sources behind this record

  1. Organization structured data — Google (accessed August 1, 2026)
  2. General structured data guidelines — Google (accessed August 1, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.

Claim limit

Organization markup can support entity understanding and visual search features, but it cannot guarantee a knowledge panel, force a specific logo, or replace external verification.