Most service-area businesses declare their territory too broadly in structured data. An electrician based in Crown Heights who writes "New York" or a ten-mile radius into the markup has told every engine the business covers the whole city. When someone asks for an emergency electrician in Crown Heights, that markup doesn't help: it says nothing about Crown Heights in particular.
The fix is to use areaServed with the neighborhoods you actually serve, each named as a place. Use a radius only where distance really is the boundary, and even then, name the neighborhoods inside it.
Why a Radius Dilutes the Claim
areaServed accepts a named Place, a plain text value such as a postal code, an AdministrativeArea, or a shape such as a GeoCircle, which is a center point and a radius.
The radius feels tidy. You drop a pin on the shop and declare five miles. But five miles from Crown Heights reaches into lower Manhattan and Queens. As far as the markup is concerned, you now serve places you would never drive to, and you have said nothing specific about the ones you do.
Named neighborhoods are a different kind of statement. "Crown Heights", "Prospect Heights" and "Flatbush" are the words people use in prompts ("electrician in Prospect Heights"), and an engine can match them against the question directly.
Specificity matters because the engine is trying to give a relevant answer, not a complete list. An accurate local claim is worth more than a broad one.
How to Structure areaServed
Use an array of Place objects, one per neighborhood you actually serve:
"areaServed": [
{ "@type": "Place", "name": "Crown Heights, Brooklyn, NY" },
{ "@type": "Place", "name": "Prospect Heights, Brooklyn, NY" },
{ "@type": "Place", "name": "Flatbush, Brooklyn, NY" }
]
Three details matter:
- Place, not City. A neighborhood is not a city, so typing Crown Heights as a City makes a false statement in the markup. Place is the accurate general type. Keep City for actual cities.
- One object per area. Don't put "Crown Heights, Prospect Heights, Flatbush" in a single name. That is one place with an odd name, not three places.
- Say where it is. "Crown Heights, Brooklyn, NY" can't be confused with anywhere else.
Avoiding the Dilution Trap
The most common mistake is listing every neighborhood you have ever worked in: Crown Heights, Prospect Heights, Flatbush, Park Slope, Sunset Park, Williamsburg, Greenpoint, Bed-Stuy. A list that long describes a borough-wide operator, and puts you up against every business in every one of those places.
Be selective. Name the three to five neighborhoods where you do most of your work and have the strongest proof: reviews that mention the area, pages about it, customers there. Let your Google Business Profile service areas carry the rest.
When a Radius Makes Sense
A GeoCircle suits businesses whose boundary really is distance: a delivery radius, or a mobile service with a travel limit. Even then, name the neighborhoods inside it as well:
"areaServed": [
{ "@type": "Place", "name": "Crown Heights, Brooklyn, NY" },
{ "@type": "Place", "name": "Prospect Heights, Brooklyn, NY" },
{
"@type": "GeoCircle",
"geoMidpoint": {
"@type": "GeoCoordinates",
"latitude": 40.6694,
"longitude": -73.9422
},
"geoRadius": "3200"
}
]
Watch the units. A bare number in geoRadius means metres, not kilometres or miles (schema.org/geoRadius), so 3200 is about two miles. You can also write the unit out, as in "3.2 km".
The named neighborhoods are what match a prompt. The radius is the fallback.
Use areaServed, Not serviceArea or serviceRadius
Older guides recommend serviceArea. Schema.org has superseded it with areaServed (schema.org/serviceArea). Use areaServed for all of it. Your address already says where you are; areaServed says where you work.
There is no serviceRadius property either. Some guides add "serviceRadius": "8 miles", but schema.org doesn't define it, so parsers ignore it at best. A radius belongs in a GeoCircle inside areaServed.
Different Areas for Different Services
If one service covers a smaller area than the rest, say so on the offer itself. Offer and Service both accept areaServed:
{
"@context": "https://schema.org",
"@type": "HVACBusiness",
"name": "Example Heating and Cooling",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Example Street",
"addressLocality": "Brooklyn",
"addressRegion": "NY",
"postalCode": "11213"
},
"areaServed": [
{ "@type": "Place", "name": "Crown Heights, Brooklyn, NY" },
{ "@type": "Place", "name": "Prospect Heights, Brooklyn, NY" },
{ "@type": "Place", "name": "Flatbush, Brooklyn, NY" }
],
"makesOffer": {
"@type": "Offer",
"itemOffered": { "@type": "Service", "name": "Emergency heating repair" },
"areaServed": { "@type": "Place", "name": "Crown Heights, Brooklyn, NY" }
}
}
This says: routine work across three neighborhoods, emergency call-outs in Crown Heights only. It is more precise, and more honest.
Zip Codes: Precise, but Not How People Ask
You can list postal codes as text, such as "11213" and "11238". That is valid. But people don't ask for an electrician in 11213; they ask for one in Crown Heights. Postal codes give an engine the geography without the words, so lead with neighborhood names, and put postal codes in your Google Business Profile service areas.
Checking Your Markup
The Rich Results Test has no service-area feature, so it won't report areaServed on its own. Run the page through the Schema Markup Validator instead. It shows the areaServed array as parsed, with each Place listed. If the array is missing, or shows one long string, fix the JSON. The full check is in how to audit your structured data.
Markup with no areaServed at all leaves the engine to infer your territory from your address. For a storefront that is often fine. For a business that travels to its customers, it understates where you work.
What This Means for Your Site
If your markup says you serve "Brooklyn", "New York City" or a ten-mile radius, it is making the broadest claim it can. Rewrite areaServed as three to five named neighborhoods where you work and have proof, typed as Place. Keep a radius only if distance is your real boundary, and give it in metres. Then validate it.