Multi Location Schema for a Cafe With Three Locations

Thomas Garner

Oct 7

10 min read

A cafe with three locations wants its structured data to be correct and not confusing, and the two most common mistakes both come from trying to shortcut the actual structure: one giant block for the brand stuffed with three addresses, or three nearly identical blocks copied onto one page with nothing tying them together as a single business.

Short answer: each location deserves its own page and its own structured data block, tied to a single brand entity, and the homepage should only list the locations in a way that links out to those individual pages. That is the whole structure. Everything below is the detail underneath it.

This post lays out that structure so it can be copied directly: one Organization block for the brand, one CafeOrCoffeeShop block per location page with its own address, hours, phone, and map link, and a homepage that ties them all together through links rather than duplicated markup. None of this is a ranking lever, and this post says so plainly rather than implying otherwise.

The Structure

The correct shape starts with a single Organization entity representing the brand as a whole, holding the properties that genuinely apply to the business overall, such as the brand name, a logo, and the main website URL. This block does not carry an address, because the brand as a whole is not located at any one address once there is more than one location.

Each individual location then gets its own CafeOrCoffeeShop block, placed on that location's own page, carrying the properties specific to that location: its own PostalAddress, its own telephone number, its own openingHoursSpecification, and its own geographic coordinates if available. Nothing in this block should be shared or copied identically from another location's block, because if every property matches exactly across locations, the markup is not actually describing three distinct places, it is describing one place three times.

Schema.org's own type documentation for Organization includes a subOrganization property, and the reverse relationship is commonly expressed through parentOrganization on the location level entity, allowing each location block to point back to the single brand entity rather than repeating the brand's own details inside every location block. This is what actually ties three separate location pages together as one recognizable brand, rather than leaving them as three unrelated businesses that happen to share a name.

Google's own Search Central documentation on local business structured data describes the standard properties a local business entity should carry, including address, telephone, and opening hours, and it does not describe a special exception or shortcut for a brand with multiple locations beyond applying that same standard structure once per location. Where Google's documentation is silent on a specific multi location detail, schema.org's own type definitions are the baseline practice to follow.

The single stuffed block mistake is actually a mistake, not just a style preference. A block that lists three separate addresses under one entity is technically ambiguous: nothing in the structure clarifies which address, phone number, or set of hours belongs to which physical place, which defeats the entire purpose of using structured data in the first place. The whole value of markup like this comes from precision, and a stuffed block trades that precision away for a shortcut that saves very little actual work.

Why One Page Per Location Matters

Beyond the schema question itself, giving each location its own page is what makes the schema structure possible at all, since a CafeOrCoffeeShop block needs a url property pointing to a specific page, and that only works cleanly when each location genuinely has its own page to point to. A shop trying to force three locations worth of schema onto a single page runs into the same ambiguity problem described above, just wearing a different shape.

A dedicated location page also gives a shop room to include the kind of detail that a shared, generic page cannot: parking or entrance notes specific to that address, a note about which location has more seating for someone working on a laptop, or anything else that genuinely differs by place. None of that detail is required for the schema itself to be correct, but it is exactly the kind of content that makes a location page useful to a real visitor reading it, not just to a search engine parsing its markup, and a page written with that visitor in mind tends to produce more accurate, specific schema almost as a side effect.

A Worked Example

Picture a fictional three location brand, invented for this example only, with locations on Elm Street, Birch Street, and Cedar Street in the same city. The homepage carries a single Organization block: the brand name, a logo reference, and the site's root URL, with no address property at all, since the brand entity itself is not tied to one location.

Each of the three location pages, Elm Street's own page, Birch Street's own page, and Cedar Street's own page, carries its own CafeOrCoffeeShop block. The Elm Street page's block includes the Elm Street PostalAddress, the phone number that actually rings at that specific location, the specific opening hours for that location if they differ from the others, and a url property pointing to that exact page rather than the homepage. The Birch Street and Cedar Street pages follow the identical pattern with their own respective details substituted in.

Each location block references the brand through a parentOrganization property pointing to the Organization entity defined on the homepage, which is what allows a search engine or any other system reading this markup to understand that these three separately addressed businesses are, in fact, one brand operating three locations, rather than three coincidentally similarly named unrelated shops.

This example is fictional and illustrative only, built to demonstrate the pattern, not describing any real shop. Any real cafe applying this structure would substitute its own real name, real addresses, real phone numbers, and real hours in place of the placeholder details used here, keeping every property specific and accurate to that one physical place.

Which Pages Carry Which Block

The Organization block belongs on the homepage, since that is the page representing the brand as a whole rather than any single location. It should not be repeated identically on every location page, since duplicating the exact same Organization block across every page adds clutter without adding meaning.

Each CafeOrCoffeeShop block belongs on its own location's page and nowhere else. A location page should not carry another location's address or phone number anywhere in its markup, even for reference, since that would misrepresent which physical place the page actually describes.

If the three locations share a single menu, that shared content can live on its own dedicated menu page, referenced from each location page through a plain link, rather than duplicating the entire menu's markup inside each location's own block. The location block's job is to describe the place, not to carry every piece of shared brand content that happens to apply to all three.

If hours differ between locations, and they often do, each location's own openingHoursSpecification should reflect that specific location's actual hours rather than a shared, averaged, or default set of hours copied from another page. A visitor checking the Cedar Street page should see Cedar Street's real hours, not a generic set of hours that happens to match a different location, and the same rule applies to a temporary or seasonal change that affects only one address.

Testing the Result

