One “Areas We Serve” page or many city pages for local SEO?

August 12, 2025 · 9 min read

Use this decision rule: launch one Areas We Serve hub now; add city pages only when each page has real local proof. Includes URL, links, schema, and build order.

You serve 15 towns. What should you publish next?

You’ve got one “We serve Greater Metro” line in your footer and a Google Business Profile with a scattered set of cities. That won’t rank well or convert.

Start with a single, useful Areas We Serve hub. Then add city pages only when you can prove you actually work in that city (photos of jobs, reviews from locals, constraints, map). This tracks with guidance to prioritize key cities first and expand only as you have unique, useful content to add (Search Engine Land), and to keep a crawlable hub that links to any deeper city pages (Local Visibility System).

What’s the practical difference between a service‑area hub and a city page?

• Service‑area hub: a browsable index of where you travel. It lists target towns, brief blurbs on coverage, job photos, and clear contact options. It links out to deeper city pages where they exist (Search Engine Land; Local Visibility System).
• City page: a deep page about doing your service in one city. It should include unique local proof — project photos from that city, reviews from residents in that city, local constraints (permits, coastal/snow considerations), and complete contact/booking options (Search Engine Land).

Think of hubs as “where we go” and city pages as “how we do this service in [City].”

A clear decision rule for service area pages local SEO

Ship a single hub now. Only create a city page when you can include all of the following on the page:

• Real‑job photos from that city (faces optional, addresses not) (Search Engine Land).
• At least one review that names that city or a nearby neighborhood (Search Engine Land).
• City‑specific details: examples include permit timing, ocean‑salt impacts on HVAC coils, snow‑load roofing notes, or parking constraints — whatever’s true for your trade there (Search Engine Land).
• A map showing the area you cover in or around that city (image or interactive), plus a clear call widget (call, text, form).

Publishing thin or templated city pages that all feed the same final funnel is a doorway risk (Google spam policies; John Mueller).

How many city pages should I publish before it looks like spam?

There’s no numeric limit. Google targets scaled content abuse and doorway pages — “creating many pages primarily to manipulate rankings” or “substantially similar pages… targeted at specific regions or cities” (Google spam policies). Focus on unique value at the page level.

10‑point “is this a doorway risk?” checklist

Run every proposed city page through this:

1. Would a user end up in the same generic funnel as every other city page (same pitch, same assets, no local proof)? That’s doorway‑like (John Mueller).
2. Is the content substantially similar across cities with only the city name swapped? Risky per doorway guidance (Google spam policies).
3. Is this page integral to the user experience, or is it just to funnel to another page? That’s one of Google’s diagnostic questions (Google Search Central, 2015 doorway post).
4. Does the page duplicate an aggregation the site already has (like listings of locations) just to capture traffic? Another doorway diagnostic (2015 doorway post).
5. Is the page an “island” that’s hard to navigate to? Doorway guidance flags this pattern (2015 doorway post).
6. Is there a block of keyword‑stuffed city names? That’s an explicit spam example (spam policies).
7. Are there city‑specific reviews, photos, or facts visible on the page? If not, thinness risk increases (Search Engine Land).
8. Does structured data faithfully reflect what’s on the page? Mismatches violate quality guidelines (SD policies).
9. Is the page navigationally tied into a clear hub > city breadcrumb trail? If not, fix that (Breadcrumb documentation).
10. Is the content about “where/how” for that city, not just repeating your “what” service page? City pages should complement service pages, not mirror them (Search Engine Land architecture).

URL structure that won’t trip filters

Keep URLs simple and readable. For a service‑area business, a safe pattern is:

• Hub: /service-areas/
• City: /service-areas/city-state/ (use hyphens and the two‑letter state code)

This mirrors Google’s guidance for descriptive, logical paths and breadcrumbs (URL structure; SEO starter guide). If you truly need a state tier, use /service-areas/state/ then /service-areas/state/city/ (Search Engine Land architecture).

Implement visible breadcrumbs (Service Areas > City) and add BreadcrumbList structured data to match the on‑page trail (Breadcrumb documentation).

Internal linking that keeps pages discoverable (and safe)

Use a hub‑and‑spoke pattern:

• The hub links to each city page with descriptive anchors like “HVAC repair in Stamford.”
• Each city page links back to the hub and to relevant service pages (e.g., “Furnace Repair”).
• Service pages link back to the hub and, where it’s useful, to top city pages.

Make these real HTML links so Google can crawl them; anchor text helps users and Google understand the destination (Google link best practices). Avoid orphan pages. Doorway guidance also warns about “island” pages (2015 doorway post).

Do service‑area pages need LocalBusiness or Service schema?

• Use LocalBusiness on your primary business page that shows your actual address. Required properties for eligibility in local rich results include name and address; recommended include telephone, url, geo, openingHoursSpecification, and priceRange (LocalBusiness docs). If you can’t show an address on a given page, don’t mark that page as a LocalBusiness with a full address.
• On a city page (no physical office there), describe offerings with schema.org/Service and set areaServed to the city. Google doesn’t list a Service rich result in its Search Gallery, so use it for clarity, not for special SERP treatment (Search Gallery; Service type).
• Ensure your structured data reflects visible content — that’s a quality requirement (SD policies).
• Add BreadcrumbList structured data that mirrors your on‑page breadcrumbs (Breadcrumb documentation).
• Skip FAQ schema as a tactic to “pad” thin city pages; Google restricted FAQ rich results starting Aug 2023 (FAQ/How‑to changes).

