Findings · 2026-09-16 · By VSNARY | Emmanuel Orta

Brand schema for multi-location businesses: link both ways

One site we operate declared twelve businesses under one brand. Read on their own, the locations named no parent at all. The fix, with a copy-paste JSON-LD example.

We operate a site that declares a brand and twelve businesses under it. The declaration is precise: a Brand node with a stable identifier, and each business pointed at by its own identifier. A reader that parses that graph learns every one of the twelve belongs to the same brand.

Then it reads any one of the twelve. None of them said so. The tree service declared membership of an arborists' association and nothing about a parent. The fencing companies declared themselves and nothing else. The relation existed from the parent side only: a family tree in which the parent lists the children and no child has heard of the parent.

Why is a one-way declaration not enough? #

A reader that lands on one location has to decide on its own whether a set of similarly branded sites are branches of one business, separate businesses, or one business appearing several times. Entity SEO is the work of not leaving that decision to the reader. What a site declares about itself is an observation with provenance; an observation that is missing cannot settle a conflation.

Google's Maps schema, as recovered and published by researchers in August 2026, treats a chain as its own object with a member-of-chain relation, alongside other declared relations between businesses. The same study measured one retail brand's stores in one city and found they disagreed on their own primary category. A chain can declare an ideal state; its members can still contradict it.

Stores of one retail brand in one city, from the same study:

How do you declare the chain from the location side? #

Copy the parent's own Brand node onto each location's business node as brand: the same @id, the same name, the same URL. The location then says what the parent already said, from its own side, and claims nothing new. If a location types itself as a plain Organization rather than LocalBusiness, it needs the same property; that is the case we missed on the first pass.

// On the parent site: the brand, with a stable @id
{
  "@context": "https://schema.org",
  "@type": "Brand",
  "@id": "https://example.com/#brand",
  "name": "Example Brand",
  "url": "https://example.com/"
}

// On each location site: the same node, by the same @id
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example-location.com/#business",
  "name": "Example Fencing",
  "url": "https://example-location.com/",
  "brand": {
    "@type": "Brand",
    "@id": "https://example.com/#brand",
    "name": "Example Brand",
    "url": "https://example.com/"
  },
  "memberOf": {
    "@type": "Organization",
    "name": "A trade association"
  }
}

Keep memberOf for what it is. Membership of a trade body is a declared membership, not a chain, and should not be counted as one. Keep Service nodes for what they are too: a service is an offering of the business, never a second business on the page. Our own first reading got both of those wrong before anything was published. The JSON-LD @id guide covers keeping identifiers stable so both sides resolve to one node.

What changed on our sites #

The first pass branded four of five. Checking every page before reporting found the fifth, and it is now branded. The sixth remains the one location that does not declare its parent, and it stays in the table rather than off it. A CrawlCheck report now shows which business a page is about and how every other business on the page relates to it, or that no relation is declared; run a scan on each location, not only the parent.

What comes after the chain? #

Once the locations agree with the parent about who they belong to, the next question is whether they agree about anything else, starting with where they work. The service-area check reads whether the areas each site declares have pages behind them.

What this post does not claim #

It does not claim a chain relation improves a ranking; the researchers recovered the relation's name, not a weight. It does not claim these sites are now correctly modelled, only that they say the same thing from both sides. And it does not claim the fix generalises: a business whose parent is a franchisor, a holding company or a larger organisation needs a different relation from the same vocabulary, and declaring the wrong one is worse than declaring none. What it claims is that direction matters, that we had it one way for a year without noticing, and that a report now shows it.

Questions this post answers

Why should each location declare its brand?

Because a reader that lands on one location only sees that location. If the relation is declared on the parent alone, the location page says nothing about belonging to a chain, and the reader has to guess.

Which property links a location to its parent brand?

Use brand on the location's LocalBusiness or Organization node, pointing at the parent's Brand node with the same @id, name and URL the parent site uses.

Is a trade-association membership a chain?

No. memberOf a trade body is a declared membership. It sits beside the brand link and should never be treated as chain membership.

Are Service nodes separate businesses?

No. A Service node describes something the business offers. It is not a second business competing for the page.

Does declaring a chain improve rankings?

No weight for it is known. The recovered Maps schema names chain membership as a relation, and the researchers recovered names, not weights. The case for declaring it is clarity, not a ranking boost.

What if the parent is a franchisor or holding company?

Then member of chain may be the wrong relation. Choose the one that describes the real ownership; declaring the wrong relation is worse than declaring none.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All findings · The dataset · How the dataset works