Programmatic SEO without building a spam site

Programmatic SEO means creating many pages from a template and a dataset: one page per city, per product combination, per integration, per currency pair, per job title. Some of the most useful sites on the web work this way. Travel sites have a page per route with schedules and prices; software directories have a page per integration with setup details; property sites have a page per neighbourhood with prices and local data. Each page answers a specific search with specific information.

The same method also produces some of the worst pages on the web: "Best plumber in [city]" repeated for 3,000 towns with the city name swapped and nothing else different. Google's spam policies describe scaled content abuse as producing many pages primarily to manipulate rankings while providing little value, regardless of whether a person, a template or an AI wrote them. The method is neutral. The data decides which side you are on.

The one test that matters

For any template, ask: if a knowledgeable person wrote this specific page by hand, would it be worth publishing? Then look at five randomly chosen generated pages, not the five best ones.

• If each page contains information the searcher cannot easily get elsewhere, specific to that page (prices, schedules, measurements, availability, reviews, statistics, setup steps), it passes.
• If the pages are identical except for the name in the heading and a few inserted words, it fails, however good the template text is.

A useful variant of the test: delete the page's name from the text. If you can no longer tell which page you are looking at, the page has no unique content.

Examples that pass and fail

Template	Unique data per page	Verdict
Train route pages ("Lyon to Geneva trains")	Journey times, frequencies, operators, typical fares, stations, changes	Pass
Integration pages ("Calendar X + Invoicing Y")	What syncs, field mapping, setup steps, limitations, screenshots	Pass, if each is documented
Currency converter pages ("EUR to GBP")	Live rate, history chart, fees comparison	Pass
Neighbourhood pages for a property site	Prices, listings, schools, transport, local descriptions	Pass if data is real and current
"Plumber in [town]" for a business with one office	None; the business does not operate there	Fail
"Best [product] for [profession]" for 400 professions	Usually the same product list	Fail
"[Keyword] in [year]" variants	None	Fail

Data comes first

Successful programmatic projects start from a dataset the business already has or can maintain, not from a keyword list. Questions to answer before designing templates:

• Where does the data come from? Your own operations, partners, public datasets, user contributions? Data copied from another site adds nothing.
• How complete is it? If 60% of combinations have only one or two data points, those pages will be thin.
• How fresh does it need to be, and can you keep it updated? Stale prices or schedules are worse than none.
• What can you add that others cannot? Your own measurements, reviews, transaction data (aggregated), or expert notes.

Set a minimum data threshold per page and do not generate pages below it. A neighbourhood with no listings and no statistics should not have a page yet.

Designing the template

• Lead with the unique data. The first screen should show what is specific to this page: the timetable, the price range, the setup steps. Generic explanation goes lower, or on a single shared guide page linked from all of them.
• Vary structure with the data. If a route has no direct trains, the page should say so prominently and show the best connection, not display an empty "direct trains" table.
• Write conditional text sparingly. Sentences generated from data ("Trains run every 30 minutes on weekdays, hourly on Sundays") are useful when they summarise real differences. Paragraphs spun from synonyms are not.
• Add human-written content where it pays. For the top pages by demand, editors can add notes, photos or tips. A hybrid of generated data and hand-written highlights is often the strongest.
• Give every page a clear title and H1 built from the data, and a unique meta description that mentions a specific detail.

Indexing and internal linking

Generated pages need routes for crawlers, like any other page. Organise them into hubs (a page per country listing its cities, a page per category listing its integrations), link related pages to each other (nearby neighbourhoods, alternative routes), and list them in XML sitemaps split by type so you can see indexing per template in Search Console. See XML sitemaps and internal linking.

Expect search engines to index a subset, especially at first. Many generated pages sitting in "Discovered – currently not indexed" or "Crawled – currently not indexed" in the Page indexing report is a quality signal: Google has looked and is not convinced. That is useful feedback about the template.

Roll out in stages

1. Prototype ten pages by hand-checking the output. Apply the one test above to each.
2. Launch a first batch of a few hundred pages with the best data and the most search demand.
3. Wait four to eight weeks. Check indexing rate, impressions, clicks and engagement for the batch.
4. Improve the template based on what you see: which sections users engage with, which pages are not indexed and why.
5. Expand to the next batch only if the first batch is indexed and performing.

A batch where most pages stay unindexed after two months is a signal to improve the data or the template, not to publish more pages. Pushing on regardless tends to make things worse, because a growing share of weak pages can colour how search engines see the whole site.

Technical performance at scale

Templates multiply every technical decision. A slow database query on one page is a slow query on fifty thousand pages, and a canonical bug in the template is a canonical bug everywhere.

• Cache the rendered pages. Generated pages are often built from several queries; serve cached HTML so crawlers and users get fast responses. See server response time.
• Keep URLs stable and predictable. Build them from stable identifiers, not from text that might change, and decide upfront how renamed entities redirect.
• Avoid generating combination pages from every filter. Two dimensions (route and month, city and category) are usually the maximum that produces distinct pages; three or more multiplies thin pages. The faceted navigation guide covers the same problem from the shop side.
• Check the template with a crawler on a sample before launch: status codes, titles, canonicals, internal links, rendering.

AI-written filler is not data

Language models make it trivial to add 300 words of text to every generated page. That text rarely adds value: it restates the heading, describes the city in generalities, or invents details that are not in the data. It also makes pages look more alike, not less. If you use AI in a programmatic pipeline, use it to summarise or explain real per-page data, constrain it to that data, and check samples by hand. The AI-assisted content guide has more on where these tools help.

Ongoing quality control

• Automated checks for pages whose data falls below the threshold (for example, after listings sell out), which should then be noindexed or removed.
• Regular sampling of random pages by a person.
• Monitoring for duplicate titles and near-duplicate content across the set.
• Tracking performance per template, not just per page, so problems in one template are visible.

The pruning guide covers how to clean up when a generated section has grown beyond its data. And if the pages are local in nature, the location pages guide covers the specific risks of doorway pages.

The short version

Programmatic SEO works when the database is the product: when each generated page shows information that is specific, accurate and hard to get elsewhere. It fails when the template is the product and the data is a list of keywords. Start small, measure honestly, and grow only what earns its place.