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: for each place named in the schema, is there a landing page in the sitemap about that place? Count how many declared areas have one 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 landing page in the sitemap about that town. 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.
Two ways the check could have been wrong #
The first version was 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. It now counts only a landing page about the place. An early version also resolved one town to a same-named town in the wrong state, seven hundred miles away; that is corrected. 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 is a landing page in the sitemap about that town. 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.
The main product
Found this on your own site? We fix it for $749.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
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 the sitemap has a landing page about that place.
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 counts only a landing page about the place. 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
Comments
Comments are read before they appear. Nothing is published automatically, and no account is needed.
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.