Findings · 2026-09-05 · By VSNARY | Emmanuel Orta · 0 views
Your schema lists service areas your sitemap has pages for a fraction of them
Four home-service sites we operate declare 19–23 service areas each in structured data. Three of them have real landing pages for one or seven. A coverage claim lives in two files, and the pages are the ones a search engine can land on.
Bar length is the share of declared service areas that have a real landing page in the sitemap. The tree site backs 21 of its 23 claims; the three fencing sites, built by the same person on the same platform, back 7, 1 and 1. The schema on all four reads as broad coverage. Scan any local service site to see its own split.
A local service business tells search engines where it works in two independent places, and they are supposed to agree. The first is structured data: a LocalBusiness or Service node whose areaServed lists the cities and regions the business covers, often as a ring of a given radius around a point. The second is the site itself: a page for each of those places, the kind a person lands on when they search the service plus their town. This scanner reads both and reports the gap between them, and on four sites we operate that gap was large in a way none of the four owners had noticed.
The measurement is simple to state. Read every place named in the schema. Read every page in the sitemap. For each declared area, decide whether a page exists whose last path segment ends in that place’s slug. Count how many declared areas have a page and how many do not. That count is the finding.
Four sites, same operator, same city
The four are home-service contractors in one metro area, built by the same person, on the same platform, with the same schema plugin. They are not a random sample; they are a controlled one, which is why the spread between them is worth reading. The schema on all four is confident about coverage. The sitemaps are not.
The tree service declares 23 service areas and has a real page for 21 of them — a page that exists, is in the sitemap, and ends in the town’s name. That is what good coverage looks like, and it is the exception here. The three fencing sites tell the opposite story. One declares 19 areas and has pages for 7. The next declares 19 and has a page for exactly 1. The third declares 20 and, again, has a page for 1. In each of those three cases the schema promises a search engine that the business serves nineteen or twenty towns, and the site offers a landing page for one of them.
Why the gap is a defect and not a technicality
Declaring an area in schema without a page behind it does two unhelpful things at once. It tells a search engine the business is relevant to a query it has nothing to show for — a person searching “fence repair in town” is offered a homepage that never mentions the town, which is a worse result than an honest absence. And it inflates the site’s own account of itself: nineteen declared areas reads as broad reach, until you notice eighteen of them resolve to the same generic page. The schema is not wrong in the sense a validator would catch — an areaServed list of nineteen cities is perfectly valid JSON-LD. It is wrong in the sense that the site cannot back the claim with anything a reader or a crawler can land on.
The reverse case is fine and common: a page for a town the schema does not list is just an undeclared area, and the scanner notes it without alarm. The defect is the direction that over-promises — declared, with nothing served.
How the check avoids two ways of being wrong about it
The first version of this check matched a declared place against any path that contained its name. That is too loose: a 14-word blog post whose URL happens to include a city name is not a service-area page, and counting it would have understated the gap by turning prose into coverage. The rule was tightened to the last path segment ending in the place slug, optionally with a state suffix, on a path short enough to be a landing page rather than an article. A page has to actually be about the place to count for it.
The second way to be wrong is about the place itself. Declared areas are geocoded so the map can draw them, and an early version resolved one town to a same-named town in the wrong state seven hundred miles away, because it took the first geocoder hit rather than the nearest one to the business. The fix was to bias every lookup to the declared centre and take the nearest candidate. A service-area check that silently relocates a town is measuring a different business.
Four sites we operate, declared against backed
| Site | Service areas declared in schema | Areas with a real page |
|---|---|---|
| Tree service | 23 | 21 |
| Fencing A | 19 | 7 |
| Fencing B | 19 | 1 |
| Fencing C | 20 | 1 |
Measured 2026-09-05. A page counts only where it exists, is in the sitemap, and ends in the town’s name. Same person, same platform, three of the four backing almost none of what they claim.
What to do about it
The gap closes in one of two directions, and the honest one depends on the business. If the contractor genuinely works in all nineteen towns, the missing eighteen pages are the work — each one a real page about that town, its service, and the fact of coverage, not eighteen copies of the same paragraph with the name swapped, which reproduces the problem in a new form. If the contractor does not really work in all nineteen, the schema is the thing to fix: declare the areas the business can actually serve and can show a page for. Either way the schema and the sitemap end up agreeing, which is the only state in which the coverage claim is true.
The point that generalises past these four sites is that a coverage claim lives in two files and is only as strong as the weaker one. Schema is cheap to write and easy to overstate; pages are expensive and hard to fake. When they disagree, the pages are the truth and the schema is the marketing. Point this scanner at a local service site and it will read both and tell you, per declared area, which ones the site can stand behind.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
Questions this post answers
What exactly is being compared?
The cities and regions a site declares in its schema (the areaServed property of a LocalBusiness or Service node) against the pages in its sitemap. For each declared area the check asks whether a landing page exists whose last path segment ends in that place’s name.
Is declaring an area without a page against Google’s rules?
It is not a schema error a validator flags — the JSON-LD is valid. It is a quality problem: the site tells a search engine it is relevant to a local query it has nothing specific to show for, and offers a generic homepage instead of a page about that town.
What about a page for a town the schema doesn’t list?
That is fine. An undeclared area is noted without alarm. The defect is the other direction — an area declared in schema with no page behind it.
How does the check avoid counting a blog post as a service-area page?
It requires the last path segment to end in the place slug (optionally with a state suffix) on a path short enough to be a landing page. A long article whose URL merely contains a city name does not count.
How do I fix the gap?
In one of two directions. If the business really serves every declared area, build a real page for each missing one — not copies of the same paragraph with the name swapped. If it does not, trim the schema to the areas it can actually serve and show a page for. Either way the two files end up agreeing.
Related findings
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.