Findings · 2026-09-05 · By VSNARY | Emmanuel Orta
areaServed vs service area pages: 20 towns declared, 1 page
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.
A local business states where it works in two places: the areaServed list in its structured data, and a landing page for each town in its sitemap. The two should match. On four home-service sites we operate, one declared 23 areas and had pages for 21. The other three declared 19 or 20 areas and had pages for 7, 1 and 1. A declared area with no page tells search engines the business is relevant to a search it has no page for. Count the towns in your areaServed, check each one for a landing page, then build the missing pages or trim the list.
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. CrawlCheck reads both and reports the gap between them, and on four sites we operate that gap was large in a way none of us had noticed. The LocalBusiness schema guide for service-area businesses covers how to write areaServed itself.
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.
What did four of our own sites show? #
The four are home-service sites we operate in one metro area, built the same way. 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. The defect is the direction that over-promises — declared, with nothing served. The same discipline applies to a chain of locations: each location should declare its parent brand, not only the parent.
How do you count the gap honestly? #
Two mistakes understate or distort the gap, and our own first count made both. A short blog post whose URL happens to include a city name is not a service-area page; counting it turns prose into coverage. Count only a landing page about the place. And check that each declared town is the town you mean: our first count matched one town to a same-named town in the wrong state, seven hundred miles away. A count 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. Built the same way, three of the four back 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 CrawlCheck at a local service site and it will read both and tell you, per declared area, which ones the site can stand behind.
The main product
Found this on your own site? We fix it for $100.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
Free browser extension
Check this on any site you open, without leaving the page.
CrawlCheck for Chrome grades every site you visit A–F and shows, from your own browser, what search engines and AI assistants are actually served. Free, no account.
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 do I avoid counting a blog post as a service-area page?
Count only a landing page about the place. An article whose URL merely contains a city name is not coverage, and counting it hides the gap.
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.