Single-location local SEO is operational; multi-location is architectural. The same chapter elements — GBP, citations, reviews, on-page, schema — but multiplied by 5, 50, or 500 locations, and each location competing in a separate local SERP with its own competitors, its own proximity dynamics, and its own review velocity. The mistakes that creep in at scale aren't usually wrong tactics; they're tactics applied without an architecture, producing duplicate content, citation drift, and brand-vs-location signal confusion.

“Every multi-location SEO problem traces back to one of three architecture choices: who owns the profiles, how location pages are templated, and where the canonical brand-vs-location entity boundary sits. Get those three right and 50 locations operate as a fleet. Get them wrong and every location competes against itself.”

One profile per location

The non-negotiable rule: one Google Business Profile per physical location with a permanent address, signage, and verifiable operations. Corporate offices that don't serve customers get no profile (Google's policy excludes administrative offices). Service-area businesses without a public-facing office get one profile per service-area region, with the address suppressed and the service area declared.

For 50+ location chains, Google's bulk-verification flow batches the verification process — submit a spreadsheet plus corporate proof and all locations verify together. For 5–50 locations, individual verification is manageable but tedious; budget two weeks for the verification cycle at this scale.

Ownership models

Three ownership patterns dominate in multi-location:

• Corporate ownership. A central business account owns all GBP listings; per-location managers (franchisees, store managers, regional ops) get manager access. Right for: central brand control, consistent NAP, aggregated insights, single response standards. Risk: the central account becomes a single point of failure if access is lost.
• Franchisee ownership. Each franchisee owns their location's GBP. Right for: franchise-friendly contracts, autonomy on local marketing. Risk: NAP drift, inconsistent response quality, varying review-request discipline. Recovering control later requires individual negotiation with each franchisee.
• Hybrid. Corporate owns the profiles; franchisees have full manager access. Combines central brand control with operational autonomy. The dominant pattern for established chains; complicated to set up for new franchise systems but the cleanest long-term.

Location page architecture

The URL structure decides the rest of the architecture. Two patterns work:

• Flat by city: /locations/boston/, /locations/cambridge/. Right for chains where each location is in a distinct city. Simple, scalable, easy to interlink.
• Nested by city + neighborhood: /locations/boston/back-bay/, /locations/boston/cambridge/. Right for multi-unit-per-city chains. The city level is itself a landing page with the city-wide content; the nested neighborhood pages handle the per-store specificity.

Either way: every location gets a unique URL with unique content. No exceptions, no city-name find-and-replace templating. The chapter on local on-page and schema covers the per-location anatomy.

The locator page

A multi-location site needs a locator — a top-level page that lists all locations with quick filters (by city, by service, by hours). Best practices:

• List view + map view. Both modes; users prefer different defaults by use case.
• Search by ZIP and by city. Auto-suggest from the location set; if no match, return the nearest 3.
• Per-location quick info. Address, phone, hours-status (open now / opens at X), distance from the searcher's IP-derived location, "Get Directions" link.
• Linked deep into the location pages. Each row links to /locations/[city]/ for the full location page.
• Indexable. The locator page itself ranks for "[brand] locations" queries; don't no-index it.

Citation propagation at scale

For 5+ locations, manual citation building doesn't scale. Three approaches:

• Yext-style real-time sync. Subscription-based, all locations updated centrally, propagation in minutes. Trade-off: rented citations that revert if the subscription ends. Right for chains under continuous brand-update pressure (frequent rebrands, hours changes, M&A).
• Bulk submission via aggregators. Data Axle, Localeze, Foursquare accept bulk feeds; one feed propagates to hundreds of derived directories. Right for stable chains where central data doesn't change often.
• BrightLocal / Whitespark bulk plans. One-time submission across the major directories with monitoring. Owned citations, slower than Yext, no subscription lock-in.

Whichever approach: the canonical NAP for each location is documented in a single source of truth before any citation work begins. Treating "the corporate spreadsheet" as that source of truth, with version control and change tracking, prevents the per-location drift that compounds for years otherwise.

Review distribution and aggregation

Reviews are produced per-location and consumed two ways:

• On the location page: a subset of that location's reviews, with AggregateRating schema reflecting that subset. The schema and the visible content match exactly.
• On the global testimonials or homepage: a curated set across locations, with AggregateRating reflecting the global aggregate (computed from all locations).

The two aggregates can diverge — a location with 4.2 stars contributing to a global 4.6 is normal. The schema handles this correctly as long as each AggregateRating reflects what's visible on its specific page.

Review velocity at scale

A 50-location chain has 50 review programs running in parallel. The variance kills if not managed. Two patterns:

• Standardize the review request flow. Same trigger event, same SMS or email template, same friction-removed link. Per-location dashboards track open rate, click rate, completion rate. Underperforming locations get coaching, not separate templates.
• Route by channel. Some locations get more reviews via SMS, others via post-receipt email, others via in-person QR. Track per-location and per-channel; converge on the highest-converting flow per location.

Brand vs location entity

Multi-location brands operate at two entity levels: the brand (Joe's Bakery, the chain) and the location (Joe's Bakery — Brookline, the specific store). Each ranks for different queries:

• Brand entity ranks for "[brand]", "[brand] near me", "[brand] [city]", "[category] like [brand]". Optimization: the homepage, brand-level schema (Organization, brand sameAs to Wikipedia/Wikidata if available), brand-level press and links.
• Location entity ranks for "[category] [city]", "[category] [neighborhood]", "[brand] [specific city]". Optimization: the location page, LocalBusiness schema, per-location reviews and citations.

The entities link to each other via schema (parentOrganization and subOrganization) and via internal linking. The brand entity gives location entities trust; the location entities give the brand entity geographic spread. Both layers compound when wired correctly.

Reporting at scale

A multi-location SEO program reports at three layers:

• Per-location dashboards. Map-pack ranking, review velocity, profile insights, top queries, click-to-call rate. The store-manager view.
• Per-region rollups. Aggregate of multiple locations in a region. The regional-ops view.
• Brand-level KPIs. Total citation coverage, brand search volume, brand entity strength signals. The corporate-marketing view.

The architecture covered here scales to hundreds of locations. The next chapter, map pack optimization, returns to the tactical layer — the specific moves that win the three-pack at the per-location level.