PublishedVerifiedEvery 6 weeksSources5 namedAuthored bySquareRank Team
Local SEO · City Pages · § 2.6.4
Squarespace City Pages — Without the Doorway Trap
The 2018 city-page playbook was 'spin up a page for every nearby city, swap the city name, repeat'. That playbook now fails Google's doorway-page policy2 and the helpful-content classifier1 in the same week. The 2026 version: only build city pages for cities you genuinely serve, write at least 700 words of city-specific content per page, declare service coverage via areaServed schema3, and cross-link into the rest of your site so the page graph is coherent.
This page covers the legitimate-versus-doorway distinction, the content bar, the URL pattern, the schema, and the rule for single-location practices. Pair this with the multiple locations leaf for the contrast between service-area pages and physical-location pages.
§01The distinction
Legitimate city page vs doorway page — the line
A legitimate city page exists because the business genuinely serves customers in that city — through travel, through a team member based there, or through a distribution arrangement Google can verify. A doorway page exists to capture the 'service + city' query without any underlying claim, usually built by duplicating an existing service page and swapping the city name. Google's spam policies explicitly cover doorway pages as a manual-action category, and the helpful-content classifier independently catches them as low-effort content. The line is verifiable: can the business demonstrate a real connection to the city, or not?
Three patterns are clearly legitimate. A wedding photographer with documented past weddings in Asheville and Charlotte builds a service-area page for each city, with photos from real weddings in each. A telehealth therapist with PSYPACT authorization across 41 states builds one state page per covered state, with state-specific licensing context and crisis resources. A plumber who genuinely travels through five surrounding towns builds one service-area page per town, with the towns named on the homepage's areaServed declaration.
Three patterns are clearly doorway. A wedding photographer in Asheville who has never travelled past the city limits builds eight 'wedding photographer in [neighbouring town]' pages. A solo therapist in Austin who has only ever practised in-person builds 'therapy in [adjacent city]' pages. A retail store with one physical location builds pages targeting every ZIP code in the metro area. All three trigger Google's helpful-content filter within months of publishing and produce ranking suppression that often hurts other pages on the site too, because the classifier downweights the whole domain when it finds the pattern.
The 2026 city-page bar
700
minimum words of city-specific content per service-area page to read as substantive, not boilerplate.
Below 700 words of city-specific content, a city page reads as boilerplate plus a few token swaps. Above 700 words with substantive local context — named neighbourhoods, named landmarks, real photographs taken in the city, real testimonials from city customers, the named team member who works there, city-specific FAQs (parking, public transit, the venues you have worked at, the local insurance plans you accept) — the page reads as a legitimate resource. The bar is not exact but is consistent across audits: 400-500 words is too thin even with effort; 700-1,000 words with real local content clears the filter.
The 'substantive local context' part is where most attempts fail. A page with 1,200 words that all read as generic service description with the city name sprinkled in fails the filter just as fast as a 200-word page. A page with 750 words where 400 of them are about the specific neighbourhoods you have worked in, the specific venues you know, the specific insurance plans clients in that city carry, and the specific FAQs they actually ask, clears the filter and ranks. The volume rule is necessary but not sufficient — the content has to genuinely vary by city.
§03URLs
URL structure for city pages and service-area pages on Squarespace
The 2026 URL pattern for service-area pages on Squarespace is /service-areas/{city-slug}/ or /serving/{city-slug}/, with a parent slug that distinguishes service-area pages from physical-location pages. Physical-location pages live at /locations/{city-slug}/; service-area pages live at /service-areas/{city-slug}/ or /serving/{city-slug}/. The two URL patterns coexist when a business has one physical location and travels to additional cities — the location page carries LocalBusiness JSON-LD with address; the service-area pages carry only the parent business name and areaServed reference back.
The /locations/ vs /service-areas/ distinction is a signal both for Google and for the site editor. Pages under /locations/ have addresses and Map blocks; pages under /service-areas/ have neither. Mixing the two paths produces ambiguity — a /locations/{city}/ page without an address looks like a doorway; a /service-areas/{city}/ page with a fake address looks like a misrepresentation. Pick one path per page type and never mix them.
§04Schema
areaServed schema and the geo block
The areaServed property is the LocalBusiness schema field that declares which cities, regions, or postal codes a business serves. The accepted values are a simple string array ('Asheville, NC', 'Charlotte, NC') for casual service-area declarations, an AdministrativeArea array for state or province coverage, or a GeoShape with coordinates for precision coverage zones. For most Squarespace service-area businesses, the AdministrativeArea pattern with name and addressRegion pairs is the cleanest fit.
Google's local-business documentation reads areaServed as the canonical signal for service coverage3. A LocalBusiness JSON-LD block on the homepage or contact page with a clean areaServed array can substitute for many city-specific pages — the schema declares coverage explicitly and Google ranks the parent business for queries in those areas without needing a per-city page. The decision tree is: if you have unique content per city that earns its own page, build the page; if you do not, ship the areaServed array and let the schema carry the coverage claim.
JSON-LDLocalBusiness with areaServed for a service-area business covering five cities
When single-location practices should not build city pages
Single-location practitioners who do not travel outside their immediate metro should not build city pages for neighbouring towns. The temptation is to spin up 'service in [neighbouring town]' pages on the theory that more pages means more rankings. In practice, those pages read as doorways, fail the helpful-content filter, and suppress rank on legitimate pages on the same domain. The 2026 alternative is to extend the Google Business Profile service area to cover the legitimate commute radius, keep one strong location page, and let the GBP signal carry the coverage claim — no per-town pages required.
The GBP service-area extension is the under-used lever. A single-location coffee shop in Asheville can list Asheville plus four adjacent towns in the GBP service-area field, and Google reads the listing as covering the metro area. No additional Squarespace pages are needed. The same pattern applies to single-office therapists, lawyers, accountants, and other professional services — the GBP service-area field carries the geographic claim and the on-site work focuses on the actual service and the actual location.
The exception is when there is genuine differentiation by neighbouring city — the business has a documented track record, a specific past client base, or a distinct service offering for that city. Then the city page becomes legitimate and the 700-word bar applies. The line is simple: real local context = legitimate; copy-paste with token swap = doorway.