Once the blocks are written, each page's markup should be checked individually using Google's Rich Results Test and the Schema Markup Validator at validator.schema.org, checking the homepage's Organization block and each location page's CafeOrCoffeeShop block separately rather than assuming that one page validating cleanly means all of them do.

A useful check beyond simple validation is a plain read through: does the Elm Street page's block actually contain Elm Street's specific details, or did a copy and paste leave a leftover detail from another location behind. This kind of small copy paste error is common with multi location markup specifically, because so much of each block's structure is genuinely identical to the others, with only the address, phone, and hours actually differing, which makes a stray leftover value easy to miss on a quick glance.

It is worth being direct about what this structure does and does not do. None of this is a ranking lever, and this post makes no claim that correct multi location schema improves a shop's visibility or position in any search result. What it does is describe the business accurately and consistently to any system reading the page's structured data, which is a reasonable goal on its own regardless of any ranking effect.

It is also worth saying plainly that structured data on a location page should match what the shop's Google Business Profile for that same location states. This post is not covering Business Profile management itself, since that has its own separate set of practices, but a location page whose address or hours disagree with that location's own Business Profile listing creates the same kind of confusing mismatch this post is trying to help a shop avoid in the first place.

A useful habit going forward is to treat any update to a location's real world details, a new phone line, a changed set of hours, a renovated address, as a three part checklist rather than a single edit: update the Business Profile for that location, update the location page's visible text, and update that same page's structured data block, in that order. Skipping the third step is common precisely because structured data is invisible to a normal visitor browsing the page, which makes it easy to forget even when the visible text has already been corrected.

A Note on Scale Beyond Three Locations

Everything in this post applies the same way regardless of whether a brand has three locations or considerably more, since the underlying pattern does not change with scale: one Organization entity for the brand, one CafeOrCoffeeShop block per location page, each tied back through parentOrganization. A shop with three locations is simply a clean, common size to walk through in detail, and the same structure holds for two locations or for considerably more than three.

What does change with more locations is the practical discipline required to keep every page accurate, since more pages means more opportunities for the kind of copy paste drift described earlier in this post. A brand with several locations benefits from keeping a simple internal reference sheet listing every location's real address, phone number, and hours in one place, so that whoever maintains the site's pages has a single source of truth to check each page's markup against, rather than relying on memory or on whatever an older page happened to say.

Frequently Asked Questions

How do I mark up multiple locations for one cafe brand?

Use one Organization block for the brand on the homepage, with no address property, and one CafeOrCoffeeShop block per location page, each with its own address, phone, hours, and a parentOrganization property linking back to the brand entity. Each location's page carries only that location's own details, and each block's url property points to that exact page rather than the homepage.

Should I put all three addresses in one schema block?

No. A single block listing multiple addresses does not accurately describe three distinct physical places and is a common mistake, since nothing in it says which phone number or set of hours belongs to which address. Each location needs its own separate CafeOrCoffeeShop block on its own page with its own single PostalAddress, tied back to one brand Organization entity.

What property connects a location to the parent brand?

A parentOrganization property on each location's entity, pointing back to the single Organization entity defined for the brand overall, is the standard way schema.org models this relationship, alongside the related subOrganization property on the brand side. It is what tells a system reading the markup that three separately addressed shops are one brand rather than three unrelated businesses.

Does the homepage need a CafeOrCoffeeShop block too?

The homepage generally carries the Organization block representing the brand as a whole. Whether it also needs its own CafeOrCoffeeShop block depends on whether the homepage itself represents a specific physical location or purely the brand; a homepage that is not tied to one address should not carry location specific properties like a single street address.

What if all three locations share the same menu?

Keep the shared menu on its own page and link to it from each location page, rather than duplicating full menu markup inside every location's block. The location block's job is to describe that specific place, its address, phone, hours and map link, not to carry every piece of shared brand content that happens to apply to all three locations equally.

Do all three locations need the same opening hours listed?

No, and they should not be copied from each other if the real hours differ. Each location's openingHoursSpecification should reflect that specific location's actual hours, since a visitor checking a specific page should see that location's real schedule. A seasonal change at one address gets updated on that one page only, in both the visible text and the structured data.

Does correct schema help my cafe rank higher in Google?

This post makes no such claim, since no documentation supports it as stated fact. What correct, consistent structured data does is accurately describe the business to any system reading it, which is a reasonable goal on its own. Google's local business structured data documentation lists address, telephone and opening hours as standard properties, applied once per location.

Should my location page's schema match my Google Business Profile for that location?

Yes. A location page's address, phone, and hours should agree with that location's own Business Profile listing. A mismatch between the two creates the same kind of confusion this post is trying to help a shop avoid, even though Business Profile management itself is a separate topic. When details change, update the profile, the visible page text and the markup, in that order.

How common is it for independent shops to actually have three locations?

This project's own census recorded a location_count field with 93 of 1,109 sampled shops showing a value of exactly three, checked September 21, 2026, though the field's counting rules should be confirmed against the underlying audit notes before treating that number as precise, since some cells in that field contain free text rather than a clean number.

How do I test that my multi location schema is written correctly?

Run each page's markup individually through Google's Rich Results Test and the Schema Markup Validator at validator.schema.org, checking the homepage's Organization block and every location page's CafeOrCoffeeShop block separately, and read through each block by hand to catch any leftover detail copied from another location. A stray phone number or hours line from a sibling page is the most common slip.

Work with Hillcane

One block with three addresses stuffed in, or three copies of the same block. Neither is correct. Here is the actual structure.

If you want help setting up correct multi location schema across your cafe's pages, reach Hillcane at hillcane.co/contact or call (256) 384-2449.