A business with two physical locations is not one business with a footnote. It is two separate places that each need their own clear signal to search engines. Most multi-location sites get this wrong, not through negligence, but because nobody stopped to build it correctly on purpose.
I documented a real example of this failure in a recent field post (https://bizpinpro.com/inthefield/in-the-field-021-when-one-location-becomes-the-only-story/), a nonprofit thrift store with two locations sharing a single page and a single generic schema block. Neither location was represented as its own complete local entity. This post is the fix.
One note before the examples: every block below uses LocalBusiness as the type because it is the general case. Whenever a more specific subtype exists, Restaurant, AutoRepair, Store, and so on, use that instead. LocalBusiness is the floor, not the target.
The Wrong Way
Here is what most multi-location sites have. One page, one schema block, trying to represent two addresses at once.
json
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Example Thrift Store",
"address": "Christiansburg and Fairlawn locations",
"telephone": "540-555-0100"
}
This tells a search engine almost nothing useful. Two towns crammed into one address field is not structured data, it is a note left for a human to sort out. That value does not conform to the PostalAddress structure Google expects for LocalBusiness markup. It is a field that does not resolve into a real address, for either location.
The Right Way
Each location gets its own complete, valid LocalBusiness block, with its own name, its own address, and its own unique identifier.
json
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://example.com/christiansburg/#business",
"name": "Example Thrift Store - Christiansburg",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Christiansburg",
"addressRegion": "VA",
"postalCode": "24073",
"addressCountry": "US"
},
"telephone": "540-555-0101",
"openingHours": "Mo-Sa 10:00-18:00",
"url": "https://example.com/christiansburg/"
}
And the second location, on its own dedicated page, with its own block:
json
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://example.com/fairlawn/#business",
"name": "Example Thrift Store - Fairlawn",
"address": {
"@type": "PostalAddress",
"streetAddress": "456 River Road",
"addressLocality": "Fairlawn",
"addressRegion": "VA",
"postalCode": "24141",
"addressCountry": "US"
},
"telephone": "540-555-0102",
"openingHours": "Mo-Sa 10:00-18:00",
"url": "https://example.com/fairlawn/"
}
Two locations. Two URLs. Two schema blocks. Each one complete and unambiguous on its own.
Why The @id Field Matters
Google's LocalBusiness documentation only requires name and address. The `@id` field is not on that list, but it is strong entity modeling practice regardless. Setting `@id` to a stable URL fragment, like `https://example.com/christiansburg/#business`, gives that specific schema block a permanent, unique identifier tied to that specific location. It is the difference between structured data that happens to work and structured data built the way a search engine models real-world entities, one clear identifier per distinct thing.
Connecting The Locations Together
If it makes sense for the business, both locations can also be linked as part of the same parent organization using the `@graph` structure, so Google understands they are related without merging their individual identity.
json
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Thrift Store",
"url": "https://example.com/"
},
{
"@type": "LocalBusiness",
"@id": "https://example.com/christiansburg/#business",
"name": "Example Thrift Store - Christiansburg",
"parentOrganization": { "@id": "https://example.com/#organization" },
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Christiansburg",
"addressRegion": "VA",
"postalCode": "24073",
"addressCountry": "US"
}
},
{
"@type": "LocalBusiness",
"@id": "https://example.com/fairlawn/#business",
"name": "Example Thrift Store - Fairlawn",
"parentOrganization": { "@id": "https://example.com/#organization" },
"address": {
"@type": "PostalAddress",
"streetAddress": "456 River Road",
"addressLocality": "Fairlawn",
"addressRegion": "VA",
"postalCode": "24141",
"addressCountry": "US"
}
}
]
}
This structure tells Google three true things at once. There is one organization. It operates two distinct locations. Each location is its own complete entity with its own address and its own page.
A Note On What Google Requires Versus What Works
Google does not require a dedicated page per location. Its documentation allows LocalBusiness markup on any page, including one page describing multiple locations. What follows here is not the bare minimum needed for eligibility. It is the architecture that represents a multi-location business the way search engines model real entities, distinct pages, distinct schema blocks, distinct identities. The minimum gets you compliance. This gets you clarity.
Why This Matters Beyond Whatever Google Currently Prefers
Google is not the only machine reading your website anymore, and it will not stay the dominant one forever. AI systems are increasingly the thing parsing, summarizing, and citing business information, and they will keep developing their own conventions for what counts as a clear, trustworthy signal. Building a site that barely satisfies today's Google minimum is building for a rule set that is already starting to share the room with others.
The better standard is not what Google currently requires. It is what represents reality clearly enough that any reasonably competent machine, today or in five years, can parse it correctly.
A business with two physical locations already made this decision in the real world. They looked at their customers, their market, their operations, and decided that one location was not enough to serve them properly. That is not a casual choice. It costs rent, staff, and overhead twice over.
The digital presence should reflect that same judgment. If the business decided two locations were necessary in the physical world, the website should not quietly collapse that decision back into one page out of convenience. Two locations in reality should mean two clear, complete, independent identities online, not because a specific search engine currently rewards it, but because that is true about the business.
What This Requires
Each location needs its own dedicated page, not a shared homepage mentioning both. Each page needs its own complete schema block with a unique `@id`. Each address needs to be structured as a proper `PostalAddress` object, not a plain text string. If it helps the business, the locations can be tied together under a shared `Organization` block using `parentOrganization`.
None of this is complicated. It is a handful of JSON blocks and a decision to build two pages instead of one. The difficulty is not technical. It is remembering that a search engine, or any AI system reading the same page, sees two addresses crammed into a single string as confusion, not information.
The Foundation Connection
A business with more than one physical location has more than one Digital Foundation to build, one for each place customers can walk into. Treating a second location as an afterthought on the homepage does not save effort in any meaningful way. It just means neither location gets the clean, complete signal it needed to be found, by Google today or by whatever reads the web next.
Build the page.
Write the block.
Give each place the identity it actually has.
