Service area pages: the location URLs squirrel looks for
A local business with no /locations or /service-areas page. squirrel scans the crawled paths and reports which location hubs it found.
What a service area page is
A service area page is a page about one place a business serves, usually one per city or neighbourhood. Sites that publish them normally put an index at a path such as /locations or /service-areas and hang the individual pages under it. That index is what this rule looks for.
They apply to a business that travels to customers, such as a plumber, a mover or a clinic with several branches. The same coverage is expressed in markup with areaServed on the business node, which squirrel’s schema/local-business rule accepts in place of a street address.
What squirrel checks
The rule runs once per crawl and emits one check:
service-area: tests the pathname of every crawled URL against five patterns, matched case-insensitively and anchored to the end of the path, with an optional trailing slash:/locationor/locations,/service-areaor/service-areas,/area-servedor/areas-served,/cities, and/neighborhoodor/neighborhoods. Any match passes with the messageN location/service area page(s) foundand lists the matching paths as items. No match reports at info status with the messageNo dedicated location pages foundand the valueConsider adding for multi-location businesses. Severity info.
A crawl with no pages emits the same check as skipped, with the message No pages available for analysis. The whole rule is skipped, with the reason shown in the report, when the site profile says the site is not a local business.
How to fix it
<a href="/locations">Locations</a>Publish a hub at one of the paths above and link it from the main navigation so the crawl reaches it.
The patterns are anchored to the end of the pathname, so only the hub matches. A site with /locations/san-francisco and /locations/oakland but no /locations index reports No dedicated location pages found, because neither child path ends in locations. Adding the index page fixes the finding and is worth doing anyway. A hub under a different name, such as /where-we-work, is also not matched.
| Rule ID | local/service-area |
| Category | Local SEO |
| Scope | Site-wide |
| Severity | info |
| Weight | 3/10 |
Enable / disable
Disable this rule
[rules]
disable = ["local/service-area"]Disable all Local SEO rules
[rules]
disable = ["local/*"]Enable only this rule
[rules]
enable = ["local/service-area"]enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.
Related rules
- schema/local-business: the LocalBusiness JSON-LD each location page should carry, including
areaServed. - local/geo-meta: the geo meta tags that belong on a location page.
- local/nap-consistency: whether those location pages agree on one phone number and address.
- content/thin-vs-site-norm: pages far shorter than the site’s own norm for their page type, which is what templated city pages look like.
Local SEO findings ship in every audit next to the core SEO, performance and agent experience rules. See Fix SEO issues with AI for how an agent works through a report.
References
Check your site
Run squirrel audit https://example.com and open the Local SEO section of the report. Every matching location path is listed. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.