Multi-Location SEO on Squarespace

The temptation is to ship a single 'Visit Us' page listing all five café addresses in a row, with one Map block per location. The intent is reader-friendly; the SEO impact is severe. Google's local-business documentation¹ is explicit: one LocalBusiness JSON-LD block per location, on a page describing that location. Two addresses on one page produces either a single LocalBusiness block (so only one location is signalled) or two LocalBusiness blocks on the same URL (which Google reads as ambiguous and downweights both).

The fix is to build a per-location page. The hub page at /locations/ exists to give readers an overview and to capture brand + 'locations' query traffic — it does not carry LocalBusiness JSON-LD itself. Each per-location page carries the schema, the embedded Map block, the location-specific hours, and the 400+ words of location-specific content.

The flat /locations/{city-slug}/ pattern handles every scale from two locations to several dozen without modification. Adding a sixth location is a single page-create; renaming a location is a single URL Mapping; moving a location to a new city is a URL Mapping plus a 301 redirect. The state-nested pattern (which looks tidy when you have three locations across three states) collapses when you open a second location in the same state and have to choose between renaming the existing page and creating a state hub that no one searches for.

The branchOf pattern⁴ is the cleanest way to signal corporate structure for multi-location businesses. The parent Organization lives on the homepage as a single Organization JSON-LD block carrying the brand name, logo, sameAs links, and contactPoint. Each per-location LocalBusiness block adds a branchOf reference back to the parent. Google reads the graph and surfaces the parent brand in the knowledge panel while ranking each child location separately in the local pack.

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Maple Café — Charlotte", "branchOf": { "@type": "Organization", "name": "Maple Café", "url": "https://maplecafe.com/" }, "address": { "@type": "PostalAddress", "streetAddress": "218 N Tryon St", "addressLocality": "Charlotte", "addressRegion": "NC" } } </script> 

The 400-word floor³ is not arbitrary. Below 400 words of location-specific content, Google reads the page as boilerplate plus a few swapped tokens. Above 400 words with substantive location context (real photos, real directions, real local team members, real local FAQs), Google reads the page as a genuine resource. The line is not exact, but the pattern is consistent across audits.

The shared-versus-unique decision is easier in practice than it sounds. Take a generic location page draft, then for each new location ask: would a real reader visiting this location want to know something specific to this address that the other location pages do not say? The answer is always yes — parking is different, the neighbourhood is different, the team is different. Write what is genuinely true, and the helpful-content filter clears itself.

Squarespace does not ship a dedicated multi-location template that auto-replicates hours updates or schema changes across pages. Each page is independently authored. For organizations approaching 10 locations on Squarespace, the practical workflow is a documented monthly maintenance pass: hours, photos, schema, GBP cross-check. Below 10 locations, the per-location overhead is bounded; above 20 locations, the maintenance cost typically outweighs the platform fit and the migration to a chain-specific platform becomes worth costing out. The decision tree is industry-specific and lives in the install conversation, not in a blog post.