How to generate 200 location-service pages from your master record in one afternoon

A 200-location operator typically takes 6-9 months to ship per-location service pages across the full footprint when the work is hand-written. The reasons are not mysterious — every page needs the location context, the brand voice, the right schema, internal links that respect the URL hierarchy, and content distinct enough from sibling locations that Google ranks them separately rather than collapsing them into a single canonical. Multiply that work by 200, and the project is a quarter-long initiative that ships about the time the next round of master-record changes makes 30% of the pages stale.

A per-location page generator agent — wired to your master record, your brand spec, and your local context layer — generates the same 200 pages in roughly 90 minutes of compute time, with schema.org markup baked in, internal-link hierarchy correct on first publish, and a cosine-similarity distinctness check that prevents the cannibalization the manual process never had time to defend against. This guide walks through the deployment.

Step 1 — Define your URL hierarchy

One location URL pattern per system, chosen at architecture time, applied consistently. The page generator cannot publish two URLs for the same location-service combination; ambiguous URL hierarchy is the root cause of most multi-location SEO cannibalization, and it accumulates over years if not pinned at architecture time.

/                                       → national home
/services/{service-slug}                → service hub (national)
/locations                              → location directory
/locations/{state}                      → state directory
/locations/{state}/{city}               → city directory
/{location-slug}                        → location home
/{location-slug}/{service-slug}         → location's specific service

The agent enforces this hierarchy as a hard rule. If your existing site has multiple URLs for the same location (e.g., /denver-cherry-creek AND /locations/co/denver/cherry-creek), the cleanup is a prerequisite step before the generator goes live; otherwise the agent inherits the ambiguity it was supposed to prevent.

Step 2 — Map your master record fields to the page template

Pull your master record schema. Identify which fields the page template needs: location_id, address, hours, phone, services, manager bio, photos, payment methods, accessibility flags. Map each field from the master record source — Salesforce Service Cloud field names, Akeneo PIM attributes, custom warehouse columns, or Google Sheet headers depending on what your operations team uses as canonical.

The mapping output is a per-vendor adapter that converts the master record format to the page template inputs. For Salesforce Service Cloud, this is a SOQL query + a transformation function. For Google Sheets, this is a GViz JSON read + parse. For custom warehouses, this is a SQL view. The architecture works against any source — the constraint is that the master record must be the single source of truth for the fields the page renders.

Step 3 — Compile your brand spec for page-level constraints

Page generation has more brand-spec surface area than review responses or GBP posts because the page is canonical and persistent. The spec needs at minimum: forbidden phrases (the typical marketing-cliche list — see the brand-voice gate spec from the review-response how-to), tone matrix targets for body copy, schema conventions (H1 pattern, internal link density, image alt text patterns), per-section structural templates (how the manager bio block reads, how the hours block reads, how the reviews block embeds), and per-vertical claim-substantiation rules.

The auto-publish threshold for location pages is 0.92 — the highest in the swarm (per the brand-voice gate from the cornerstone piece). Pages are canonical, indexed, persistent — the cost of an off-brand page surviving for weeks before catching it is far higher than the cost of an off-brand review response that scrolls off the GBP within days.

Step 4 — Wire the local context layer ingestion

Each location page needs more than master-record facts to be brand-distinct from a sibling location. The local context layer caches per-location external data — landmarks, demographics, neighborhood specifics, weather seasonality, local events, regional terminology preferences. The agent reads this layer when composing the location-context paragraphs that distinguish the Cherry Creek page from the Capitol Hill sibling.

• Landmarks within 2 miles — Google Places API, refresh weekly
• Demographics — US Census API + per-state datasets, refresh quarterly
• Local events calendar — Eventbrite + regional event aggregators, refresh daily
• Weather seasonality — NOAA or commercial weather API, refresh monthly
• Public transit + parking context — Google Maps + per-city open-data sources where available, refresh annually
• Regional terminology — bring-your-own dictionary per region (handles "soda vs pop", "shore vs beach", etc.) — manually curated, low-frequency updates

The local context layer is owned by a background ingestion job, not the page generator agent itself. The agent reads from the layer; the layer refreshes on its own cadence. Stale data flagged with last_refreshed_at; the agent emits a telemetry warning when it generates against stale data.

Step 5 — Set the cosine-similarity distinctness threshold

