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

A practitioner’s rule: publish one useful Areas We Serve hub, then add only proof‑backed city pages. Includes URL structure, schema, links, and a doorway risk checklist.

You serve several towns and aren’t sure how many pages to build

You could publish a page for every city you’ll drive to. Or you could keep a single “Areas We Serve” hub. The risk: thin, near-duplicate city pages are classic doorway patterns and can get filtered or acted on by Google’s spam policies (Google Search Central spam policies; Google’s 2015 doorway guidance).

Here’s a decision rule and build order you can apply today.

The decision rule: start with one hub; add city pages only when you have local proof

Practitioner guides land on the same play: ship a single, useful Areas We Serve hub first; add per‑city pages only when each page can carry unique, first‑party proof like job photos, city‑specific reviews, and local constraints (Surfside PPC guide; The STACC). Community threads show templated “service in [city]” pages get filtered or flop (r/localseo discussion).

So:

• Publish a single “Areas We Serve” hub now.
• Only create a city page when you can show real work in that city and answer city‑specific questions buyers ask.

What’s the difference between a hub and a city page?

• Areas We Serve hub: A single page that states your core services, your physical base, your primary service radius, and a scannable list of towns you actually serve. It should include one or two short proof elements for your top markets (mini‑gallery, a few reviews) and links to any live city pages.
• City page: A conversion page for one city with first‑party proof and hyper‑specific details: named neighborhoods you serve, constraints like permits or travel fees, photos from jobs in that city, reviews from customers in that city, and FAQs locals actually ask. Practitioners consistently show these fuller, proof‑backed pages survive quality updates (The STACC; Surfside PPC guide).

How many city pages can you publish before it looks like spam?

There isn’t a safe “number.” Google acts on doorway patterns, not a page count. Their policy flags creating “pages to rank for specific similar queries” and “sites whose primary purpose is to funnel users to other pages” as spam (Google Search Central spam policies). The doorway guidance has been consistent since 2015.

Your guardrail: if a page can’t stand on its own with unique, city‑level proof and useful content, don’t publish it yet.

The “do I have enough to ship a city page?” content checklist

A page is ready when you can provide most of the following without faking it:

• 3–10 photos of your own jobs from that city (before/after if applicable), with one‑sentence captions describing the problem and fix.
• At least one review from a customer in that city, quoted and attributing the person’s first name + last initial.
• A short job log: 2–3 brief bullet case blurbs for recent jobs in the city (service, neighborhood or cross streets, outcome).
• City‑specific FAQs (e.g., roofers: “Do I need a permit in [City] for a re‑roof?”) with clear answers.
• Constraints and pricing context that are actually different in that city (parking, disposal fees, travel windows, soil/lot issues).
• Named neighborhoods or landmarks you service inside the city.
• A static map image or embedded map of your service radius for that city and travel time windows.
• A primary CTA that routes to your quote/booking flow and secondary phone CTA.
• Internal links: back to the Areas hub and to 1–2 related services.
• Machine‑readable schema with accurate areaServed (see schema section below; Schema.org).

Practitioners point to this kind of first‑party, city‑specific proof as the dividing line between pages that rank and those that get filtered (The STACC; Surfside PPC guide; community experiences in r/localseo).

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

Google’s doorway guidance and spam policies focus on intent and duplication, not just templates (doorway guidance; spam policies). Before you publish, answer “no” to each of these:

• Would this page exist if search engines didn’t? If no users would ever need it, that’s risk.
• Does it read like the same page as others with only the city swapped?
• Is the main purpose to funnel to a central “contact us” with no distinct value on the page?
• Could you merge it with another page without losing anything real for users?
• Are you listing every suburb regardless of actual demand or proof of work there?
• Is there zero first‑party proof (photos, job notes, local reviews) unique to this city?
• Are the FAQs and pricing constraints identical across cities?
• Is the map generic or unrelated to the city’s actual radius or travel pattern?
• Do internal links form a thin hub‑and‑spoke intended only for crawlability, not user navigation?
• Does a random visitor land here and feel misled or bounced into another page to get details?

Safe URL structure and internal linking pattern

Keep URLs simple and stable:

• Areas We Serve hub: /service-areas/ or /areas-we-serve/
• City pages: /service-areas/[city]/ or /areas-we-serve/[state]/[city]/ if you truly need state disambiguation

Linking:

• From the hub, link to each live city page with a one‑sentence teaser that mentions the service focus and a proof element (“See jobs we’ve completed near [neighborhood]”).
• From each city page, link back to the hub and to 1–2 top service pages (e.g., /roof-repair/) that matter in that market.
• From relevant service pages, link down to the top city pages that have proof for that service.

Avoid orphan pages. Avoid listing cities in the footer if the links go to thin pages, that pattern often maps to doorway playbooks (spam policies).

Do service‑area pages need LocalBusiness or Service schema?