How website area pages relate to your Google Business Profile service areas

• You can set up to 20 service areas (cities or postal codes). There’s no radius option anymore. Your overall coverage should stay within about 2 hours of driving from your base. SABs get one profile for the whole area (GBP help).
• Setting service areas does not boost rankings. For SABs, rankings are mostly based on the address used to verify the listing; service areas mainly affect what users see on the map (Sterling Sky test).

Align them this way: list all towns on your hub (crawlable), build strong city pages where you have proof, and set GBP service areas for user clarity within your real footprint.

Safe publishing order if you serve 15 towns but only have proof for 4

Here’s a printable build order you can follow this week:

1. Draft /service-areas/ with a sentence on your coverage, a short list of the 15 towns, and 1–3 small job photos. Use real HTML links for the towns (even if some are “coming soon”) (Local Visibility System; links crawlable).
2. Add a paragraph under each town name explaining what’s typical there (older housing stock, waterfront corrosion, hilly terrain — whatever’s true for your trade) (Search Engine Land).
3. Implement visible breadcrumbs and BreadcrumbList on the hub (Breadcrumb docs).
4. Pick the 4 cities where you have proof. Create /service-areas/city-state/ pages with unique titles and H1s.
5. Add city‑specific proof: photos from jobs in that city, at least one review naming the city, and any local constraints or tips (Search Engine Land).
6. Embed a map image or widget highlighting your coverage in/around that city.
7. Link each city page back to the hub and to your top 1–3 service pages (links crawlable).
8. Add Service schema with areaServed on each city page; keep LocalBusiness on your primary address page only (LocalBusiness docs; Service type; Search Gallery).
9. Publish and request indexing in Search Console.
10. As you complete jobs in the remaining 11 towns, collect proof and publish those city pages one at a time. Don’t ship placeholder pages — that’s doorway risk (spam policies).

What content must a city page include to avoid doorway‑page risk?

A minimum viable city page for, say, “Roof repair in Norwalk, CT” should include:

• A unique H1 and intro that names the city and the service in ordinary language.
• 2–6 real project photos from Norwalk with short captions (“Asphalt shingle repair off West Ave.”) (Search Engine Land).
• One or more reviews from Norwalk customers (quote and first name/last initial), or a review carousel filtered to that city if you have it (Search Engine Land).
• Local specifics that affect the work: coastal wind exposure notes, common roof pitches in your area, permit office timelines, HOA constraints — whatever genuinely changes scope or pricing (Search Engine Land).
• Clear contact actions: tap‑to‑call, short quote form, chat.
• A small coverage map or service radius graphic centered on Norwalk.
• Internal links to related service pages and back to the Areas hub (links crawlable).
• Descriptive, simple URL and breadcrumbs (URL structure; Breadcrumb docs).
• Service schema with areaServed: Norwalk, CT (Service type).
• No keyword‑stuffed lists of nearby towns — that’s a documented spam signal (spam policies).

How to measure if these pages are working (leads, rankings, calls)

Measure in four places:

• Map Pack visibility by location: use a geo‑grid local rank tracker like BrightLocal’s Local Search Grid to see rank across your service area rather than from one spot (BrightLocal Local Search Grid).
• Organic queries and clicks: in Search Console, filter Performance by Page to each city URL and check “service in city” queries, clicks, and CTR (Search Console Performance).
• GBP interactions: monitor calls, website clicks, and direction requests in GBP’s Performance view or via the Business Profile Performance API (GBP Performance API).
• Leads and calls from pages: in GA4, track tel: link clicks as events on each city page. Use UTM‑tagged URLs from your GBP listing so you can separate GBP traffic from organic in acquisition reports (GA4 UTM guidance).

If you want this implemented without templates, Fluxaro builds custom, conversion‑focused websites with local SEO, booking/lead capture, a 24/7 AI receptionist, and a live analytics dashboard. See what we build on our Services page or browse live Examples.

URL, internal linking, and schema — a quick reference you can hand to your web person

• URLs: /service-areas/ and /service-areas/city-state/ (URL structure).
• Breadcrumbs: show Service Areas > City and add BreadcrumbList (Breadcrumb docs).
• Links: hub → all city pages (descriptive anchors); city ↔ hub; city ↔ relevant service pages; real HTML links (links crawlable).
• Schema: LocalBusiness on your primary address page (name, address required; phone/url/geo/hours/priceRange recommended) and Service + areaServed on city pages (LocalBusiness docs; Service type; Search Gallery; SD policies).
• Content: local proof (photos, reviews, specifics), clear CTAs, and no keyword‑stuffed city lists (Search Engine Land; spam policies).

Want hands‑on help mapping this and wiring up tracking? Book a quick call — we’ll scope exactly what you need and quote it. Book a call.

Do this next

Create /service-areas/ today: list your towns with crawlable links, add 3–5 real proof items, wire breadcrumbs, and publish. Then start city pages only where you have proof.