Structured data mastery

Organization schema: brand identity in structured data

Organization schema is where a brand's identity lives in the AI-readable layer — logo, social profiles, contact points, and the cross-references that connect a product to its company. The block most Shopify stores ship as a stub or skip entirely.

11 min read Updated May 10, 2026

A product without a brand is a product the buyer cannot trust. An AI surface ranking shopping queries treats a product page’s Product block as one half of an answer; the other half is the Organization block that identifies the company behind the product. Most Shopify catalogs ship the Product block well-populated and the Organization block either as a thin stub or not at all.

This guide is the operator’s reference for the Organization schema. The properties that matter, the properties to populate first, the Shopify-specific implementation patterns, and the failure modes that suppress brand-identity signals across the catalog.

Organization and the closely-related Brand are not the same; the difference comes up repeatedly and is worth handling first.

Organization vs Brand

Schema.org defines both types. They have overlapping properties but different semantic roles.

Organization — the legal or operational entity. A company, a non-profit, a subsidiary. Carries the company’s identity: legal name, logo, address, contact points, social profiles. One per actual organization. Site-wide.

Brand — the brand identity associated with a product. A Brand is what gets cited inside a Product’s brand property. Carries the brand’s name, logo, and identifying URL. A single Organization can own multiple brands; a single brand can be owned by different organizations over time.

For most ecommerce catalogs, the brand and the organization are the same entity, and the cleanest pattern is:

brand: { @id: ... }

brand: { @id: ... }

seller: { @id: ... }

Site-wide
Organization block
name, url, logo, sameAs

Product block
variant 1

Product block
variant 2

Offer block
  1. Emit one site-wide Organization block (typically on the homepage and in the <head> of every page).
  2. Inside each Product’s brand property, reference the Organization by @id rather than restating it.

This avoids drift between the two — there is one canonical source of brand identity per site.

The cross-reference looks like:

<!-- Site-wide Organization block -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yourstore.com/#organization",
  "name": "Acme Outfitters",
  "url": "https://yourstore.com/",
  "logo": "https://yourstore.com/cdn/shop/files/acme-logo.png"
}
</script>

<!-- Per-product Product block -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wool runner",
  "brand": { "@id": "https://yourstore.com/#organization" }
}
</script>

The @id is the stable URL identifier the parser uses to resolve the cross-reference. The #organization fragment is convention — any stable URI works, but the {site-root}#organization pattern is widely used and unambiguous.

For catalogs where the brand and the organization are not the same (a parent company that owns multiple sub-brands), emit separate Brand objects and reference them from the relevant products. This is the less common case; the rest of this guide focuses on the brand-equals-organization pattern.

The properties that matter

Of Organization’s many properties, eight are load-bearing for AI commerce surfaces:

PropertyRequired?Purpose
nameRequiredThe displayed brand name
urlRequiredCanonical homepage
logoStrongly recommendedThe brand mark, ideally on a transparent background
sameAsRecommendedCross-references to social/profile URLs
contactPointRecommendedCustomer-service contact details
addressOptionalBusiness address (matters for local-relevance)
descriptionRecommendedOne- or two-sentence brand description
foundingDateOptionalWhen the brand was founded

The first three are the floor. Most catalogs have name and url; many are missing or wrong on logo.

The logo property is the URL to a publicly accessible image of the brand mark. Three rules from Google’s logo structured- data documentation:

  1. The URL must be crawlable (not blocked by robots.txt).
  2. The image must be a recognizable logo, not a hero image or a marketing banner.
  3. Recommended sizing: minimum width 112 pixels; both square and horizontal logos are acceptable.

Common Shopify failure: logo set to the homepage hero image because that was what was uploaded first in the theme settings. The result is a banner where Google expects a logo, which gets filtered out of brand-knowledge-panel eligibility.

Fix: upload a dedicated logo file (a PNG with a transparent or white background works; SVG is also accepted by Google and most AI surfaces) and point logo to that asset specifically.

sameAs

sameAs is an array of URLs identifying the brand on other platforms. The intent is “these other profiles are also us.” Use it for:

The sameAs array is one of the signals AI surfaces use to confirm a brand’s identity. A page that cites https://yourstore.com/ plus a verified LinkedIn page plus a Wikidata reference is more trustworthy than a page that cites only itself.

"sameAs": [
  "https://www.linkedin.com/company/acme-outfitters",
  "https://www.instagram.com/acme.outfitters/",
  "https://twitter.com/acme_outfitters",
  "https://www.wikidata.org/wiki/Q123456789"
]

contactPoint

contactPoint is a sub-object describing how to contact the brand. The Schema.org type is ContactPoint.

"contactPoint": {
  "@type": "ContactPoint",
  "telephone": "+1-XXX-XXX-XXXX",
  "email": "support@example.com",
  "contactType": "customer support",
  "areaServed": ["US", "CA"],
  "availableLanguage": ["English", "French"]
}

Several practical notes:

Many ecommerce brands do not have a public-facing phone number. In that case, omit telephone and provide email or url (pointing to a contact form) instead.

The full reference block

A complete Organization block for a typical Shopify catalog:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yourstore.com/#organization",
  "name": "Acme Outfitters",
  "alternateName": "Acme",
  "url": "https://yourstore.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://yourstore.com/cdn/shop/files/acme-logo.png",
    "width": 600,
    "height": 200
  },
  "description": "Outdoor apparel and gear for cold-weather hikers.",
  "foundingDate": "2014",
  "sameAs": [
    "https://www.linkedin.com/company/acme-outfitters",
    "https://www.instagram.com/acme.outfitters/",
    "https://twitter.com/acme_outfitters"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "email": "support@example.com",
    "contactType": "customer support",
    "areaServed": ["US", "CA"]
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97201",
    "addressCountry": "US"
  }
}
</script>

