Multi-Location SEO: A Developer's Guide to Location Pages

Multi-location SEO is the work of making every place your business serves findable in search. For most businesses that means one page per location, and that is where the trouble starts.

Pages get copied, the city name gets swapped, and a year later nobody knows which ones are accurate. I have built and run location page systems for a 13-dealership auto group and for a home-buying business, so this guide comes from the build side: data, code, tracking, and upkeep.

What multi-location SEO is and what it is not

It is a system for presenting accurate, useful information about each location to people and to search engines. The system includes pages, structured data, Google Business Profile listings, citations, internal links, and measurement.

It is not a trick for ranking in many cities with one page repeated. Search engines treat that pattern as spam, and visitors treat it as noise.

Who needs this guide

You likely need it if one of these describes you:

• You operate several stores, offices, clinics, or branches.
• You serve many towns from one base and want to be found in each.
• You manage a dealership group or franchise with shared branding.
• You are about to build hundreds of city pages and want to avoid the common failures.
• You inherited a set of location pages and cannot tell which still help.

If you have one location, most of this still applies at a smaller scale. A single well-built page beats ten thin ones.

Start with the data, not the pages

Before writing any page, build a clean record for every location. In a spreadsheet or a database, the record is the source of truth that pages, listings, and schema all read from.

A useful location record includes:

• The business name as it should appear everywhere
• Street address, city, state, and postal code
• Phone number and hours, including holiday exceptions
• The services or departments offered at that location
• The primary category for the Google Business Profile
• The manager or contact who verifies the facts
• The date each fact was last verified

When pages are generated from this record, every page agrees with every other page by construction. When pages are written by hand, they drift apart.

Choose a URL structure that scales

Put location pages in subfolders on your main domain, such as /locations/fort-worth/. Subfolders share the authority of the main site and keep reporting simple, while separate domains split your effort and your measurement.

For businesses with many places, a hierarchy makes the structure clear to people and crawlers. A pattern like state, then county, then city gives every page a parent and a set of siblings.

I used this pattern on a Django site that covers Texas, Kentucky, and Indiana. A city page lives at /where-we-buy/{state}/{county}-county/{city}/, and county and state index pages sit above it. You can read the city landing pages case study.

Keep URLs short, lowercase, and readable. Avoid dates and numeric strings, because they age badly and tell nobody anything.

What every location page needs

A location page has one job: give a person who is near that location what they need to act. The strongest pages combine fixed facts with local detail.

Facts that must match everywhere

The name, address, phone number, and hours on the page must match the Google Business Profile and every listing. Even a small mismatch weakens trust signals and confuses customers.

Generate these facts from the location record instead of typing them. One edit then fixes every page.

Local detail that cannot be faked

Add information that only makes sense for this place: real photos of the location, directions and parking, the staff who work there, nearby landmarks, and reviews from local customers. If a page would read the same with a different city name, it needs more.

Local detail is also the part that takes real effort. Plan who collects it, because someone has to visit, ask, or call.

Services and calls to action

State which services are available at this location, and point to the action you want: call, book, or visit. A page that lists services the location does not offer will frustrate visitors and waste ad and search traffic.

Physical locations versus service areas

A physical location page represents a place customers can visit. A service area page represents a place you travel to or serve remotely.

The difference matters for honesty and for search guidelines. A service area page should say plainly how you serve that area and show proof that you do, such as projects completed there or the team that covers it.

Do not give a service area page an address you do not have there. The page should help a person in that area decide to call, not pretend that you have a storefront.

How to avoid doorway pages

Google’s spam policies describe doorway abuse as creating pages to rank for specific, similar searches that lead users to intermediate pages that are less useful than the final destination. Among the examples are many pages aimed at specific cities or regions that funnel people to one page, and substantially similar pages that look more like search results than a browseable hierarchy.

The policy is the reason to build location pages with care. A set of pages with the same body text and a different city name matches the pattern the policy describes.

Use this test on every page you plan:

1. Would a person who lands here find something they could not find on a sibling page?
2. Does the page contain facts, photos, or content specific to this place?
3. Does it sit inside a clear hierarchy that a person could browse?
4. Does it lead to a real service, not to a single form that every page shares?

If you answer no to the first two questions, merge the page into a stronger one or do not publish it.

Titles, descriptions, and headings at scale

Search results show your title tag and description, so each page needs its own. Build them from real fields, such as the service, the city, and the state, with a pattern you can read aloud.

