Location pages

Why location pages still matter

Even with AI engines mediating more searches, location-specific buyer intent ("plumber in Austin," "best dentist near me") routes through a mix of map results, local pack, and AI citations. A well-built location page wins on all three.

When to use them

Use location pages when:

• You serve customers in specific geographies.
• You have any physical presence (office, warehouse, service area).
• Your pricing, availability, or service catalogue varies by city.

Skip them when:

• You're a pure-digital SaaS with no geographic differentiation. (Use service pages instead.)
• You'd be inventing locations — duplicate boilerplate with city names changed is exactly what engines down-rank.

Anatomy of a generated location page

1. H1 — local intent first. "Plumbing services in Austin, TX" beats "Austin Plumbing Services."
2. Local-evidence paragraph. Years serving the city, count of customers, neighbourhoods covered.
3. Service catalogue. Specific services with local pricing or "starts at" anchors.
4. Neighbourhoods served. A list of zip codes, suburbs, or neighbourhoods you cover.
5. Local reviews / proof. Pulled from your reviews source if connected, otherwise hand-curated.
6. Local FAQ. 3–5 city-specific questions ("Do you offer emergency service in Austin?").
7. LocalBusiness schema. Auto-generated and validated.

Starting a location page

Content → New → Location page.

• City + state / region. "Austin, TX." We use the geocoder to validate.
• Services. Pulled from your service list; you toggle which apply locally.
• Local proof. Years in business in that city, customer count if you can share, named neighbourhoods.

The engine refuses to invent local proof. If you don't supply it, the section is omitted — better an honest gap than a fabricated stat.

Avoiding the duplicate-content trap

Two failure modes Google penalises and AI engines down-rank:

1. Templated cities. Same text with city names swapped. Don't.
2. Thin local content. "We serve [city]. Call us." Engines hate it.

The location-page engine:

• Pulls a unique paragraph per city from local sources (chamber of commerce data, public landmarks, common neighbourhoods).
• Reorders the service catalogue per city based on what your dashboard says is in demand locally.
• Inserts a unique local FAQ per city.

The minimum unique-content threshold per page is 350 words after templated sections are removed. The engine targets 700+.

Multi-city campaigns

Bulk-generate up to 50 cities at once on Strategy, 200 on Managed, unlimited on Domination. Upload a CSV with the cities and any per-city overrides; the engine produces drafts that all hit the unique-content threshold.

Updating pricing

City-specific pricing is a workspace setting at Settings → Pricing → Geographic overrides. Updating it there auto-updates every location page on the next regeneration.

Geographic schema

We emit LocalBusiness JSON-LD with the right areaServed and address blocks. The schema is validated against Google's Rich Results Test on every publish — if validation fails, publish is blocked with the field that's wrong.

When local data is sparse

Some service-area businesses cover hundreds of micro-cities where you don't have unique local proof. Two strategies:

1. Cluster. One page per metro, with sub-sections for neighbourhoods. Cleaner and ranks well.
2. Hub + spoke. A regional hub page (e.g. "Central Texas plumbing") that links to a small number of strong city pages, with the long tail covered by the hub.

The engine recommends one or the other in the wizard based on how many cities you list.