One Brand, Many Locations: The LocalBusiness Schema Graph for Franchises

Most LocalBusiness schema guides show a single block for a single shop. Franchise and multi-location brands need something those guides skip: a way to say that forty addresses are forty locations of one brand, each with its own hours, phone, and sometimes its own departments, without claiming anything the page does not show.

schema.org has the vocabulary for this, though it is spread across several properties that are easy to misuse. This guide assembles them into one structure, with copy-ready JSON-LD, and flags the places where the documentation leaves you to make a judgment call.

The structure has three layers, and each lives on the page that shows its information.

• The brand. One Organization on the home page, with a permanent @id.
• Each location. One LocalBusiness subtype on each location page, with its own @id, pointing to the brand through parentOrganization.
• Departments, where they exist, nested inside the location that contains them.

The @id values are what turn separate blocks into a graph. They are identifiers, not links that need to load, so the convention is the canonical URL of the page plus a fragment, like #organization or #localbusiness. Pick the pattern once and never change it. If you are new to entity identifiers, the same idea is covered in what belongs in sameAs schema.

Google's Organization documentation recommends placing this markup on the home page or a single page about the organization, not on every page. Its recommended properties include name, alternateName, url, logo (at least 112 by 112 pixels), address, telephone, email, description, contactPoint, and sameAs.

For a franchise brand, keep the Organization about the brand itself. Do not attach any single location's address or phone number to it unless that is genuinely the corporate headquarters contact.

Example Air and example.com are placeholders. Replace every value with your real brand data.

Each location page gets one block describing that location. Google's LocalBusiness documentation lists address and name as required, and recommends properties including geo, openingHoursSpecification, telephone, url, priceRange, and department. It also says to use the most specific LocalBusiness subtype possible, which for a heating and cooling franchise is HVACBusiness.

LocalBusiness inherits from both Organization and Place on schema.org, which is why a location can carry organization properties like parentOrganization and place properties like geo and branchCode in the same block.

Every value in that block should appear on the rendered page. Google's structured data policies say markup must be a true representation of the page content and that you should not mark up content that is not visible to readers. For franchise systems, the reliable way to keep that true across dozens of pages is to render the visible NAP block and the JSON-LD from the same location record, so they cannot drift apart.

Older multi-location examples use branchOf. On schema.org, branchOf is superseded by parentOrganization, which schema.org defines as the larger organization that this organization is a subOrganization of. Its expected domain and range are Organization, and its inverse is subOrganization.

In practice, reference the brand by @id rather than repeating the full Organization on every location page. The reference keeps each location page small and ensures every location points at exactly the same brand entity.

schema.org defines branchCode as a short textual code, also called a store code, that uniquely identifies a place of business, and notes that it is typically assigned by the parentOrganization and used in structured URLs. That is exactly what a franchise location number is.

If your system already assigns location numbers, use the same code in schema, in your internal reporting, and as the store code when managing Business Profiles in bulk. One identifier that follows the location everywhere makes audits, migrations, and ownership changes much easier to reconcile.

This is the part the documentation does not settle. schema.org has no franchise or franchisee property, and Google's documentation does not describe how to represent an independent owner.

The most defensible approach is to let parentOrganization express the brand relationship, keep the location nameconsistent with the brand name used on the Business Profile, and state independent ownership in visible text on the page. Some systems also add the operating company's registered name as legalNameon the location. That is a reasonable use of the property, but treat it as a judgment call, and only include it when the page visibly shows the same legal name, usually in an “independently owned and operated by” notice.

The modeling of multi-location businesses is an active discussion on schema.org's own issue tracker, for example issue 4805, so revisit this choice if the vocabulary changes.

Some locations contain distinct parts: a dealership with a service center, a store with a pharmacy. Google's LocalBusiness documentation supports a department property for these, and describes the naming pattern as the store name followed by the department name. In practice it is most useful when a department has details of its own, such as separate hours or a separate phone number.

The Business Profile side follows a similar rule. Google's profile guidelines say publicly facing departments that operate as distinct entities should have their own profile, and that each department name must be different from the main business name. Keep the department names in schema, on the page, and on the profile aligned.

For franchises that serve customers at their homes, the location page usually describes a territory more than a storefront, and Google asks service-area businesses to hide their address on the Business Profile. The areaServed property describes where the location provides service, and accepts values such as a city, an administrative area, or a shape.

Two cautions. Google still lists addressas required for LocalBusiness markup, so decide deliberately how much of the address the page shows, and keep the markup to what is visible. And list only the areas this territory actually serves. Markup that claims a neighboring franchisee's towns creates the same confusion as the city page problem covered in franchise location pages.

On review markup specifically, see AggregateRating schema and the self-serving review rule before adding stars to any location page. For the other LocalBusiness properties and how they compare to the rest of the vocabulary, the schema markup types guide covers them in context.

Validate the template, then validate the data. The template check catches syntax and structure once. The data check catches the location with a missing phone number or hours that never got entered.

1. Run one location page through the Schema Markup Validator to confirm the vocabulary and the @id references parse the way you intend.
2. Run the same page through Google's Rich Results Test to see what Google detects and whether required properties are present.
3. Crawl every location page and confirm each has exactly one LocalBusiness block, a unique @id, a unique branchCode, and the same parentOrganization reference.
4. Compare schema values against the visible NAP and hours on each page, and against the Business Profile for that location.
5. Repeat after any location opens, closes, moves, or changes hours.

If schema is one piece of a larger multi-location effort, the ownership rules in franchise SEO strategy decide who is responsible for keeping each location record accurate in the first place.