A good title puts the main term first and stays within about 50 to 60 characters. A good description gives the reason to click in the first 120 characters or so, which is what shows on small screens.

Each page should have one H1 that matches the title closely, and H2 headings that cover the actual sections. On my city pages, the H1 and section headings carry the city name and are built from the same record as the title tag.

Check for duplicates before you launch. A simple script that lists every title and description and flags repeats saves a lot of cleanup later.

Structured data for locations

Structured data tells search engines what a page is about in a form they can read directly. I write it as JSON-LD and keep it matched to what is visible on the page.

For a physical location, a LocalBusiness type, or a more specific subtype, can carry the name, address, phone number, hours, and URL. A BreadcrumbList describes where the page sits in the hierarchy, and an Organization on the home page ties the locations together.

On the city pages I built, each page includes a schema.org WebPage block with the name, description, and publisher organization, all carrying the city. On a careers site I built, each job page carries JobPosting markup with fields for title, location, employment type, hours, pay, and hiring organization. You can read about it in the careers site case study.

Rules I follow for markup:

• Mark up only what is visible on the page.
• Use the same facts in markup that appear in the text.
• Validate with Google’s Rich Results Test and the Schema.org validator.
• Re-check when content changes, because markup goes stale like any other content.

Invalid or misleading markup is worse than none, since it can cost you eligibility for rich results.

Internal linking between locations

Pages that nothing links to are hard for crawlers to find and easy for visitors to miss. Link each location from your main navigation or a locations hub, and link sibling locations to each other.

On the city pages I built, each page links to more cities in the same county. That gives crawlers a path and gives visitors a next step if they are near a neighboring town.

Also link from related service pages and from blog or guide content. Use descriptive link text that names the place or service.

Google Business Profile and the pages it links to

For physical locations, each place needs its own Google Business Profile with a verified listing. Each profile should link to its own location page, not the home page, so the person who clicks lands where the information is.

Keep the category, hours, phone number, and URL aligned with the website. Add UTM parameters to the profile link so you can tell profile traffic apart from other sources in analytics.

I have experience with Google Business Profile in a multi-location setting. At a dealership group I built an inventory feed that produced organic vehicle listing ads for the profile, which Google has since ended. You can read that story in the inventory ad feed pipeline case study.

Citations and name, address, and phone consistency

Citations are mentions of your business details on other sites, such as directories and maps. They are most useful when they agree with each other and with your site.

Keep one master sheet as the single source of truth, with a column for the last time each location was verified. Audit the main platforms on a schedule and log what you fix, so you can see which ones keep drifting.

Pick the platforms by relevance. Major maps and review sites matter for almost everyone, and industry directories matter for some.

Tracking each location

If you cannot measure a location, you cannot tell whether its page is working. Build measurement into the page structure from the start.

Name your URLs so you can filter them

I give my custom pages a consistent URL pattern. At World Car, my custom pages used a shared prefix, and location pages ended in a state suffix. Then I could pull them out as a group with a regular expression.

In Google Search Console, the page filter matches the full URL, so use a fragment like /wc- and not a start anchor. In GA4, the page path filter matches the path alone, so a start anchor works there.

Events and conversions

Set up GA4 events for the actions that matter: calls, form submissions, direction requests, and bookings. Use Google Tag Manager so changes do not require a code release each time.

Attribute traffic by location

Add UTM parameters to listing links and ad URLs, and include a location identifier. That lets you roll results up by location and compare them.

Reporting by location

A report that mixes every location together hides the ones that need help. Build a view that shows traffic, key actions, and trend for each location, and a rollup for leadership.

I build these in Google Data Studio, fed by Google Sheets and Google Apps Script when the data needs cleaning first. The point is that someone can open one report and see which locations are healthy.

Audit existing location pages first

If pages already exist, audit before you build anything new. The goal is to sort every page into keep, improve, merge, or remove.

1. Crawl the site with a tool such as Screaming Frog and export every URL, title, description, H1, and status code.
2. Pull the same URLs from Google Search Console and see which get impressions and clicks.
3. Flag duplicate titles, duplicate descriptions, and pages whose body text matches a sibling.
4. Check each page’s facts against the location record.
5. Decide the fate of each page and write the reason down.

Pages that get no traffic and add nothing are candidates for merging into a stronger page. Merge with a permanent redirect so that old links still land somewhere useful.

Roll out in phases

Do not launch every location at once. Start with the flagship locations or the markets with the most customers, and treat them as the template test.

