Programmatic SEO is how a business gets a real page for each service in each town it covers, without writing every page by hand. It is the service I am best known for. I have built more than 30,000 location pages for contractors, healthcare practices, multi-location businesses and franchise brands across the United States and Canada, working from Seekonk, Massachusetts.
What programmatic SEO is
People search for a service and a place together: "roof repair" plus a town name. A site with one services page and one list of towns has no page that answers that search. Programmatic SEO fixes that with three parts: a database of your services and towns, a page template for each page type, and rules that join them. The content lives in the database. The template displays it. Change a row and the page changes.
The method is neutral. It can produce hundreds of useful pages or hundreds of worthless ones. The difference is what goes into each row.
When it works, and when it does not
It works when:
You truly serve the towns on the list and will take the job when the phone rings.
You offer several distinct services, and customers search for them by name.
There is something real to say that differs by town or by service.
Your site already has solid core pages for each service.
It does not work when:
The only thing that would change from page to page is the town name.
You want pages for places you do not serve.
You have one service and one town. A few hand-written pages will do the job.
The plan is to generate text in bulk and publish it unread.
Planning the matrix: a worked example
Take a made-up tree care company with 6 services and a list of 20 towns. On paper that is:
6 service pages
20 town pages
6 services across 20 towns: 120 service-in-town pages
Total: 146 pages
That is the starting count, not the plan. I go through it with the owner and with keyword research, and cut:
Places that are not separate places. Two of the 20 "towns" turn out to be villages inside another town on the list. People search by the town name. They are folded into that town's page. 18 towns remain.
A service nobody searches by town. One service is bought by referral, and research shows no town-level searches for it. It keeps its service page and gets no town pages. Five services across 18 towns leaves 90.
A service not offered everywhere. One service needs equipment that only covers 12 of the 18 towns. Six rows go. 84 remain.
Outer towns. Two towns at the edge of the area are worth the drive only for the two largest kinds of job. Each keeps two service pages instead of four. Four more rows go. 80 remain.
The plan is now 6 service pages, 18 town pages and 80 service-in-town pages: 104 pages, each of which the company can stand behind. The 42 pages that were cut are the ones that would have been thin, untrue or duplicates.
The questions I ask of every cell in the matrix:
Do you do this job in this town today?
Does anyone search for it by town?
Is there something to say here that the service page and the town page do not already say?
Is this a real place name that people use, or part of another one?
Would this page compete with another page on your own site for the same search?
How the database is modeled
Three collections do most of the work. Example fields for each:
Services: name, URL slug, short summary, what is included, what is not, how the job runs, signs you need it, service-level questions and answers, photos, related services, SEO title, meta description.
Towns: name, URL slug, state or province, county, 2020 Census population, villages and neighborhoods, nearby towns you also serve (a reference back to this same collection), local notes for your trade, source URLs for every fact, SEO title, meta description.
Combinations: one row per service in a town. A reference to one service and one town, its own heading, intro, local section, questions and answers, photo, SEO title, meta description, a status field (draft, reviewed, published) and the date it was last reviewed.
Larger builds add more collections: locations or franchisees, staff, reviews, projects and FAQs, each referenced from the rows that use them.
Two rules keep the model clean. Shared facts are stored once: your phone number, license details and process live in one place and appear everywhere, so a change is made once. And every fact about a place carries its source, so it can be checked again later.
Useful page or doorway page
This is where most location page projects go wrong, so I will be exact. Google's spam policies describe doorway abuse as sites or pages created to rank for specific, similar search queries that lead users to intermediate pages that are not as useful as the final destination. One of Google's own examples is multiple pages targeted at specific regions or cities that funnel users to one page.
The same policies describe scaled content abuse as generating many pages for the primary purpose of manipulating search rankings and not helping users, no matter how the content is created. Generating many pages with AI tools without adding value for users is listed as an example.
Neither policy bans location pages or templates. They ban pages that give the visitor nothing. So my test for every row is simple: if a customer in that town landed on this page, would it answer their question better than your general service page does? If not, the row does not get published.
How each row gets its own substance
Local facts from sources: county, neighboring towns, population from the Census, and details that matter to the trade, such as housing age, coastline, tree cover or permit rules, taken from municipal and state sources.
What the owner knows: the jobs you do most in that town, what tends to come up there, how far out you schedule. This comes from a conversation with you, and it is the part no competitor can copy.
Service detail that changes by place: what the job usually involves there, and the seasonal timing.
Questions and answers: written for that service in that town. Google has retired the FAQ rich result, so these are written for the reader, not for a search feature.
Internal links: to the same service in nearby towns, to other services in the same town, and up to the main service and town pages.
Your own proof: photos and reviews from real jobs in or near that town, where you have them.
A clear next step: call, text or request a quote.
Research and drafting tools help with volume. They do not replace judgment. Google's guidance on helpful content names generating pages from feeds or with AI "without manual oversight or curation" as low effort, and I treat that as the line.
Quality checks before a row is published
Every place fact has a source URL in the row, and the source says what the page says.
The page is read in full, as a page, not as a spreadsheet cell.
Rows for neighboring towns are compared side by side. If the text is the same apart from the town name, the row goes back.
The title and meta description are unique across the whole collection, with no prices in them.
Every internal link points to a page that is published.
Phone, hours and service area match the Business Profile.
The page makes sense to someone who has never heard of the business.
Only rows marked reviewed are published and added to the sitemap.
Technical setup
Dynamic pages: one template per page type, bound to the collection, with readable URLs such as /roof-repair/attleboro-ma. Google recommends words and hyphens over ID numbers.
Titles and descriptions: written per row, not stamped from one pattern. Google's title guidance warns against boilerplate.
Canonical tags: every page points to itself as the canonical version. Google treats rel="canonical" as a strong signal and sitemap inclusion as a weaker one.
Sitemaps: every published page listed with its full URL. A single sitemap holds up to 50,000 URLs or 50 MB, so large builds are split by page type under a sitemap index.
Breadcrumbs: a visible trail from home to service to town, marked up as BreadcrumbList.
Structured data: LocalBusiness markup with accurate name, address and phone, using the most specific business type. Google does not guarantee any rich display from it.
Crawlable links: real links in the page. Google can only follow a link that is an anchor element with an href, and says every page you care about should be linked from at least one other page.
Franchise brands and multi-location businesses
This is a core part of my work. I built the Christmas Decor franchise website and have worked with 50+ lighting companies. A brand build adds a layer to the model.
Territories: each franchisee or location owns a set of towns or postal codes. Every town belongs to one location, so two franchisees never have pages competing for the same search.
Franchisee or location pages: one per location, with its own name as registered, address or service area, phone, hours, staff, photos, reviews and LocalBusiness markup. This is the page that location's Google Business Profile links to.
Town pages under each location: generated from the territory, carrying that location's phone number and details, never a national number.
Brand fields and local fields: the brand controls name, logo, service descriptions and legal text. Those fields are locked. The location controls hours, staff, photos, local notes and proof. Those fields are open.
Profile rules: Google requires locations in the same country to share one name and one main category, and allows one profile per location. The website data and the profiles are kept in step.
Changes over time: when a territory is sold, split or closed, towns are reassigned in the database and the pages follow. Old URLs are redirected, which Google treats as a strong canonical signal.
The same model fits a company-owned group: a healthcare practice with several clinics, a restaurant group, a contractor with branches. See local SEO for the profile side of multi-location work.
Rollout in phases, and how indexing is watched
Plan: keyword research, the matrix, the cuts, the data model, and one page written in full so the standard is set before the rest are built.
Pilot: the service pages, the town pages and a first group of combinations, usually the towns that matter most to you. Published, added to the sitemap, sitemap submitted in Search Console.
Read the pilot: which pages Google indexes, which searches they appear for, and which rows are weak.
Expand: more towns in batches, built to what the pilot showed. Weak rows are rewritten or dropped.
Maintain: rows are updated as services, service areas and local facts change, and proof from new jobs is added.
Publishing is not the same as being indexed. Google says a sitemap is a hint, not a guarantee, and that you should not expect every URL on a site to be indexed. I watch three things in Search Console:
The Page indexing report, filtered by sitemap. With one sitemap per page type, each type can be read on its own.
The reasons Google gives. "Discovered, currently not indexed" means Google knows the URL and has not crawled it yet. "Crawled, currently not indexed" means it looked and chose not to index it. The first is a waiting state. The second is a signal to improve those rows, not to resubmit them.
The Performance report by page and query. Which towns and services earn impressions and clicks, and which do not.
Google's crawl budget guidance is written for sites with very large page counts. For most local builds it says keeping the sitemap current and checking the Page indexing report regularly is enough. I do not promise rankings or a share of pages indexed.
Common failure modes, and how I avoid them
The town-name swap. One paragraph, 200 towns. This matches Google's doorway example of "substantially similar pages". Avoided by the side-by-side check and by requiring a local section in every row.
Pages that all funnel to one page. Town pages with no content of their own that push everyone to a single contact page. Google lists this as doorway abuse. Each page I build answers the search itself.
Bulk AI text, published unread. This is the scaled content abuse example. Every row is read and checked against its sources before it goes live.
Pages for places you do not serve. They bring calls you cannot take and reviews you do not want. Cut at the matrix stage.
Fake addresses to match the pages. Google does not accept P.O. boxes or unstaffed virtual offices for Business Profiles. Town pages do not need an address in the town, and I do not create one.
Orphan pages. Pages that exist only in the sitemap. Every page is linked from its service page, its town page and its neighbors.
Two pages for one search. Near-identical services, or a village and its town, each with a page. Merged at the matrix stage.
Everything published at once and never looked at again. Avoided by the pilot and by reading the indexing report.
Stale rows. A service dropped, a town no longer covered, pages still live. The database has one place to turn them off.
Rush timelines
Expedited timelines are available when the deadline is real: a lighting company that needs town pages live before the holiday season, a seasonal contractor ahead of its busy months, a new location with an opening date. The way to go fast without cutting quality is to shrink the first phase, not the checks. The pilot covers fewer towns, built to the full standard, and the rest follow. Tell me the date at the start and I will tell you what can be live by then.
What I need from you
The full list of services, in the words your customers use.
The towns you serve today, the ones you want more work in, and the ones you would rather not drive to.
For franchise and multi-location builds: the territory list, the brand rules and a contact for each location.
A conversation about how the work differs from place to place. This is where the local substance comes from.
Photos and reviews, tagged by town where you can.
License, insurance and certification details.
Access to edit the website, and to Google Search Console and your Google Business Profile.
One person who can check a page for accuracy before the standard is set.
Questions to ask any provider
How do you decide which service and town combinations not to build?
What is different on each page apart from the town name?
Where do the local facts come from, and can I see the sources?
Who reads the pages before they are published?
How will I know which pages Google has indexed?
Platforms
I build most often in Wix Studio, where CMS collections and dynamic pages are built in, and I am a Wix Legend Partner. I am not Wix-only. In WordPress the same model is built with custom post types and custom fields. Shopify, Squarespace, Weebly and other platforms can carry smaller builds, and I can add location pages to an existing site on an older platform where it supports them. Every build is a custom design. If your current platform cannot hold structured content, I will say so before any work starts.
Location page projects
Every build is scaled to the business. The method is the same for a regional company covering a handful of towns and a statewide practice that needs hundreds of pages: plan the matrix, cut what should not be built, and give each page its own substance. The page count follows the business, not the other way around.
Tree Medics: a focused regional build. A Southern Maine tree health company works in 16 towns and needed eight service pages and one service area page that covers all 16 properly. That is the whole matrix for a business of that shape, and it was built to the same standard as the larger ones.
Curb Infusion: a statewide program for one trade. A Massachusetts lighting contractor needed local SEO across 100+ towns and cities.
Greater Boston Psychiatric Services: a statewide program for a practice. A Medway, Massachusetts telehealth practice needed a full site, all of its content and 300+ location pages.
Location pages work best alongside local SEO on your Business Profile and listings. To see what a matrix would look like for your business, ask for a free proposal or call or text 508-244-0403. I reply within 24 hours.