SEO / Search Platforms

Structuring a Multi-Location Website

Platform: SEO / Search Platforms
Owner: SEO Specialist
Assignee: Alessandra
Supports: Website Specialist

Needs review — This SOP contains our content but has not been verified by Nick. Treat as a working draft until marked Live.

SOP: Structuring a Multi-Location Website

Last Updated: May 2026 Version: 1.0 Owner: SEO Specialist Coordinates with: Website Specialist, GBP Specialist

Purpose

This SOP covers how to structure a website that supports multiple Google Business Profiles, one per physical location. It applies any time the client has (or is adding) a second, third, or fourth GBP at distinct physical addresses.

The framework is from AI SEO Mastery Pro, “Structure for Multiple Locations.” Goals:

Each GBP gets its own dedicated landing page so it can rank for its own city.
Each landing page has location-specific schema, content, embeds, and contact info.
Existing rankings are protected. We don’t move ranking GBPs just because the structure isn’t “best practice.”
The site scales cleanly from one to many locations without duplicate-content traps.

This SOP is run by the SEO Specialist. The Website Specialist executes the page builds. The GBP Specialist consumes the output (location landing pages + phone numbers) when creating or updating GBPs.

When to Use This SOP

Trigger any of the following:

A new client is onboarded with 2+ existing GBPs.
An existing client adds a second/expansion location and needs a new GBP landing page (called from the Preparing a New Address for GBP Creation SOP).
An existing multi-location client has all GBPs pointing at the homepage and rankings are weak in some markets.

Do NOT use this SOP for:

Service-area businesses with a single location and many service areas. That’s a single-location structure with a service area defined on the GBP, not a multi-location structure.
Pure franchise sites where each franchise has its own domain. Different problem.

The Four Ground Rules

These rules govern every decision in this SOP.

1. Don’t touch it if it’s ranking. The most important rule in multi-location SEO. If a GBP is already ranking in the top 3 with its current landing page (even if that landing page is the homepage and “shouldn’t” be), leave it alone. Moving a ranking GBP’s landing page will lose positions in the short term. Always run a rank map FIRST. Only restructure landing pages for locations that aren’t ranking well.

2. Each GBP must have its own dedicated landing page. Different city = different page. You cannot optimize one landing page for multiple cities effectively. Each landing page needs its own Local Business schema, its own embedded GBP map, its own city-specific content, and its own internal links to city-specific service pages.

3. Each GBP must have a distinct phone number. Never share phone numbers across GBPs. Tracking numbers that route to the same call center are fine. The same raw phone number on two GBPs is not fine — it creates duplicate-business signals to Google.

4. The most competitive location gets the homepage. The homepage is the most powerful URL on the domain. Pick the location where ranking is hardest (or where revenue concentration is highest) and let the homepage carry it. Other locations get their own landing pages.

Phase 0: Run a Rank Map First (Pre-Work, Mandatory)

Before recommending ANY structural change to an existing multi-location client, pull rank data.

Why

A real client example from the training: 8 locations, all pointing at the homepage. Rank analysis showed:

4 locations ranking top 3 everywhere
2 locations averaging 10-11
2 locations averaging 20+

Only the bottom 2 got new landing pages. The 6 that were ranking stayed pointed at the homepage despite being “incorrect” structurally.

How

Pull a heatmap / geo-grid scan for each location’s primary category + city keyword.
Calculate the average ranking position for each location.
Categorize each location:
- Top 3 average: Don’t touch. Even if structure is “wrong,” leave it alone.
- 4-15 average: Maybe touch. Look at trend. If declining, restructure. If stable or improving, leave alone.
- 16+ average: Restructure. Nothing to lose.
Document the categorization in Task Tracker before proposing changes.

Output of Phase 0

A list of locations classified as “leave alone” vs. “restructure.” Every recommendation downstream applies only to the “restructure” list.

Phase 1: Architecture Decisions

For each location that’s getting a new (or revised) landing page:

Decision 1: URL pattern

Pick one and use it consistently across all locations:

/[city]/ — short, clean, top-level. Best for sites with few locations and no other top-level conflicts.
/locations/[city]/ — explicit, organized, scales well. Best for sites with 4+ locations.
/[city]/[primary-category]/ — when the city alone isn’t a strong enough keyword target.

Once chosen, apply the same pattern to every multi-location landing page on the site. Mixing patterns confuses Google.

Decision 2: Which location gets the homepage

If the client is brand-new (no existing rankings), pick the most competitive market — usually the largest population center or highest revenue concentration. That market needs the homepage’s authority to rank.

If the client has existing rankings, the homepage already belongs to whichever location is currently linked to it. Per the rank map: don’t move it unless that location is ranking 16+. The homepage stays pinned to wherever the rankings dictate.

