The list that should be making you money
Look at the footer of any service-business site. There's the list. "We serve Saint Paul, Minneapolis, Edina, Bloomington, Roseville, Maplewood, Eagan, Burnsville..." Twenty, thirty, fifty places.
That list, in a footer, is invisible to Google in the way that matters. It's text on a page. Google indexes the page. The page is /service-areas or /contact or /about. The pages for Saint Paul and Bloomington — the pages people actually search for — don't exist.
Meanwhile the competition with 60 hand-written city pages is showing up first when somebody Googles "garage door repair Saint Paul."
Service businesses live or die by local SEO. And right now you either hand-write a page per service-area combination, or skip this powerful SEO hack entirely. BIAB ends both.
Service × ServiceArea = a dedicated, automated page for each
The pattern is dead simple. You declare one URL template:
``ts defineParallelPage({ routePattern: "/repair/[service]/[area]", variables: { service: { source: { section: "services" }, slugField: "type", tokenFields: ["type", "description"] }, area: { source: { section: "serviceAreas", path: "areas" }, slugField: "slug", tokenFields: ["name", "state"] }, }, meta: { title: "{service.type} in {area.name}, {area.state} | {company.shortName}", description: "Professional {service.type} in {area.name}. Call {company.phone}.", }, templateRef: "repairPage", }) ``
BIAB materialises one page per (service × area) combination. Five services × thirty areas = 150 pages. Each one has substituted meta tags, substituted body copy, its own URL, its own canonical, and its own row in your sitemap.
This is what "programmatic" actually means in SEO — not "auto-generated articles" (Google penalises those). It's "the same depth of content a hand-built campaign would produce, generated from a template you maintain." Google rewards it because it is hand-curated; the curation is in the template and the source data, not the typing.
What this does
Local SEO has been one of the core implementations of SEO services for decades. Agencies have been hand-writing location pages, building city-specific microsites, and shipping invoices for the labour, since long before "programmatic" was a word in the SEO vocabulary. The work has always been there; the automation is what's new.
When a user types "Garage Door Repair in Brooklyn" into Google — and it's a service you offer, in a service area you set — your site has a page that is literally about garage door repair in Brooklyn. URL, title, H1, meta description, structured data, all of it specific. Google's algorithm has one job: return the most relevant page for the query. Your page wins because it is the most relevant page.
When a user types "powerwashers near me" — and powerwashers are a product you sell, in inventory, with location data on your store profile — your page exists, optimised, indexed, with the product and the location both in the URL.
When a user types "catering services" — and you're a venue that offers monthly catering rates with add-ons — your page exists for that exact combination, naming the service, naming the offering, naming the city.
This feature flips the algorithm much more in your favor than nearly any other move you can make as a service business. Not because you tricked Google. Because your site was literally built to capture what was most similar to what the user searched for, and Google rewards that the way it always has.
The reason this hasn't been automated until now isn't that nobody wanted it. It's that the integration was hard. The data has to live somewhere structured (your CRM, your product catalog, your service-area list). The template has to render from that data. The URL has to reflect the variables. The sitemap has to know what materialised. The cache has to invalidate when source data changes. The robots.txt has to behave correctly when the platform has a billing problem.
BIAB owns all of those pieces because it owns the data, the SDK, the URL routing, and the SEO infrastructure. So we shipped them as one feature.
What changes when you edit the source list
Add a new service area in the BIAB dashboard. Five new pages exist immediately — one per service. The sitemap reflects them on the next request. The webhook fires biab:section:serviceAreas and your consumer-side cache invalidates every variant in one shot. Search engines discover the new URLs the next time they fetch your sitemap.
Remove an area. The five pages stop materialising. The sitemap drops them. Your robots.txt continues serving Google a clean signal.
You manage one list. The fan-out is automatic. Your team never edits 150 pages by hand.
The SEO powerhouse is the infrastructure underneath
The reason most teams skip programmatic local SEO isn't the templating. It's the infrastructure: sitemap pagination above 50K entries, per-page canonical URLs, per-page meta tags, structured data per page, robots.txt with the right Sitemap: line, per-page noindex overrides, automatic invalidation when source data changes, and — the one most platforms get wrong — careful behaviour during platform outages so search engines treat downtime as temporary instead of permanent removal.
All of that ships with the feature:
/sitemap.xmlauto-generated, paginated, correct<lastmod>per URL./robots.txtwith the rightSitemap:line, per-pagenoindexoverrides where you set them.- Webhook-driven cache invalidation on the consumer SDK so a source-list edit reaches the rendered page within seconds, not days.
- HTTP 503 +
Disallow: /during platform-level outages — Google reads this as "come back later" and your URLs stay in the index instead of falling out. - Per-page
<link rel="canonical">so the cartesian fan-out doesn't create duplicate-content signals.
That's the work most teams quote out to a consultant and never finish. The Programmatic Local SEO feature is that work, packaged.
Cartesian: services × areas × anything
One variable in the URL gives you one landing page per entry. Two variables give you the cross-product. Add a third (services × areas × types of customers) and the fan-out grows multiplicatively.
Most service businesses live in the 30-150 page range. Operations with a real matrix — locksmiths with 4 services × 30 cities × 2 dispatch windows — land in the 240 range. Sitemap pagination handles the math; you keep editing your one template.
What this is, and what it isn't
This isn't "AI writes 150 articles." Google penalises that, and it deserves to. The body copy on each materialised page comes from your template — your hand-written narrative — with names and locations substituted in. The page mentions Saint Paul because it's for Saint Paul. The meta description names the service because the URL is for that service. Every page is unique because every combination is unique, and the substitution is mechanical, not generative.
This is also not "we'll get you to #1 in three months." Local SEO compounds; the third month after you publish 150 indexable city pages is when most teams start seeing the ranking move. The work pays off in the second quarter, not the second week.
What it ends
It ends the meeting where someone says "we really should do service-area pages" and someone else nods and the meeting moves on, every quarter for years. It ends the slow-bleed loss of local search position to the competitor who finally got around to writing the 60 pages. It ends the choice between "stop everything else and spend a month writing location pages" and "skip this entirely."
Service businesses live or die by local SEO. The platform either ships this or it doesn't. BIAB does.