Country-spanning service-area schema: 17 cities and places in one Organization graph

A merchant services brokerage in the Ozarks region serves a four-state corridor: Missouri, Arkansas, Oklahoma, and Kansas. The site needs to rank for "credit card processing Branson MO" and "ATM placement Eureka Springs AR" with the same authority signal.

Schema.org gives you areaServed for exactly this. Most implementations stop at one city. Here is how Steele Solutions declares 17 distinct areas in a single Organization graph node, blending City, State, and Place types with containedInPlace chaining.

The flat-string mistake

The temptation is to write:

"areaServed": "Branson, Missouri and surrounding areas"

This is technically valid Schema.org. Google reads the string and infers a service area. But the inference is shallow. Google does not know which cities are in the area. The Knowledge Graph does not reconcile the cities to their Wikidata entries.

The dense pattern uses an array of typed objects:

"areaServed": [
  {"@type": "City", "name": "Branson", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Springfield", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  ...
]

Each city is an explicit entity. The containedInPlace chain tells Google that Branson is in Missouri. The State entity gets its own Knowledge Graph reconciliation.

City vs Place

Some service areas are not political units. Lake Taneycomo is a body of water. Branson Landing is a commercial district. These cannot be City. Use Place:

[
  {"@type": "City", "name": "Branson", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "Place", "name": "Lake Taneycomo"},
  {"@type": "Place", "name": "Table Rock Lake"},
  {"@type": "Place", "name": "Branson Landing"},
  {"@type": "Place", "name": "the Ozarks"}
]

Mixing City and Place is fine. Both inherit from Place in the Schema.org type hierarchy. Google handles the mixed array correctly.

The full Steele Solutions areaServed

The complete areaServed for Steele Solutions, spanning Missouri and Arkansas with associated lake and regional entities:

"areaServed": [
  {"@type": "City", "name": "Branson", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Hollister", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Forsyth", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Kimberling City", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Cassville", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Springfield", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Joplin", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Reeds Spring", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Lake of the Ozarks", "containedInPlace": {"@type": "State", "name": "Missouri"}},
  {"@type": "City", "name": "Bentonville", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "City", "name": "Rogers", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "City", "name": "Eureka Springs", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "City", "name": "Berryville", "containedInPlace": {"@type": "State", "name": "Arkansas"}},
  {"@type": "Place", "name": "Lake Taneycomo"},
  {"@type": "Place", "name": "Table Rock Lake"},
  {"@type": "Place", "name": "Branson Landing"},
  {"@type": "Place", "name": "the Ozarks"}
]

13 cities, 4 places, 17 total areas in one declaration.

Why containedInPlace matters

Without containedInPlace, the City entity is ambiguous. Branson exists in Missouri but also in Colorado. Springfield exists in 35+ US states. The chained containedInPlace resolves the ambiguity for Google's Knowledge Graph.

The chain can go deeper. For a sub-state region:

{
  "@type": "City",
  "name": "Branson",
  "containedInPlace": {
    "@type": "AdministrativeArea",
    "name": "Taney County",
    "containedInPlace": {"@type": "State", "name": "Missouri"}
  }
}

This tells Google: Branson is in Taney County, which is in Missouri. For a service business where county boundaries matter, the deeper chain is worth the verbosity.

Per-area landing pages

The areaServed declaration is the entity-graph statement. The site also needs landing pages for each area. Steele Solutions has:

/branson-mo/
/locations/springfield-mo/
/locations/joplin-mo/
/locations/hollister-mo/
/locations/forsyth-mo/
/locations/kimberling-city-mo/
/locations/reeds-spring-mo/
/locations/lake-of-the-ozarks/
/locations/bentonville-ar/
/locations/rogers-ar/
/locations/eureka-springs-ar/
/locations/berryville-ar/
/ozarks-region/ (regional hub)
/locations/ (location index)

Each page has its own page-level schema with the City as the WebPage about. Cross-link from the homepage areaServed to each landing page where possible.

What ranking changes to expect

For a brand-new domain, dense areaServed declaration produces:

Faster discovery of per-area landing pages
More query-specific impressions in GSC (e.g., separate impressions for "credit card processing Bentonville AR" vs "credit card processing Branson MO")
Cleaner Knowledge Panel reconciliation
AI Overview citations for region-specific queries

For Steele Solutions on day 7 of launch, GSC was already showing impressions for at least 3 different region+service combinations.

The live example

The complete entity graph including the 17-area areaServed declaration is at https://steelesolutions4u.com/entity.json. The same schema is embedded inline on every page of the site.

Live site: https://steelesolutions4u.com/. Service-area pages start at https://steelesolutions4u.com/locations/.