Why We Named the County Before the Cities in the /ai Meta Description

When we rewrote the meta description for our /ai page, we had six cities to reference: Kokomo, Carmel, Fishers, Westfield, Noblesville, and Indianapolis. We could have listed all six as a flat string. We didn't.

The description reads:

"Fractional AI operations partner for service businesses in Hamilton County (Carmel, Fishers, Westfield, Noblesville), Kokomo, and Indianapolis."

That structure is not a style choice. It's how we target county-level queries and city-specific queries simultaneously.

The gap a flat city list leaves open

A flat list like "Carmel, Fishers, Westfield, Noblesville, Kokomo, Indianapolis" targets city-specific queries well. If an AI assistant reads our page to answer "who does AI automation in Fishers Indiana," the city name is there.

What it misses: county-level queries. "AI operations partner Hamilton County." "Business automation Hamilton County Indiana." People identify with their county more than a specific suburb, especially in the areas north of Indianapolis where the county functions as the common geographic reference. A flat city list doesn't capture those queries unless the county name appears somewhere in the text.

County grouping covers both levels

"Hamilton County (Carmel, Fishers, Westfield, Noblesville)" puts the county name in the description and lists each city. Both show up in natural language matching. Someone searching at the county level finds "Hamilton County." Someone searching for Westfield specifically finds "Westfield." The parenthetical structure makes the geography legible to humans and machine parsers both.

Carmel, Fishers, Westfield, and Noblesville all share Hamilton County. Grouping them reflects that reality. Kokomo (Howard County) and Indianapolis (Marion County) stand alone because they don't.

How the county field propagates to city page descriptions

The cities array in src/content/local.ts has a county field on each object. For the four Hamilton County cities, it's "Hamilton County." For Kokomo, "Howard County."

generateMetadata() on the city pages pulls from it:

const description = `${localBusiness.name} is a fractional AI operations partner for ${found.name} and ${found.county} service businesses...`;

The Carmel page meta description says "fractional AI operations partner for Carmel and Hamilton County service businesses." The Westfield page says "Westfield and Hamilton County." The Kokomo page says "Kokomo and Howard County."

Every city page covers two geographic levels automatically. The county field in local.ts is the single source. Add a seventh city with a county value and its page targets both levels without any additional wiring.

The Service schema takes a different approach

The /ai Service schema areaServed uses cityServiceArea, which is the flat city list mapped to { "@type": "City", name } objects. Six individual cities. No county grouping.

Schema.org doesn't have a county type that maps cleanly to areaServed. Individual City objects are the right call for structured data. The county grouping belongs in the natural language layer, where AI engines match against prose, not in the typed schema layer where explicit object types determine matching.

Two signals, two mechanisms. The meta description and page copy do county-level coverage in plain text. The Service schema does city-level coverage in structured data. Both are needed. Neither replaces the other.