Multi-branch local SEO is where most South African businesses quietly lose 30 to 50% of the leads they could be capturing. The single biggest reason: the Johannesburg branch and the Pretoria branch share one Google Business Profile, the website has one generic "Contact" page, and the citation graph treats the two locations as the same business. The algorithm does the same.
This post is the operating manual we use for clients running multi-branch businesses across Johannesburg, Sandton, Cape Town, Pretoria and uMhlanga, and the same framework applies for franchises, law firms with multiple offices, retail chains and any other business that shows up in more than one South African metro.
The single biggest mistake multi-branch businesses make
Sharing one Google Business Profile across branches. The reasoning always sounds reasonable: "we are one business." The algorithm disagrees. Google Maps indexes locations, not businesses. A single GBP cannot have two addresses, two phone numbers, two sets of hours and two review streams without losing half the signals.
The correct setup:
- One GBP per physical location, each with its own address, phone, hours, reviews and owner access.
- A "brand" GBP at the head office, if the head office is a separate location with its own signage and customer traffic. Skip it if the head office is just an admin building.
- A website with one location page per GBP, internally linked back to a single brand pillar.
That is the foundation. Everything else assumes it.
Hub-and-spoke or all-spokes — the architecture decision
Multi-branch websites have two viable architectures. Pick one and apply it consistently:
- Hub-and-spoke. One pillar page at
/services/local-seo/with a "Locations" section, and one location page per branch at/services/local-seo-{city}/. Each location page links back to the pillar; the pillar links down to every location. The location pages rank for "[service] + [city]" queries; the pillar ranks for "[service]" queries. - All-spokes. One page per branch, no central pillar. Each location page targets "[service] + [city]" and cross-links to its sibling location pages. No pillar page exists for the service; the brand homepage absorbs the "[service]" queries.
We default to hub-and-spoke. The pillar carries the entity's authority and passes it down to every spoke through internal links; the spokes target the local intent without competing with each other for the central keyword. All-spokes works for franchises with strong local brand recognition, but it leaks authority without a central pillar to consolidate it.
For a five-city South African business, the URLs look like:
/services/local-seo/— pillar/services/local-seo-johannesburg/— branch page/services/local-seo-sandton/— branch page/services/local-seo-cape-town/— branch page/services/local-seo-pretoria/— branch page/services/local-seo-umhlanga/— branch page
The branch pages cross-link to each other through a "Other locations" block at the bottom of each page, and each one links back to the pillar through a breadcrumb and an inline anchor.
GBP ownership, access and reporting (the ops reality)
The architectural decision is the easy part. The hard part is GBP ownership and access. The pattern that prevents the most common multi-branch failure:
- One owner per branch GBP. The branch manager or a delegated local marketing person. Owner access is required for verification, category changes and the things that cannot wait for a head-office round of approvals.
- One manager per brand. Head office holds manager access on every branch GBP. Manager access is sufficient for posts, photos, responses and most day-to-day work.
- No shared logins. Each person with access uses their own Google account. Shared logins are a security risk and a Google guidelines risk.
- A documented access list. A simple spreadsheet with branch, role, account email, recovery email and last review date. Audit quarterly.
The reporting cadence that keeps this manageable:
- Weekly. Branch manager runs the GBP insights export and posts it to a shared channel. Calls, direction requests, website clicks, photo views.
- Monthly. Head office consolidates the five branch exports, compares to the previous month, and flags any branch with a 20% drop in calls or direction requests.
- Quarterly. A full GBP audit across all five branches, using the GBP checklist as the rubric.
A spreadsheet beats a dashboard for most multi-branch South African businesses under 20 locations. Dashboards become useful at 30+ locations.
NAP and citations per branch — what must match, what can differ
The NAP consistency article covers the single-location case in detail. The multi-branch extension is:
- Name must match across the branch's GBP, the branch's website page and the branch's citations. "Page Panther Johannesburg" vs "Page Panther Sandton" is acceptable as long as the format is consistent. "Page Panther (JHB)" vs "Page Panther Sandton" is not.
- Address must be the branch's physical address. Not the head office address, not a registered address that does not match the storefront. Google verifies by postcard or video, and a mismatch triggers soft-suspension.
- Phone can be the branch's local number or a central routing number. Either works. The consistency matters — pick one approach and apply it across every branch.
- Hours can differ per branch. A Pretoria branch that closes for lunch and a Sandton branch that does not should both show their actual hours. Fake consistency hurts pack visibility.
The citation graph is per-branch, not per-brand. Each branch has its own Yellow Pages listing, its own TrueLocal profile, its own AfriBiz listing. A multi-location platform like Moz Local or Yext can manage them centrally, but the underlying entities are still per-branch.
The location-page template that scales
A multi-branch location page should be built once and reused with city-specific content swapped in. The template we use:
- Hero. Service name + city. "Local SEO in Sandton." H1, description, CTA.
- Why this branch. Two paragraphs on what makes the Sandton branch distinct — suburb coverage, industry specialisation, founder background, recent projects.
- Suburbs served. A grid of the suburbs the branch covers, with internal links to the same suburb mentioned on the website's other pages.
- Services offered. The branch's full service list, with internal links to the central service page.
- Case study or proof point. One recent project from this specific branch, with a measurable outcome.
- FAQ. Five to seven city-specific questions — pricing for the city, response times, coverage radius, payment methods, parking.
- Contact. Branch-specific phone, address, hours. Map embed. CTA.
- Other locations. A small block linking to the other four branch pages.
Each branch page should be 80 to 90% the same structure, 10 to 20% city-specific copy. The schema on each page should include LocalBusiness with areaServed set to the specific city, and an address block matching the GBP exactly.
Reporting: how to keep branch managers honest without becoming a dashboard
Multi-branch local SEO has a unique reporting challenge: branch managers control the inputs (reviews, posts, photos) but the outputs (calls, direction requests, conversions) often get attributed centrally. The pattern that balances both:
- Per-branch GBP insights, weekly. Sent to the branch manager, with a comparison to the previous four weeks.
- Per-branch pack visibility, monthly. A rank-tracker run for the top five "[service] + [city]" queries per branch. Sent to both the branch manager and the head-office marketer.
- Per-branch conversion events, monthly. Phone calls from the GBP, contact form submissions from the branch page, bookings. Tracked through call tracking and UTM-tagged URLs.
- Per-branch review velocity, monthly. New reviews per branch, response rate, average rating.
The single most important metric is calls from the GBP per branch per month. It is the most direct measure of local SEO success and the one branch managers understand without translation.
A Local SEO engagement scoped per branch — typically 4 to 6 hours of senior strategist time per branch per month — covers the architecture, the GBP work, the citation cleanup and the reporting. For a five-city business, that lands at roughly 20 to 30 hours per month, delivered through quarterly sprints.
FAQ
Do I need a separate website for each branch?
No. One domain, one location page per branch, internally linked back to a central pillar. The algorithm reads the internal link graph, not the file structure.
What if two branches share a building?
Two separate GBPs with the same address but different suite numbers, different phone numbers and different entry signage. The verification is harder — Google may ask for proof of separate entrances or separate signage — but it is achievable.
Can I run GBP posts from head office across every branch?
Yes, with manager access on each branch GBP. The cadence is one post per branch per week. Head office can write the posts centrally if the brand voice is consistent, but each post should reference the specific branch's city or service area.
What happens when a branch closes?
Mark the GBP as permanently closed. Do not delete it — closing preserves the review history and prevents a future tenant from claiming a profile that does not match their business. Update the website to remove the branch page; let the GBP close page sit as a soft redirect.
How do I prevent a branch manager from breaking the GBP?
Owner access at head office. Manager access for the branch. A documented playbook covering what the branch can and cannot change without approval. Quarterly audits using the same checklist.
If you are running a multi-branch business and want a second opinion on the architecture before the next branch opens, send us the branch list and the cities. Most multi-branch local SEO problems are visible in the GBP access list and the location-page template — fixing those two is usually enough to recover 30% of lost pack visibility inside one quarter. The Local SEO engagement is scoped per branch so the work matches the actual footprint.