The multi-town problem
You work across four suburbs. Your competitors have location pages for twenty. The temptation is to match them, and it is the wrong instinct.
areaServed lets you state your coverage in structured data without inventing pages you cannot fill; it
is a standard Schema.org property, and Google lists it among the recommended LocalBusiness properties
(Google Search Central, checked 21 September 2026). It belongs in
the LocalBusiness block described in
Lesson 4: schema and structured data for local AI SEO,
alongside the other LocalBusiness properties that lesson lists, and it is the schema counterpart to the service-area settings covered in
Lesson 2.
Two shapes
Named places. The clearest option for most businesses:
"areaServed": [
{ "@type": "City", "name": "Boise" },
{ "@type": "City", "name": "Meridian" },
{ "@type": "City", "name": "Nampa" },
{ "@type": "City", "name": "Eagle" }
]
Use City, AdministrativeArea or State depending on the unit. Name places the way customers name them, not the
way a postal authority does.
A geo radius. Suited to genuinely distance-based coverage:
"areaServed": {
"@type": "GeoCircle",
"geoMidpoint": { "@type": "GeoCoordinates", "latitude": 43.6166, "longitude": -116.2079 },
"geoRadius": "25000"
}
The radius is in metres (Schema.org GeoCircle, checked 21 September 2026). This is honest for a mobile trade that charges by travel distance, and vague for a business whose coverage follows suburbs rather than circles.
Named places are the better default because they are specific, they read the same way as your page text, and they are easier to keep consistent.
How many to list
As many as you genuinely work in, and no more. Google lets a profile carry up to 20 service areas (Google Business Profile Help, checked 21 September 2026); treat that as a ceiling, not a target.
The temptation is to list thirty suburbs on the theory that more coverage means more chances. In practice it works against you in three ways. It contradicts your website if the page names five. It contradicts your profile service areas if those list eight. And it makes every individual area claim less credible, because a business that claims everywhere is providing no information.
A useful test: would you accept a job in that suburb next week at your normal rate? If not, it does not belong.
Keeping it consistent
Three places state your coverage, and all three must agree:
- Your business profile service areas.
- Your website page text, where the areas should appear in prose so a passage can be quoted.
- Your
areaServedmarkup.
Same list, same names, same order if you can manage it. This is the same consistency discipline as the NAP consistency guide, applied to geography.
If you hide your address entirely, the service-area business guide covers the profile-side configuration that pairs with this markup.
What not to do
Town-name stuffing. Listing every locality within an hour is transparent and self-defeating.
Fake branch pages. A page claiming an office in a town where you have no presence is a guidelines problem and a trust problem.
Coverage that contradicts your travel policy. If you charge a surcharge beyond a certain point, either exclude those areas or state the surcharge plainly on the page.
A worked example for a four-town operator
Halvorsen Plumbing, working across Boise, Meridian, Nampa and Eagle, should have: four named areas in
areaServed, the same four places listed as service areas on the business profile, one strong service page naming
all four in prose alongside callout terms (and the $40 travel fee for Kuna and Star), and no separate location pages unless there is genuinely
distinct content for each.
That configuration is consistent, honest and quotable, which is the whole objective.
Keeping schema, profile and page text aligned
Three statements of coverage exist, and an engine reads all three. They have to agree.
| Where | What it should say |
|---|---|
| Business profile service areas | The suburbs or towns you genuinely work in |
| Page text | The same list, in prose, so a passage can be quoted |
areaServed markup | The same list again, as named places |
The most common breakage is a site that lists five suburbs, a profile that lists eight, and markup that lists twenty because someone pasted in a regional list. That combination does not extend your reach, it undermines every individual claim.
If your coverage genuinely changes, update all three in one sitting. Treat it as a single task rather than three, in the same way the NAP consistency guide treats a phone number change.
When location pages are justified
Occasionally they are. The test is whether you can write something genuinely distinct for each town: different access conditions, different building stock, different regulations, a named local example, a different response window.
If you can, a location page earns its place and should carry that distinct content plus the same canonical business facts. If you cannot, one strong page naming all your areas will serve you better than eight near-duplicates that compete with each other and dilute the topic.
For a service-area business with no premises, the service-area business guide covers the profile-side configuration that pairs with this markup, including what to publish instead of a street address.
How many places before it stops helping
There is no published threshold, but the practical pattern is consistent across the publisher's own local builds.
Up to roughly ten named places, each one adds specificity that an engine can match against a customer's location. Past that, the list starts to read as a claim about a region rather than a set of places you work in, and the individual claims weaken.
Three questions keep the list honest:
- Did you work in that place in the last twelve months?
- Would you accept a job there next week at your standard rate?
- Does your website mention it in prose?
Three yes answers means it belongs. Anything less and it is padding, which costs you credibility on the places that do belong.
If you genuinely cover a wide region, a geo radius is the more honest shape, paired with page text that explains your travel terms rather than listing forty suburbs.
Sources
- Schema.org, areaServed property: https://schema.org/areaServed and GeoCircle type: https://schema.org/GeoCircle (both checked 21 September 2026)
- Google Search Central, "Local business (LocalBusiness) structured data": https://developers.google.com/search/docs/appearance/structured-data/local-business (checked 21 September 2026)
- Google Business Profile Help, "Manage your service areas for service-area and hybrid businesses": https://support.google.com/business/answer/9157481 (checked 21 September 2026)
- Google Search Central, "General structured data guidelines": https://developers.google.com/search/docs/appearance/structured-data/sd-policies (checked 21 September 2026)