Home · The 15 signals · Brand entity

Shopify brand entity in JSON-LD

The brand property on your Product JSON-LD is how AI shopping agents decide which store is the "official" seller of a branded product versus a marketplace reseller. The shape matters: a nested {"@type": "Brand", "name": "..."} entity gets full credit; a plain string gets half; a missing brand gets zero. Most Shopify themes emit the string form by default, leaving 4 of 8 possible points on the table for every PDP — and a missing or weak brand entity is the difference between "the official Allbirds.com store" winning a "where to buy Allbirds" query versus a discount reseller showing up first.

Last updated 2026-04-30 · Ranking-spread signal · 8 pts

8 / 70Ranking-spread weight
4 ptsDefault theme leaves on table
1 lineIn product.liquid to fix
What this signal scores: the brand property on every Product JSON-LD block on every PDP. Nested Brand entity ({"@type": "Brand", "name": "Allbirds"}) = 8 pts. Plain string ("brand": "Allbirds") = 4 pts. Missing or empty = 0 pts.

What it is

The schema.org Product type allows two shapes for the brand property:

Bad — 0 pts

Missing entirely

{
  "@type": "Product",
  "name": "Wool Runner",
  "offers": {...}
  // no "brand"
}
Partial — 4 pts

Plain string

{
  "@type": "Product",
  "name": "Wool Runner",
  "brand": "Allbirds",
  "offers": {...}
}
Correct — 8 pts

Nested Brand entity

{
  "@type": "Product",
  "name": "Wool Runner",
  "brand": {
    "@type": "Brand",
    "name": "Allbirds"
  },
  "offers": {...}
}

The nested form is what schema.org documents recommend and what every major AI agent's parser is built to expect. The string form was historically permitted as shorthand and is being phased out — it still parses, but agents are increasingly weighting it as a "weaker signal" relative to the nested form.

Why AI shopping agents care

How to test it on your store

  1. Open any PDP. View source.
  2. Find the Product JSON-LD block (search for "@type": "Product").
  3. Look for the "brand" field. If it's missing — 0 credit. If it's a plain string ("brand": "Allbirds") — half credit. If it's a nested object with "@type": "Brand" — full credit.
  4. Spot-check 3 PDPs across different collections to confirm the shape is consistent — themes sometimes emit one shape on default products and a different shape on app-managed products.

The free CatalogScan scan runs this check automatically and reports the exact shape it found, so you don't have to view-source ten different PDPs by hand.

How to fix it

Patch product.liquid to nest the brand5 minfree

In your theme's sections/main-product.liquid or snippets/product-json-ld.liquid, find where it emits "brand". Most default themes have something like "brand": {{ product.vendor | json }}. Replace with the nested form:

"brand": {
  "@type": "Brand",
  "name": {{ product.vendor | json }}
}

Make sure the JSON above is comma-separated correctly with adjacent fields. One commit, all PDPs fixed.

Set Vendor on every product10 minfree

The Liquid above pulls from {{ product.vendor }}. If Vendor isn't set on a given product, the field emits an empty string and you get 0 credit on that PDP. Bulk-set Vendor across your catalog: Products → Bulk edit → Add fields → Vendor.

Add knowledge-graph linkage (advanced)15 minfree

For a stronger trust signal, expand the Brand entity with url (your homepage), logo (a square brand image), and sameAs (your Wikipedia, Wikidata, or LinkedIn URLs). Agents that resolve to a known brand entity in their training data weight your store higher than unknown-brand listings.

"brand": {
  "@type": "Brand",
  "name": "Allbirds",
  "url": "https://www.allbirds.com/",
  "logo": "https://www.allbirds.com/assets/logo.png",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Allbirds",
    "https://www.wikidata.org/wiki/Q47073143"
  ]
}
CatalogScan Pro: theme-aware patcher2 min$49/mo

Pro detects your theme's existing JSON-LD shape and emits a Liquid patch you can paste into the right partial. See Pro pricing.

4 mistakes we keep finding

1. Vendor field used as a "category," not a brand

Some store owners use Vendor for internal categorization ("Footwear," "Accessories," "Spring 2026"). The Liquid below emits whatever's in Vendor as the brand. Result: "brand": "Footwear" in your JSON-LD. Agents rank you against other "Footwear" brands — none of which exist. Use Vendor for the real brand only; use Tags or product_type for category.

2. Inconsistent capitalization and punctuation across PDPs

One PDP says "Allbirds," another says "AllBirds," a third says "allbirds." Agents treat these as three different brands, fragmenting your brand authority. Pick one canonical form (the one on your About page) and bulk-edit Vendor everywhere to match.

3. Multiple brands on a multi-brand storefront, but only one default emitted

Multi-brand retailers sometimes hardcode the storefront-owner's name in brand instead of pulling from {{ product.vendor }}. Result: every product appears to be "REI brand," even when REI is reselling Patagonia, Black Diamond, etc. Always pull brand from the per-product Vendor field.

4. "@type": "Organization" instead of "Brand"

Some themes emit "brand": {"@type": "Organization", "name": "Allbirds"}. Schema.org allows it but agents treat it as ambiguous — Brand carries the right semantics for product-discovery context. Use "@type": "Brand".

See also

String or nested? Find out in 2 minutes.

Free scan. We tell you the exact shape your theme emits today and what's costing you ranking-spread points.

Scan my store → See all 15 signals