
City pages and location pages are two different tools for local search, and confusing them leads to wasted effort and thin content penalties. This guide explains the difference, when to use each, and how to build them in a way that actually drives local rankings.
The most common question I get from service businesses expanding their local SEO is some version of: "Should we build pages for each city we serve, or pages for each of our physical locations?" The answer is: those are two completely different things, and you may need both, or just one.
Conflating city pages and location pages leads to the same mistake every time: building one when you needed the other, or building both but treating them the same way. Let me be specific about what each is, when to use each, and how to build them correctly.
City pages are website pages targeting specific cities where a service-area business operates but does not have a physical location. They're used by businesses that serve customers across multiple cities but work from a single base or no fixed location.
Examples of businesses that need city pages:
City pages answer the question "Do you serve [city]?" for both Google and potential customers.
What a city page is not: A city page is not a physical location, there's no office, no storefront, no employees based there. It's a geographic content signal that tells Google your service is available in that area.
Location pages are website pages for each of a business's physical locations. They're used by businesses with multiple offices, stores, clinics, or service centers.
Examples of businesses that need location pages:
Location pages answer the question "What's at this specific location?" for both Google and customers looking for the nearest branch.
What a location page is not: A location page isn't just a list of your physical addresses, it's a full page with unique, location-specific content about that particular branch.
| Factor | City Pages | Location Pages |
|---|---|---|
| Physical presence | No, service only | Yes, office, store, or clinic |
| GBP associated | No (service-area listing) | Yes, each location has its own GBP |
| Primary purpose | Rank for service + city queries | Rank for individual location searches |
| Content approach | Service availability in that city | Unique details about that specific location |
| Schema type | Service schema with areaServed | LocalBusiness schema with address |
| Typical volume | 3–20 pages for main service areas | 1 page per physical location |
Build city pages when:
The honest caveat: City pages work when they contain genuinely useful, location-specific content. A page that just swaps the city name into a template, "We offer plumbing services in Round Rock", is thin content. Google identifies these and they rank poorly or not at all.
City pages that rank are ones with genuinely different content per city: specific neighborhoods served, local context (water quality issues in that city, building age of housing stock, local permit requirements), customer examples from that area, and specific service details relevant to that market.
Build location pages when:
One location per GBP rule: Google requires a separate GBP listing for each legitimate physical location. Each GBP listing should have a corresponding location page on your website. This creates a consistent digital footprint across Google Maps and your website.
For franchise businesses and chains, location pages are non-negotiable, they're how each location gets its own SEO presence while benefiting from the brand's overall domain authority.
A city page that ranks isn't template content with the city name swapped. Here's the structure for a city page that Google treats as genuinely useful:
URL: /[service]-[city] or /[city]/[service]. Example: /plumbing-round-rock or /round-rock/plumbing.
Page title (H1): "[Service] in [City, State] | [Business Name]"
Opening section (200–300 words):
Services section: List your services with brief descriptions. Can match other city pages in structure but should have some city-specific context where possible.
Why choose you section: Credentials, experience in that specific area, any local partnerships or associations.
Service area map: Embed a Google Map showing your coverage in that city.
Reviews from that area: If you have reviews from customers in that city, feature them. If not, feature your general reviews with a note about serving that area.
CTA: Click-to-call and contact form, specific to that city if possible ("Contact us for [city] service").
Schema: Service schema with areaServed set to the city name, plus your standard LocalBusiness schema.
Each location page is the online home for that specific branch, and it needs to be genuinely differentiated from your other location pages.
URL: /locations/[city-neighborhood] or /[city-neighborhood]-location.
Must-haves unique to each location page:
Schema: Full LocalBusiness schema with the exact address, hours, phone, geo coordinates, and a link to the associated GBP listing.
The differentiation test: Could you swap the content from one location page onto another with minimal editing? If yes, your pages aren't differentiated enough and Google will treat them as near-duplicate content.
Mistake 1: Template city pages with swapped city names. Google identifies this immediately. Each city page needs genuine local context, even 2–3 sentences of city-specific content per section makes a significant difference.
Mistake 2: Building city pages for cities you barely serve. City pages for cities where you've done 2 jobs in 3 years aren't genuinely informative, they're manufactured content. Build city pages for cities where you have real service history and genuine intent to grow.
Mistake 3: Location pages with no unique information. "Visit our [city] location!" with your address and nothing else is not a location page, it's a placeholder. Each location page should be a complete resource for that branch.
Mistake 4: No internal linking. Your city and location pages need internal links from your homepage, service pages, and blog posts. Orphan pages (pages with no internal links pointing to them) rank poorly.
For businesses with multiple physical locations, Flento's multi-location dashboard manages all GBP listings from a single interface, making it practical to maintain consistent optimization across all locations without logging into each GBP separately.
For NAP consistency, Flento's Business Listing Management Software ensures that each location's address, phone, and name appear consistently across directories, critical for businesses where each location has its own phone number and address that need to be tracked independently.
For city pages:
For location pages:
✅ Done? Manage all your location GBP listings from one dashboard with Flento → Try Flento free
How many city pages should I build? Start with your top 3–5 most important service cities, where you have the most customers or the most growth potential. Build those pages well before expanding. 5 good city pages outperform 20 thin ones every time.
Can I have both city pages and location pages for the same market? Yes, if you have a physical location there. Your location page covers the physical branch; your city page can cover the broader surrounding metro area if you serve beyond your immediate location's neighborhood.
Do city pages help Google Maps rankings or only organic? Primarily organic. City pages support organic search rankings for "[service] in [city]" queries. Google Maps rankings are driven by your GBP listing, not your website pages, though strong website domain authority does correlate with stronger GBP performance.
What's the minimum word count for a city page? There's no magic number, but 400–600 words is generally sufficient to provide enough content for Google to evaluate relevance and extract meaningful passages. Focus on content quality over length.