Check how the first pages are crawled and indexed in Search Console. Fix what the first batch teaches you, then roll the same workflow out to the rest. A phased launch also lets the people at each location verify their facts without a deadline crush.

A sample location page outline

This outline works for most businesses. Adjust the sections to fit the location and the service.

• H1: the main service and the place, matching the title tag
• Opening paragraph: who the location serves and what makes it useful, in two or three sentences
• Key facts: address, phone, hours, and a map link, generated from the record
• Services at this location: only what the location actually offers
• Local detail: photos, directions, parking, and the people who work there
• Reviews or proof: feedback from customers of this location, when available
• Questions people ask: answers specific to this location, marked up as an FAQ when appropriate
• Nearby locations: links to siblings in the same area
• Call to action: one clear next step

Write the opening paragraph and the local detail by hand or from a real interview. Generate the key facts from data.

Maintenance: plan the refresh before you publish

Pages decay. The organic traffic from the SEO pages I built for the dealership group dropped significantly over about eight years, because nobody kept up maintenance. I wrote about the pattern in Why SEO Pages Need Refresh Cycles.

More pages mean more upkeep. Every location page is a promise to keep hours, staff, offers, and photos accurate.

A refresh plan needs:

1. An owner for each group of pages
2. A review date set at publication
3. A checklist covering facts, links, photos, and markup
4. A way to retire or merge pages that no longer serve a purpose

If your team cannot keep up with fifty pages, publish twenty and keep them excellent.

Common mistakes

Swapping the city name and nothing else

This is the fastest way to create pages that add no value and may match the doorway pattern. Each page needs content that is specific to its place.

Publishing before the data is verified

Wrong hours or a wrong phone number on a location page costs real customers. Verify with the people at each location before launch.

Ignoring the Google Business Profile

A great page with a neglected profile loses to a competitor with both. Treat them as one system.

Having no measurement plan

If you did not name your URLs and set up events, you will not know which pages work. Decide how you will measure before you build.

Treating launch as the finish line

The work that decides success starts after publishing. Budget time for upkeep from the first day.

A build checklist

1. Create a verified record for every location.
2. Choose a subfolder URL structure with a clear hierarchy.
3. Generate pages from the records so facts match everywhere.
4. Add local detail that is real: photos, directions, people, and reviews.
5. Build unique titles, descriptions, and headings from real fields.
6. Add JSON-LD that matches the visible page, and validate it.
7. Link locations from navigation and from each other.
8. Link each Google Business Profile to its own page.
9. Keep citations consistent with the master sheet.
10. Name URLs so you can filter them in Search Console and GA4.
11. Set up events, conversions, and UTM tracking by location.
12. Build a report by location.
13. Set owners and review dates for every page.

What this looks like in practice

At World Car Auto Group, I ran SEO for 13 dealerships. The work included city-based strategy, custom pages with structured URL naming, and reporting automated with Google Apps Script.

For Aquifer Investments, I built a Django site where every city page is generated from city, county, and state data and carries its own metadata and JSON-LD. I have no ranking or lead numbers for it, so I do not publish any.

On the World Car Careers site, city-targeted job pages averaged about 460 users per month over nine months, and 451 unique users submitted an application, per GA4. Traffic has fallen since the listings stopped being updated, and that is the clearest example I have of why upkeep belongs in the plan.

Frequently asked questions

How many location pages do I need?

You need one page for each location a customer can visit, and for each service area where you can show real work. Fewer strong pages are better than many thin ones.

Can I use the same text on every location page?

Shared text is fine for things that really are the same, such as your policies. The page as a whole needs content that is specific to the place, or it risks looking like a doorway page.

Should I use subfolders or subdomains?

Subfolders work for most businesses, because they keep authority and measurement together. Subdomains and separate domains are harder to manage and rarely help.

Do I need LocalBusiness schema on every page?

Pages for physical locations benefit from it, and it should match the visible details. Service area pages may need a different approach, so check that the markup does not claim a storefront you lack.

How do I know which location pages are working?

Name your URLs consistently, filter them in Search Console and GA4, and track calls and forms by location. Then compare locations against each other over time.

How often should I update location pages?

Set a review date when you publish, and check facts at least on a regular schedule. Update sooner when hours, staff, or offers change.

Can you build a location page system for me?

Yes. I design the data model, build the pages, add the markup and tracking, and set up the refresh plan. See technical SEO services or request a quote.

Next steps

If you are planning a location page system, or you inherited one that is not working, tell me about it. I will reply with what I would check first.

Request a quote or read how engagements work.