The single architectural primitive that prevents multi-location cannibalization: cosine similarity between every newly-generated page and the same-service page from the geographically-nearest sibling location must stay below 0.85. The check runs after the brand-voice gate but before publish. Pages that fail trigger a regeneration with a stronger local-context-injection prompt; pages that fail twice escalate to human review.

Step 6 — Run initial bulk generation against 1-2 locations as proof

Pick 2 locations: one canonical (a flagship, well-staffed location with rich master-record data) and one weak (a recent opening, thin master record, less-curated photos). Generate against both. The flagship validates the upper bound of agent quality; the weak location validates the lower bound — what does the agent ship when the input is sparse.

Spot-check the outputs: do they read on-brand, does the schema validate, does the cosine-similarity check pass against existing sibling pages, do the internal links resolve correctly. The bulk-generation run typically surfaces 2-4 brand-spec gaps before full deployment. Fix the spec, regenerate the test pair, repeat until both pages would have shipped at editorial-team-approved quality.

Step 7 — Generate the full set + run schema validation

After the test pair passes editorial review, run bulk generation against the full location footprint. At 200 locations × 5 services = 1,000 pages, the run completes in 60-90 minutes of agent compute time. Each page passes through: brand-voice gate → distinctness check → schema validator (Schema.org validator + Google Rich Results Test API) → editorial governance routing → publish queue.

Routing per page: pages scoring 0.92+ on the brand-voice gate auto-publish (with the 5-minute delay window); pages 0.75-0.92 queue for tier-2 single-approver review (batched daily); pages below 0.75 escalate. At a healthy steady state, 92-95% of pages auto-publish on first attempt, 4-7% queue for review, <1% escalate.

Step 8 — Set up master-record-update event triggers for ongoing regeneration

The initial bulk generation is the hard work; ongoing regeneration is the easy part. Wire the master record source to fire `master_record_updated` events when fields change (manager update, hours change, new service added, address correction). The page generator subscribes; affected pages regenerate; the brand-voice gate runs; governance routes; pages publish. Steady-state cadence at 200-location scale: 0.5-2 page edits per location per month, scaling to 100-400 monthly regenerations across the footprint.

Total time-to-full-deployment for the page generator: typically 21-30 days at 50-200 location scale. Longer than review-response (14-21 days) because the brand-spec compilation work is heavier and the cleanup of pre-existing URL ambiguity from step 1 sometimes surfaces a multi-week cleanup project the operator did not budget for.

A copy-pasteable schema.org LocalBusiness template

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/{location-slug}/#location",
  "name": "{brand-name} {location-name}",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "{master-record.street}",
    "addressLocality": "{master-record.city}",
    "addressRegion": "{master-record.state}",
    "postalCode": "{master-record.postal_code}",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "{master-record.lat}",
    "longitude": "{master-record.lng}"
  },
  "telephone": "{master-record.phone}",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "{master-record.weekday_open}",
      "closes": "{master-record.weekday_close}"
    }
  ],
  "areaServed": {
    "@type": "GeoCircle",
    "geoMidpoint": { "@type": "GeoCoordinates", "latitude": "{lat}", "longitude": "{lng}" },
    "geoRadius": "{master-record.service_radius_meters}"
  },
  "makesOffer": [
    {
      "@type": "Offer",
      "itemOffered": {
        "@type": "Service",
        "name": "{service.name}",
        "description": "{service.description}"
      }
    }
  ]
}

Per-vertical operators swap LocalBusiness for the appropriate subtype: Restaurant for chain restaurants, MedicalBusiness or MedicalClinic for healthcare, Store for specialty retail, Gym for fitness. The template is a starting point; adapt the property set to your category.

What this guide does not cover

URL-hierarchy cleanup of pre-existing site sprawl is its own engagement — typically a 2-4 week project that surfaces during step 1 if the operator has years of accumulated URL inconsistency. CMS migration (moving FROM Wordpress TO a headless CMS, for example) is out of scope; the agent generates INTO whatever CMS you currently run. Master-record cleanup is out of scope (the agent works against your record's current state; cleanup is a separate engagement). Multi-language page generation is out of scope (English-only here); multi-language operators need a translation-quality gate layered on top of the brand-voice gate.

The architecture, the URL hierarchy, the master-record mapping, the brand spec, the local context layer, the distinctness threshold, the schema template, the event-triggered regeneration — those are universal. Apply them to your existing master record + CMS and you have the full per-location page surface generated in 90 minutes of agent time and ongoing-fresh forever.