Decision 3: City-agnostic category/service pages (high-competition markets only)

In high-competition markets, you may need duplicate category/service pages WITHOUT city names for site navigation:

/hardscape/ — generic page for nav and crawling structure.
/redding/hardscape/ — city-specific page for ranking “hardscape Redding.”
/eureka/hardscape/ — city-specific page for ranking “hardscape Eureka.”

Why: A nav bar that points to /redding/hardscape/ when a Eureka visitor lands creates cross-location confusion. The city-agnostic page is the navigation hub. The city-specific pages do the ranking work.

When to use this pattern:

3+ locations
Same primary category across locations
Highly competitive primary keyword

When to skip:

2 locations only
Different category mix per location
Low/medium competition

Phase 2: Build Out Each Location Landing Page (Mini-Homepage Pattern)

Each new location landing page is structured as a “mini-homepage” with its own Core 30 hierarchy. Treat it like building a new homepage for a brand-new business.

Required elements on every location landing page

Above the fold:

H1 with target keyword: [Primary GBP Category] [City] (extra context words OK — e.g., “Top-Rated Hardscape Contractor in Redding, CA”).
City-specific hero image or photo of the new office.
Primary CTA with the location’s distinct phone number.
Embedded Google Maps showing the location’s actual address.

Body:

Subheadings for each of the location’s GBP categories (up to 10 total).
50-100 words of city-specific content under each subheading.
Internal link from each subheading block to the corresponding city-specific category/service page.
Embedded reviews specific to that location (Google reviews from that GBP, not all reviews company-wide).

Local trust signals:

City-specific testimonials if available.
Photos of completed projects in that city.
Mention of nearby neighborhoods, landmarks, or service areas the location covers.

Schema (mandatory — see Phase 4 for details):

Local Business schema matching this location’s specific GBP.
Postal Address schema.
Opening Hours schema matching the location’s actual posted hours.
Geo Coordinates if available.

Footer / contact section:

Location’s distinct phone number (NOT a number shared with another GBP).
Location’s full street address.
Location-specific hours.

Page count by phase

For the GBP prep phase (before GBP creation), the minimum viable buildout per the Preparing a New Address for GBP Creation SOP is:

1 location landing page
2-3 city-specific service pages for the highest-priority services in that market
Locations index page (if not already in place)
Site nav update

For the post-verification full buildout, scale to a complete Core 30 for the location:

1 location landing page (already built)
~10 city-specific category pages
~11+ city-specific service pages
Supporting topical content (PAA-driven articles) over time

Page count math for multi-location clients

Locations	Approximate page count
1 location	12-30 pages (Core 30)
2 locations	~40 pages
3 locations	~60-90 pages (Core 90)
5+ locations	Scale by rank map — don’t build unnecessary pages

Don’t blindly multiply. Use rank tracking data to guide priorities. If location 2 already has good topical relevance with 12 pages, don’t build the remaining 18 just to hit “Core 30 for that location.”

Phase 3: City-Specific Category and Service Pages

Each new location needs city-specific category and service pages internal-linked from the location landing page.

URL pattern

Match the URL pattern picked in Phase 1. If the location landing page is /redding/, then:

Category page: /redding/hardscape/
Service page: /redding/paver-patios/

Page structure

Each city-specific page follows the standard Core 30 structure but with the city baked into:

Title tag: [Service] [City] | [Brand]
H1: [Service] [City] (extra context words OK)
URL slug
2-3 mentions in opening paragraph
At least one mention in every major section
Schema: include city in addressLocality for Local Business schema referenced on the page

Internal linking from the city-specific pages

Each city-specific page links:

Back to the location landing page (breadcrumb + body link)
Sideways to 2-3 sibling city-specific pages within the same location
NOT to the equivalent page in a different location (cross-location linking dilutes the geographic signal)

Phase 4: Schema Requirements

Schema is where multi-location sites either rank well or look like a single confused entity to Google. Get this right.

Per-location landing page

Each location’s landing page gets its OWN Local Business schema block matching its specific GBP. This is non-negotiable.

Required fields:

@type: LocalBusiness (or a more specific subtype like HomeAndConstructionBusiness)
name: business name (same across all locations)
address: this location’s PostalAddress (street, locality, region, postal code, country)
telephone: this location’s distinct phone number
url: the location landing page URL (NOT the homepage)
image: location-specific image
openingHoursSpecification: this location’s hours
geo: GeoCoordinates if available
sameAs: link to this location’s GBP, this location’s Yelp, Facebook, etc.

Site-wide

Organization schema can go everywhere. Local Business schema does NOT go on every page — only on the relevant location landing page.

Shared service pages

If you have a city-agnostic service page (e.g., /hardscape/ for nav), it should NOT have Local Business schema. It’s a navigational/topical page, not a location page. Use Service schema instead.

