If you run a business that serves customers across a region rather than at a single storefront, Google needs to know that. The mechanism is structured data, specifically the Service and LocalBusiness types with a defined areaServed. Done right, it helps your site rank in cities you do not have a physical address in. Done wrong, it sends conflicting signals that hurt your visibility in every city, including the one you operate from.
I have audited dozens of local-business sites across Renfrew County and the Ottawa Valley. Almost none of them get this right. Some have no schema at all. Most have schema that contradicts the visible content. A few have schema that names cities the business has never operated in, copied from a template.
What service-area schema is supposed to do
Schema.org markup is a structured way to describe a page's content to search engines. The visible text says "we serve Renfrew County." The schema says it in a format Google can parse without natural-language interpretation. When both agree, Google can confidently include your business in queries like "electrician serving Pembroke." When they disagree, Google has to guess, and Google's guess is often "this business serves only its address city."
For a brick-and-mortar shop, LocalBusiness with an address is enough. For a service-area business like a plumber, contractor, or web designer, you also need areaServed, which lists the cities or regions where you take work.
The three patterns I see most often
Pattern 1: No schema at all. The site has a page about service areas, but the structured data block is missing. Google reads the human-readable content and makes its best guess. Usually that guess is "this business serves its address city only."
Pattern 2: Generic template schema. The schema includes a long areaServed list copied from a template, every city in the province, or every city the agency works in. When Google compares this against the visible page content (which mentions only two or three cities), the signals contradict. Google deprioritizes the markup or ignores it entirely.
Pattern 3: Conflicting locality fields. The schema address.addressLocality says Arnprior. The page H1 says Pembroke. The footer NAP says Renfrew. Each is a different signal to Google about where the business is located. This pattern is especially common on data-driven local landing pages where one template renders ten cities but the schema fields are hardcoded.
What working service-area schema looks like
Here is the actual JSON-LD on a service-area page on this site. The business is a web design studio in Arnprior, Ontario, serving the broader Ottawa Valley.
| Field | Value | Why |
|---|---|---|
@type | ProfessionalService | More specific than LocalBusiness for service-area businesses |
name | Kingsbury Creative | Matches visible NAP exactly |
address.addressLocality | Arnprior | Where the business is registered |
address.addressRegion | ON | Two-letter province code |
address.addressCountry | CA | ISO-3166 country code |
areaServed | Array of named City objects | Each city served gets its own structured entry, not a comma-separated string |
serviceArea.geoMidpoint | lat/lon of regional centre | Helps Google understand the geographic centre of the service area |
The key rule: every value in the schema must be consistent with what is visible on the page and across the site. The address in schema must match the address in the footer. The cities in areaServed must appear in visible content. The business name must match every other mention of the business across the web.
How to check what your site is sending
Google's Rich Results Test will fetch any URL and show you the structured data it finds, along with any validation errors. Run it on your home page, your contact page, and any service-area landing pages. If you see "LocalBusiness detected" with no errors and the cities you expect, you are in good shape. If you see no schema, contradictory fields, or warnings, those are findable and fixable.
Schema.org's own validator goes deeper into the structure without judging it for search-result eligibility. Useful when you want to know if your markup is syntactically valid even when Google's tool says "not eligible for rich results."
The pattern most agencies miss
Schema is not a one-time setup. Every page that describes a service or location needs its own consistent markup. A blog post mentioning a city the business does not serve will not break things, but a service page or a local landing page with mismatched schema absolutely will.
Most templated local landing pages built by agencies fail here. The template renders ten cities, but the address.addressLocality field is hardcoded to the agency's location. Google reads ten pages with ten different H1 cities but one consistent schema locality, and the signal collapses.
I wrote about this specifically in the context of Pembroke web design. The fix is per-city schema fields on every templated page, not a single shared block.
What to do this week
Run your service-area pages through the Rich Results Test. Note what comes back. If there is no schema, no working schema, or schema that contradicts the visible content, that is the work. It is not a redesign. It is a structured-data fix that takes a competent developer an afternoon per page.
The payoff is showing up in searches your visible content already qualifies you for. Get in touch if you want me to audit yours.