How should a multi-location business structure its sitemaps?
Split by section — core, services, locations, service-by-location, blog — and publish a sitemap index. Search Console reports indexing per submitted sitemap, so the split turns the sitemap into a diagnostic: a low rate on one file while others index fine shows exactly where the quality problem sits.
Split so the reporting is useful
Search Console reports indexing per submitted sitemap. That makes the split a diagnostic decision, not a housekeeping one.
A structure that pays off:
/sitemap.xml (index)
/sitemap-core.xml home, about, contact
/sitemap-services.xml service pages
/sitemap-locations.xml one page per location
/sitemap-loc-svc.xml service x location pages
/sitemap-blog.xml posts
Now a low indexing rate on sitemap-loc-svc.xml while services and locations index fine tells you exactly where the quality problem is. A single file tells you nothing.
The service-by-location matrix is where problems live
Six services across five locations is thirty pages, and if they were generated from a template with the city name swapped, most of them are duplicates in substance.
Audit that set specifically:
- Sample several and read them side by side
- Ask whether anything on the page could only be true of that location
- Check whether they carry distinct titles, or the same title with a swapped city
If they are template-identical, the sitemap is not the problem — publishing them was. Reduce the matrix to combinations you can genuinely write about.
Check each location page against the profile
Every location page should correspond to a real, staffed address with its own Google Business Profile, and the address, phone number and hours must match exactly between them.
A location page for a place with no physical presence is a liability, not an asset.
Watch for cross-location duplication
Common failures across multi-location sites:
Shared phone number. A single tracking number on every location page undermines the distinctness of each.
One canonical for all. A misconfigured template canonicalising every location page to a hub means none of them index.
Identical schema. LocalBusiness markup copied with the same address across all pages.
Store locator only. Locations existing solely inside a JavaScript locator with no crawlable URL.
Verify each file independently
Status-check every URL, per file, and record the counts:
for f in core services locations loc-svc blog; do
n=$(curl -s https://example.com/sitemap-$f.xml | grep -c '<loc>')
echo "$f: $n URLs"
done
Then compare submitted against indexed for each in Search Console, and track the ratio over time rather than as a snapshot.
What this costs to run properly
Multi-location structure of this kind sits in Authority Builder — $12,500 setup, $3,500 a month, where the location and service matrix is built deliberately rather than generated. Growth Engine at $5,500 and $1,500 suits two or three locations.
The honest limit
Splitting sitemaps improves your visibility into the problem. It does not fix pages that are near-identical, and no sitemap structure rescues a location page for an address that does not exist.
Frequently asked questions
Why split sitemaps by section?
Because Search Console reports indexing per submitted sitemap. Splitting by content type turns the sitemap into a diagnostic: a low rate on one file while others index fine tells you exactly where the problem is.
How do I audit service-by-location pages?
Read several side by side and ask whether anything on each page could only be true of that location. If they are template-identical with a swapped city name, the problem is that they were published, not the sitemap.
Does every location need a page?
Every real, staffed address with its own Google Business Profile should have one, with address, phone and hours matching exactly. A page for a location with no physical presence is a liability.
What breaks most often on multi-location sites?
A shared tracking phone number across all locations, a template canonical pointing every location page at one hub, identical LocalBusiness schema, and locations that exist only inside a JavaScript store locator with no crawlable URL.
Will better sitemaps fix low indexing?
No. Splitting improves your visibility into the problem. Near-identical pages stay near-identical, and no sitemap structure rescues a page for an address that does not exist.