Skip to the journal
Search Engine Optimization Directory

Programmatic SEO: Building Pages at Scale Without Creating Thin Content

  • Filed November 10, 2026
  • Content strategy, guide 9 of 13

Programmatic SEO means generating many pages from a template and a dataset: one page per city, product, integration, route, salary band or comparison. It is not spam by definition. Google’s scaled content abuse policy targets pages “generated for the primary purpose of manipulating search rankings and not helping users”, and says the abuse is typically “large amounts of unoriginal content that provides little to no value to users, no matter how it’s created” (Google’s spam policies). The same template can produce a useful directory or a doorway network. What separates them is the data behind each page, the purpose of the set, and whether each page gives a reader something a single page could not.

When template-driven pages are useful

A programmatic set earns its place when:

  • each page answers a distinct query with distinct information. A train timetable page for each route, a product page for each SKU, an exchange rate page for each currency pair.
  • the data is real, accurate and maintained. Prices, schedules, specifications and availability come from a source that is updated.
  • a reader landing on any single page gets a complete answer without needing to visit the others.
  • the set forms a browsable structure, not a pile of near-identical entry points.

When it crosses into abuse

Google’s examples of scaled content abuse include generating many pages with generative AI or similar tools without adding value, scraping feeds or search results to generate pages, and stitching or combining content from different pages without adding value. Its doorway policy describes “pages targeted at specific regions or cities that funnel users to one page” and “substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy”.

Patterns that signal trouble:

  • pages that differ only by a swapped place name or keyword;
  • thin data (one figure per page) padded with generic text;
  • pages generated for every combination of variables, including combinations nobody searches for or that have no data;
  • every page funneling to the same contact form or product without its own answer;
  • content sources the site has no right to republish.

A go/no-go quality framework

Run each proposed set through these questions before generating a single page. A “no” on any of the first four is a stop.

# Question Go No-go
1 Is there a real search need per page, not just per keyword variant? Distinct intents with distinct answers Variants of one intent
2 Does each page carry unique, useful data? Several data points specific to the page's entity One data point or none
3 Is the data accurate, licensed and maintained? Owned or licensed source with an update process Scraped, stale or unverified
4 Would a reader on one page be satisfied without visiting another? Yes The page exists to send them elsewhere
5 Does the set have a browsable hierarchy? Index pages, categories, filters linking logically Flat list of thousands of entry pages
6 Is there a rule for empty or thin combinations? Not generated, or <!–INLINECODE0–>, or 404 Generated anyway
7 Is there editorial review? Sampled human review per template and per data refresh None
8 Can the set be maintained at its size? Owner, monitoring and refresh schedule Publish and forget

Template rules that keep pages differentiated

  • Make data the core of the page, not decoration around a paragraph. Tables, figures and comparisons specific to the entity.
  • Write conditional text, not fixed text. Sentences that change meaning based on the data (“prices on this route are lower on weekdays” appears only when the data shows it), rather than a paragraph that says the same thing on every page.
  • Suppress empty sections. If a page has no reviews, no events or no prices, do not render an empty section with filler.
  • Set a minimum data threshold. A page is generated only if the entity has enough data to answer the query.
  • Link within the set by real relationships: nearby cities, related products, the next route.

Quality assurance at scale

  1. Sample review. Read a random sample of pages from each template, plus the pages with the least data.
  2. Duplicate check. Compare text similarity across pages of the same template; pages that are nearly identical apart from the entity name fail question 2 of the framework.
  3. Data accuracy check. Compare a sample against the source.
  4. Index monitoring. After launch, watch the Page indexing report for the set. A large share of “Crawled, currently not indexed” in one template is a signal to reassess that template’s value.
  5. Search performance by template. Track impressions and clicks per template, not just per page, to see which sets deliver.

Maintenance

Programmatic pages age at the speed of their data. Stale prices, closed businesses, discontinued products and outdated schedules repeat on every page that draws on the same source, so one stale feed can mislead readers across the whole set. Decide before launch:

  • how often each data source refreshes;
  • what happens to a page when its entity disappears (redirect to a parent, 404, or an informative archive page);
  • who owns each template.

AI-generated text inside templates

Generative AI can draft descriptions for templated pages, within what Google’s policies on AI-generated content allow. Google’s guidance says AI use is not itself the problem, but that using generative AI to create many pages without adding value “may violate Google’s spam policy on scaled content abuse” (Google on using generative AI content). The same page stresses fact-checking AI-generated content before publishing. Where AI writes text for thousands of pages, the text must still be grounded in the page’s data, checked for accuracy, and specific enough that it would not read the same on every page.

From 10,000 city pairs to 400 data-backed pages

A hypothetical moving company comparison site wants pages for moves between US city pairs.

  • Naive plan: 10,000 city pairs, each with the same paragraph about “moving from {City A} to {City B}” and a quote form. Questions 1, 2 and 4 fail: the pages differ only by names and exist to collect leads. This is the pattern Google’s doorway examples describe.
  • Revised plan: pages only for the 400 pairs where the site has real data: distance, sample quotes from listed movers, average transit times reported by movers, and the movers licensed for that route. Each page shows that data, with conditional text based on it, and links to the origin and destination city hubs.
  • Rules: pairs with fewer than five quotes are not generated; quotes older than 12 months are removed; a monthly refresh updates figures.
  • Monitoring: the Page indexing report and Performance report filtered to the template.

The revised plan is still programmatic. It is defensible because every page answers its own question with its own data.

The test in one line

If deleting any single page from the set would leave a searcher with a question that no other page answers as well, the set is doing its job. If every page could be deleted except one with no loss, the set exists for rankings, not readers.