What Is areaServed Schema?

The areaServed schema property identifies the geographic area where a service or offered item is provided, using AdministrativeArea, GeoShape, Place or Text values.

It helps define real operational coverage: the cities a plumber visits, the states a law firm serves, the countries eligible for an offer, or the delivery radius around a location. The property should match visible service-area, shipping, eligibility or coverage information.

areaServed is available on ContactPoint, DeliveryChargeSpecification, Demand, FinancialIncentive, Offer, Organization and Service. It supersedes the older serviceArea property. The broad domain means the same region can have different meaning depending on its subject, so model the actual item whose coverage is stated.

1. Frame the decision raised by What Is areaServed Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Describe actual service availability.
• Choose the most accurate value type.
• Keep coverage synchronized with the page.

areaServed should state where the business can genuinely provide the specific service or offer.

Schema.org allows areaServed on ContactPoint, DeliveryChargeSpecification, Demand, FinancialIncentive, Offer, Organization and Service, so the subject should match the coverage fact being described.

A Service value says where that service is delivered. An Organization value describes the organization’s broader coverage. An Offer value can narrow availability for a particular transaction, while a ContactPoint may support a regional customer-service channel.

Do not attach every region to Organization and assume it applies to all services. A company may offer consulting nationwide but onsite installation in three states. Model the narrowest relevant subject to preserve these distinctions.

• Evidence for Which Types Can Use areaServed: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Identify the exact coverage statement.
2. Select the entity it describes.
3. Choose a supported region value.
4. Verify the parent and page agree.

Correct subject selection prevents one broad coverage claim from overwriting service-specific limits.

areaServed describes where a service or offered item is provided, while geographicArea describes the region associated with an intended Audience.

A software company may sell nationwide but publish a guide for California agencies. The Service areaServed can be the United States, while the guide Audience geographicArea can be California. Availability and targeting overlap only when the page proves both facts.

Keep the property subjects distinct. Review the geographicArea schema guide for audience location and the Audience schema guide for the parent relationship.

1. Frame the decision raised by How Is areaServed Different From geographicArea.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Audit service availability and targeting separately.
• Place each region on its correct subject.
• Do not copy values without evidence.

Use areaServed for where delivery happens and geographicArea for where the intended group belongs.

Use AdministrativeArea for formal jurisdictions, Place for named locations, Text for a clear published label, and GeoShape when the business operates within a real geometric boundary or radius.

Country and State are specific AdministrativeArea types and work well for national or state coverage. A City can represent a named municipal place. Text is flexible for phrases that do not map cleanly, but it provides less structure. GeoShape is useful only when coordinates or boundaries reflect actual operations.

Choose the simplest value that preserves truth. A service covering all of Arizona does not need a polygon. A mobile provider serving 20 miles from a depot should not be broadened to the entire state.

• Evidence for Should You Use AdministrativeArea, Place, Text or GeoShape: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Read the exact public boundary.
2. Determine whether it is formal, named or geometric.
3. Choose the least complex accurate type.
4. Test that no ineligible region is implied.

The best areaServed value is the simplest representation of the business’s real service boundary.

Mark up cities, states and countries with matching Place or AdministrativeArea subtypes, using clear names and separate values when several jurisdictions are served.

A local HVAC service can use City for Austin. A statewide legal service can use State for Texas. A SaaS implementation service available across the United States can use Country. Do not replace a city with its state merely to appear broader in local results.

{
  "@type": "Service",
  "name": "Technical SEO Consulting",
  "areaServed": [
    {"@type": "State", "name": "California"},
    {"@type": "State", "name": "Oregon"}
  ]
}

Full names reduce ambiguity in audits. Postal abbreviations may be familiar in US content, but “CA” can have different meanings internationally. Keep a canonical structured value even if visible copy uses abbreviations.

1. Frame the decision raised by How Do You Mark Up Cities, States and Countries.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Match geographic granularity.
• Use separate values for separate jurisdictions.
• Never broaden the published boundary.

City, state and country markup should preserve the exact scale at which the service is truly offered.

Use a GeoCircle when a service has a genuine radius around a known midpoint, supplying GeoCoordinates for the center and a radius whose unit and interpretation match the business’s public coverage policy.

Radius markup suits mobile services, delivery zones and emergency response coverage. It should not be generated around every branch without checking travel boundaries, exclusions, roads, water crossings or franchise territories. Real-world coverage is rarely a perfect circle.

The official areaServed example uses GeoCircle with a geoMidpoint and geoRadius. Ensure the numeric radius is interpreted consistently by the implementation and that visible text helps customers understand service availability.

• Evidence for How Do You Mark Up a Service Radius: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Confirm the business really uses a radius.
2. Validate the midpoint.
3. Apply a consistent radius unit.
4. Test edge locations against service policy.

A GeoCircle is appropriate only when a circular model honestly approximates real service delivery.

A Service can have multiple areaServed values when it genuinely operates in several named regions, but separate service entities or offers are clearer when coverage, terms or pricing differ.

A consultant serving California and Oregon under the same terms can list two State values. If an installation package is available only in California while remote consulting is nationwide, those are different service scopes and should not be merged into one broad region list.

Do not enumerate hundreds of cities when a state accurately represents full statewide coverage. Conversely, do not replace selected cities with a whole state if rural areas are excluded. Choose the representation that matches operational granularity.

1. Frame the decision raised by Can One Service Have Multiple Areas Served.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Combine regions only when service meaning matches.
• Separate coverage when terms differ.
• Use the least repetitive accurate granularity.

Multiple service areas should preserve operational distinctions rather than flatten them into one oversized footprint.

Common areaServed mistakes include using the superseded serviceArea property, claiming locations the business cannot serve, confusing coverage with address or audience, overbroad state markup and copied region lists.

A validator can accept a Country object but cannot confirm whether a local business truly operates nationwide. Evidence must come from current first-party coverage, delivery and eligibility information. City landing pages created for search visibility do not by themselves prove service availability.

Coverage changes are operational facts. Franchise boundaries, licensing, delivery fees and staff capacity can change before structured templates are updated. Connect the markup source to the same system or owner that controls public service-area copy.

• Evidence for What areaServed Mistakes Are Common: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Check property and subject.
2. Compare every region with live coverage.
3. Test exclusions and boundary cases.
4. Trace repeated overclaims to templates.

areaServed must reflect operational truth, not the set of locations a site hopes to rank for.