Schema for local, international and multi-brand businesses

Structured data is a way of stating facts about entities. Almost every schema problem we audit is not a syntax problem — the JSON-LD validates, the test tool is green — it is a statement about the world that is wrong.

So before opening a template, answer one question: how many organisations exist here? Not how many websites, not how many brands in the marketing deck, not how many Companies House registrations. How many distinct things would a knowledgeable person name as separate businesses?

Three shapes cover nearly everything. One company, several physical shops — that is one organisation and several locations. One company, several markets — that is one organisation, full stop; a market is not an entity. A group with several consumer brands — that is several organisations plus a parent, and it is the one that gets modelled wrongly most often, usually by describing the group on every brand site and leaving the brands themselves undescribed.

Get this wrong and no amount of correct markup rescues it, because you are precisely and consistently describing something that is not true.

It is worth separating two things that discussions of schema tend to blur.

Google's Organization documentation lists the properties it supports, and the list is generous: name, url, logo, sameAs, contactPoint, address, email, telephone, legalName, alternateName, description, numberOfEmployees, foundingDate, plus identifiers — iso6523Code, naics, duns, vatID, taxID — and commerce properties including hasMerchantReturnPolicy, hasShippingService and hasMemberProgram. None of them is required.

parentOrganization and subOrganization are not on that list. They are schema.org vocabulary, defined respectively as "the larger organization that this organization is a subOrganization of, if any" and "a relationship between two organizations where the first includes the second, e.g., as a subsidiary". They are valid, they are correct, and they should not be sold to a client as a route to a rich result.

Emit them anyway, and be honest about why. A search engine's rich result is one consumer of structured data; entity understanding is another, and it is the one that matters for the answer engines now summarising brands on their own. A model asked "who owns this brand" gets a better answer from an explicit parentOrganization than from a paragraph in a footer. That is a reasonable thing to invest an hour in and an unreasonable thing to promise a ranking for. The same applies to identifiers: a duns or vatID wins you nothing visible, and makes the entity unambiguous, which is worth having when your brand name is a common word.

The model that works is simple once the entity question is settled. Each brand site describes its own brand as the Organization on its home page — name, url, logo, sameAs, contact point, address — and adds parentOrganization pointing at the group. The group site describes the group and lists the brands with subOrganization.

Use @id to make those references mean something. A node identified by a stable URI — the canonical home page URL, or that URL with a fragment such as #organization — can be referred to from other documents rather than re-described in each. Restating the parent's full details on four brand sites means four descriptions that will drift the first time an address changes, and drift is how two entities get created out of one.

The mistake we see most often runs the other way: the group is marked up as the Organization on every brand site, because one agency built the schema snippet and copied it. The result is four home pages all claiming to be the same company, none of which describes the brand the page is actually about. The brands then have no structured description anywhere, which is the exact opposite of the intent.

One more distinction worth keeping straight. brand in schema.org is "the brand(s) associated with a product or service, or the brand(s) maintained by an organization or business person" — it belongs on products, where it says who makes the thing. A subsidiary company is not a brand property on the parent. If the brand trades, employs people and has its own site, it is an organisation.

This is the shape that most often gets over-modelled. A store selling in the UK, Ireland, Germany and the US is one organisation. It is not four, and creating four is actively harmful, because you have told search engines that four similar companies with the same logo are competing for the same name.

The correct treatment is one canonical Organization, described once, referenced from the localised sites by @id rather than restated. Market-specific facts belong on market-specific nodes: local phone numbers as contactPoint entries with areaServed and availableLanguage, local shops as LocalBusiness nodes on their own pages, local company registrations as legalName on a subsidiary if one genuinely exists as a separate company.

The things people reach for schema to solve here are usually not schema's job. Which locale version of a page to show is hreflang and canonicals. Which currency and prices apply is Markets configuration and product markup. Delivery expectations per country belong on the product and in hasShippingService. Schema states who you are; it does not route traffic.

One genuinely useful international property is sameAs, "URL of a reference Web page that unambiguously indicates the item's identity" — the social profiles, the Wikipedia or Wikidata entry if one exists, the company register listing. For a brand whose name is ambiguous in one market and not another, that list is the cheapest disambiguation available, and it is the signal answer engines lean on hardest when deciding which of two similarly named companies they are describing.

None of this needs a schema app, and we would rather you did not install one. Apps that inject structured data tend to emit a generic Organization block on every page — which contradicts Google's own placement guidance — and they add a script to the critical path to do it.

The maintainable pattern on Shopify is a snippet per entity type, rendered from data held in one place. Put the organisation's details in a metaobject or a set of shop metafields, render them into JSON-LD from a single snippet, and include that snippet on the home page and the about page only. Locations become a location metaobject type with a template, so each shop has a page and each page carries its own node from the same fields the page displays.

The reason to hold the data rather than hardcode the JSON is drift. A phone number written into a Liquid snippet and also into a footer and also into a contact page is three phone numbers waiting to disagree. One source, rendered three ways, cannot. This is the same discipline a well-built [section library](/services/build/shopify-section-library) applies to everything else on the site: the content is data, the template is presentation, and nobody edits markup to change a fact. Then validate, and — more usefully — read what you emitted as prose. If the sentence it produces is not one you would say out loud about the business, the markup is wrong regardless of what the test tool says.

`aggregateRating` on your own Organization. Do not. Google excludes self-serving reviews for Organization, and marking one up risks a manual action that would strip every rich result across the site. Display the review count as visible text and link to the platform it came from.

The same Organization block on every page. Harmless in intent, and it contradicts Google's own guidance to place it on the home page or a single about page. It also makes it much harder to see which page is the canonical description of the entity.

Markup that disagrees with the page. An address in JSON-LD that is not the address in the footer, hours in schema that the shop no longer keeps. Structured data that contradicts the visible page is worse than none, because it is a statement you are making deliberately.

A group described where a brand should be. The tell is a brand home page whose Organization name is the holding company. Check every brand site you own; it is nearly always the copied snippet.

• Shopify section library
• Schema markup audit: what is on your site and what is wrong
• Getting found by AI assistants