A few notes on this block:

Where to emit it on a Shopify site

Three placement strategies, in increasing order of completeness:

Homepage only. A single Organization block on the homepage. Acceptable for small catalogs; minimum viable. The risk: a deep product page may be the first surface a crawler visits, and absent the homepage context, the brand identity isn’t immediately available.

Homepage + every page header. The Organization block on the homepage plus a smaller version (just name, url, @id) in the <head> of every page. The lighter every-page block references the homepage block by @id. This is the recommended pattern for catalogs of any meaningful size.

Homepage + every page header + breadcrumbs. Adds a BreadcrumbList to product and collection pages, with the homepage at the root referencing the Organization block. The breadcrumb gives the AI surface an explicit path from product → collection → brand and is the most complete pattern.

For implementation in Shopify, the Organization block lives in the theme’s theme.liquid (so it renders on every page in the layout). The Liquid:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "{{ shop.url }}/#organization",
  "name": {{ shop.name | json }},
  "url": "{{ shop.url }}/",
  {%- if settings.logo -%}
  "logo": {
    "@type": "ImageObject",
    "url": "{{ settings.logo | image_url: width: 600 }}",
    "width": {{ settings.logo.width }},
    "height": {{ settings.logo.height }}
  },
  {%- endif -%}
  {%- if settings.brand_description -%}
  "description": {{ settings.brand_description | json }},
  {%- endif -%}
  "sameAs": [
    {%- if settings.social_linkedin -%}{{ settings.social_linkedin | json }}{%- endif -%}
    {%- if settings.social_instagram -%},{{ settings.social_instagram | json }}{%- endif -%}
    {%- if settings.social_twitter -%},{{ settings.social_twitter | json }}{%- endif -%}
  ]
}
</script>

The settings.* references assume the theme exposes brand settings under config/settings_schema.json. Most Shopify themes expose at least logo and social links by default; others require adding the settings explicitly.

The seven failure modes

The most common Organization-schema issues, in rough order of frequency:

1. No Organization block at all

A catalog that emits clean Product blocks but no Organization block. The brand identity is implicit (in prose, in the URL, in the visible page) but not structured. AI surfaces have to infer the brand from context — which works less reliably than reading a structured block.

Fix: add the block. Even a minimal name + url + logo block is meaningfully better than no block.

2. logo pointing to a hero image

The theme’s “logo” setting was filled with the homepage hero image. The Organization.logo URL resolves to a marketing banner rather than a brand mark. Google’s logo-extraction pipeline filters out hero images; the brand doesn’t get a knowledge-panel logo.

Fix: upload a dedicated logo file and point logo to that asset. The hero image stays where it belongs (in the homepage hero), the logo is a separate asset.

3. Incomplete sameAs

sameAs includes only one or two profiles, or is missing entirely. The brand has real social presence and a Wikidata entry but none of it is cross-referenced from the structured data. AI surfaces have less basis to confirm the brand’s identity across platforms.

Fix: enumerate all genuine brand profiles. Don’t pad — fake profiles or profiles the brand doesn’t actually operate hurt more than they help.

4. Inconsistent name

The name value in the Organization block doesn’t match the brand.name in the Product blocks. Common when the Product block hard-codes a brand name while the Organization block is populated from a different setting. AI surfaces see two brand names and can’t reliably pick one.

Fix: use the cross-reference pattern (Product.brand → {"@id": ".../#organization"}) so the brand name lives in one place.

5. Hard-coded logo URL with a stale image

The Organization block points to a logo URL that worked at theme install but the underlying image was replaced or moved. The reference 404s. Validators may not flag this (URL is syntactically correct); AI surfaces see no logo.

Fix: use Shopify’s image_url filter (or equivalent) so the logo URL is generated from the live asset reference. Validate periodically that the URL resolves.

6. Wrong jurisdiction in address.addressCountry

The addressCountry uses a non-standard country code (e.g., "USA" instead of "US", or the country’s full name in prose). Schema.org expects ISO 3166-1 alpha-2 codes ("US", "CA", "GB", etc.).

Fix: use the two-letter ISO code.

7. Organization block emitted from JavaScript

Some apps inject the Organization block via client-side JS after page load. Crawlers that don’t execute JS see no block; the AI surface sees a page without brand identity. Especially common with apps that add structured data via tag managers.

Fix: render the Organization block server-side in theme.liquid. JS-injected structured data is a recipe for inconsistent visibility.

Knowledge-panel and brand-card eligibility

A well-formed Organization block is one of the inputs to Google’s brand knowledge panel — the box that appears in search results when a buyer searches the brand name. Eligibility requirements (per Google’s Logo and Brand documentation):

The structured data is necessary but not sufficient. A new brand without an established presence on other platforms won’t get a knowledge panel until the cross-web signals accumulate. The schema work makes a brand eligible; time and presence make a brand actually appear.

Where this is less load-bearing

Two scenarios where Organization schema work returns less:

B2B catalogs with named-account customers. A brand that sells only to known accounts via a quoting process has limited need for public-facing brand-identity work. AI surfaces are not the main discovery path; named-account RFPs are. The work has secondary value (employees finding internal documentation, brand disambiguation in industry-specific search) but the prioritization is lower.

White-label or reseller catalogs. A reseller storefront selling other companies’ branded products may not be the authoritative source for the brand identity. The cleanest pattern is: the reseller’s Organization block reflects the reseller; individual Product.brand references point to the actual brand’s Organization block via @id to that brand’s canonical site. Most AI surfaces handle this gracefully but it requires getting the cross-references right.

Related