Validation

After every multi-location schema implementation, run the schema through Google’s Rich Results Test and Schema.org validator. Errors here block rich snippets and confuse local intent matching.

Phase 5: Internal Linking Strategy

Internal linking on a multi-location site is where most teams accidentally cross-pollinate signals. Rules:

From the homepage

Link to each location landing page from the main nav and footer.
The location currently linked to from the homepage’s “Contact” / hero CTA is the location whose GBP points at the homepage.
Don’t link to city-specific service pages from the homepage. The homepage links to the location landing pages, which link to the service pages.

Between location landing pages

Locations index page (/locations/) lists all locations and links to each.
Individual location landing pages may link to other location landing pages (e.g., “We also serve [Other City]”), but lightly. Don’t make them feel like alternates.

Within a single location

Location landing page → city-specific category pages → city-specific service pages.
Sibling links between city-specific pages within the same location are fine and encouraged.

Across locations (the trap)

City-specific service pages do NOT link to the equivalent service page in another location.
/redding/paver-patios/ does not link to /eureka/paver-patios/.
Doing so dilutes the geographic signal and confuses Google about which page should rank for which city query.

Phase 6: Update Each GBP to Point at the Right Landing Page (Carefully)

Once the new location landing pages are live and indexed, update each GBP’s website URL to point at its dedicated landing page.

Before changing the URL on a GBP

Re-read the rank map from Phase 0. If the location is ranking top 3, do not change the URL even if you’ve now built a “proper” landing page. The current URL is working. Leave it.

If the location was in the “restructure” group in Phase 0, proceed:

Confirm the new landing page is live and indexed (check site: operator on Google).
Confirm all schema validates without errors.
Confirm the new page has at least 50% of its full content (don’t point a GBP at a half-built page).
Update the GBP website URL field.
Document the change date in Task Tracker.
Monitor rankings daily for the first 2 weeks. Some short-term dip is expected and usually recovers within 30-60 days.

What to expect after a URL change

Short-term: rank dip of 1-5 positions, sometimes more.
Medium-term (30-60 days): recovery, often to better positions than before.
If rankings don’t recover by day 60, reassess. May need to add content, build links to the new page, or revert.

Hard rule

If a GBP is ranking 4-10 average and you’re tempted to “improve” it with a new landing page, don’t. The risk-reward at that ranking band isn’t worth it. Save restructuring for the locations ranking 16+ where there’s nothing to lose.

Definition of Done

Multi-location structure work is complete when ALL of the following are true:

Common Issues

Inherited client has all GBPs pointing at the homepage and rankings are mixed

Run the Phase 0 rank map. Only restructure the locations ranking 16+ average. Leave the rest alone, even if it feels structurally “wrong.” This is exactly the 8-location example from the training: 6 of 8 stayed pointed at the homepage and kept ranking top 3.

Client wants identical content on every location landing page (just swap the city name)

Don’t. Google detects city-swap duplicate content easily. Each location landing page needs unique:

Photos
Testimonials
Mentions of local landmarks/neighborhoods
Service emphasis (different markets, different demand mix)

If the team can’t write unique content per location, build fewer landing pages and let some locations stay on the homepage (only safe if those locations are ranking).

Client doesn’t want to use distinct phone numbers per GBP

Push back. Tracking numbers that route to the same call center cost ~$5/month per number and are the standard solution. Sharing the same phone across GBPs creates duplicate-business signals. If the client refuses, document the decision and the risk in Task Tracker.

Adding a new location to an existing single-location site

The existing single location is already on the homepage and presumably ranking. Don’t move it. Build a new location landing page at /locations/[new-city]/ (or whatever URL pattern you pick), link it from nav and footer, and let the new location’s GBP point at it. The original homepage location stays where it is.

City-agnostic service page outranks the city-specific one for the city query

This means the city-specific page is too thin. Beef up the city-specific page with more unique content, more local references, and more internal links from city-specific siblings. Don’t delete the city-agnostic page — it serves a navigation purpose.

gbp/preparing-new-address-for-gbp.md — The SOP that triggers this one when a new GBP is being prepped.
csm/sourcing-virtual-office-for-gbp.md — Where the new address gets sourced.
AI SEO Mastery Pro, “Structure for Multiple Locations” lesson — primary source for this framework.
AI SEO Mastery Pro, “Core 30 Structure Breakdown” — the underlying structure each location landing page replicates.
BrightLocal — multi-location citation campaign management.

Version Control:

v1.0 (2026-05): Initial draft. Codifies the AI SEO Mastery Pro multi-location framework — rank-map-first rule, mini-homepage pattern, distinct phone numbers, schema per location, internal linking rules, and the “don’t touch it if it’s ranking” guardrail.