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 belongs in
the LocalBusiness block described in
Lesson 4: schema and structured data for local AI SEO,
alongside the other properties in
what LocalBusiness schema is and which fields matter,
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": "Dandenong" },
{ "@type": "City", "name": "Springvale" },
{ "@type": "City", "name": "Noble Park" },
{ "@type": "City", "name": "Keysborough" }
]
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": -37.9884, "longitude": 145.2148 },
"geoRadius": "25000"
}
The radius is in metres. 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.
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 three-town operator
A mobile appliance repair business working across Dandenong, Springvale and Noble Park should have: three named
areas in areaServed, the same three suburbs listed as service areas on the business profile, one strong service
page naming all three in prose alongside callout terms, 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 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.