Use schema to express who you are and what/where you serve. Schema.org supports both LocalBusiness and Service:

• Sitewide: a LocalBusiness entity on your homepage or contact page with name, telephone, address (if you publicly show it), geo/hasMap, openingHours, sameAs, and priceRange where applicable.
• On the Areas We Serve hub: either extend your LocalBusiness with areaServed, or add a Service entity that points to your LocalBusiness as provider and lists areaServed values.
• On each city page: use a Service entity with serviceType set to the relevant offering and areaServed set to the city. Include offers or terms if they differ by city. Keep values truthful and consistent.

Minimal example for a city page (replace placeholders):

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Service", "serviceType": "Emergency plumbing repair", "areaServed": { "@type": "City", "name": "Springfield" }, "provider": { "@type": "LocalBusiness", "name": "Your Company Name", "telephone": "+1-203-555-0100" } } </script>

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Service", "serviceType": "Emergency plumbing repair", "areaServed": { "@type": "City", "name": "Springfield" }, "provider": { "@type": "LocalBusiness", "name": "Your Company Name", "telephone": "+1-203-555-0100" } } </script>

Schema alone won’t make thin pages rank, but it gives machine‑readable clarity on area coverage (Schema.org vocabulary).

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

Treat your GBP service areas as a customer‑facing coverage signal, not a content to‑do list. Setting service areas in GBP doesn’t require you to publish duplicate city pages.

What to do:

• Reflect your real coverage on the site hub and on GBP. It’s fine if you serve an area but don’t have a city page yet.
• Only build a city page when you have the proof listed above. Templated pages that just match your GBP list fit doorway patterns (doorway guidance; community experiences).

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

Use this build order to avoid thin content and keep momentum:

• Publish the Areas We Serve hub with: your base location, primary service radius, list of all 15 towns (as plain text, not 15 empty links), and short proof callouts for the 4 towns you have evidence for.
• Build the 4 proof‑backed city pages first. Each page should meet the content checklist.
• On the hub, link only to those 4 pages. Leave the other town names unlinked or point them to a single contact section until proof is ready.
• Add city pages one by one as you collect proof: photos, reviews, job notes. Update the hub each time with a teaser and link.
• Revisit underperforming city pages quarterly: expand FAQs, add new job blurbs, swap in fresh photos.

How to measure if these pages are working

Measure on three fronts: rankings, visits/engagement, and leads.

• Rankings: Track a small set of queries that map to each page (“[service] [city]”) in a rank tracker. Don’t chase every variation; watch trend lines.
• Visits and engagement: In analytics, create a page group for /service-areas/ and for each /service-areas/[city]/ URL. Track entrances, time on page, and click‑through to contact or booking.
• Leads: Add clear, unique CTAs per page. Use UTM parameters on button links to your quote form so form submissions attribute to the originating page. Use call tracking that assigns a tracking number on the page while keeping your primary number consistent in your site header and on GBP to avoid NAP confusion.
• Phone logs: Tag calls by landing page in your call tracking. Review recordings/notes for city‑specific questions you can answer on‑page next iteration.

A printable build order you can tape to the wall

• Create /service-areas/ hub with full coverage list and proof callouts.
• Gather proof for City A–D (photos, reviews, job notes, FAQs, constraints, map).
• Publish City A page; link it from hub and related service pages.
• Publish City B page; repeat internal links.
• Publish City C page; repeat.
• Publish City D page; repeat.
• Set up analytics: page groups, UTM on CTAs, call tracking with page‑level tags.
• Collect proof for City E next; only publish when checklist is met.
• Quarterly: refresh each city page with new photos, a new review, and an extra FAQ.

Ready to act? Start a shared folder for each target city and drop in job photos, review screenshots, and quick job notes, then draft your /service-areas/ hub today.

Common questions

What’s the practical difference between an Areas We Serve hub and a city page?

The hub is a single page that states your coverage and links to any live city pages. A city page is a conversion page for one city with unique proof (photos of jobs there, local reviews, city‑specific FAQs and constraints) designed to stand on its own.

How many city pages can I publish safely?

There’s no safe number. Google acts on doorway patterns (lots of near‑duplicate pages made for search) per its spam policies and doorway guidance. Only publish a city page when you have unique, city‑level proof and useful content for users.

Do I need LocalBusiness or Service schema on area pages?

Use LocalBusiness for your entity sitewide and Service on the hub and each city page. Set serviceType and areaServed accurately, and reference your LocalBusiness as provider. See Schema.org for properties like areaServed, geo/hasMap, telephone, and openingHours.

Should my GBP service areas match one‑for‑one with website city pages?

No. GBP service areas signal coverage, not a page checklist. It’s fine to list areas you serve on GBP without a matching city page. Only create a page when you have city‑specific proof; templated one‑liners are doorway risk.