Every large site you use daily is programmatic. A property portal has a page for every locality, a travel site for every route, a job board for every title in every city. Nobody wrote those pages one at a time; a template was designed, a dataset was connected, and the pages were generated. That is programmatic SEO, and it is one of the most powerful things you can do in search, which is exactly why it is also one of the most abused. I have written separately about why it is not a shortcut; this is the long form.
What programmatic SEO is
Programmatic SEO is the generation of a set of pages from a single template populated by a structured dataset, where each page targets a distinct search intent that follows a pattern. The pattern is usually "[thing] in [place]", "[thing] for [segment]", "[A] vs [B]", "[A] to [B]", or "[attribute] [category]". The dataset supplies the values; the template supplies the structure; the combination supplies the pages.
What makes it SEO rather than just dynamic web pages is that each generated page is intended to rank for its own query. That intent is what imposes the quality requirement. A dynamic page that exists only for users who navigate to it can be thin. A page that is asking a search engine to rank it has to be worth ranking.
Three things have to be true for the approach to make sense:
- Real demand per page
- Real data per page
- Quality enforced per page
If any one is missing, the build will produce either pages nobody searches for, pages with nothing on them, or pages that vary only in the words substituted into the template. All three outcomes look like success in the CMS ("we published 8,000 pages") and like failure in Search Console.
When it is justified: real demand times real data
The test I use is a multiplication. Is there a pattern of queries with meaningful demand for each individual combination, not just the pattern in aggregate? And do I have data that is genuinely different for each combination, enough to make a page that answers the query better than the existing results? Demand times data. If either factor is near zero, the product is near zero.
Demand per page, not in aggregate
"Coworking space in [city]" has demand for Bangalore, Mumbai, Pune and Hyderabad, and almost none for the four hundred towns in a district list. A build that generates pages for all of them produces a handful of useful pages and hundreds of pages with zero impressions. Check the demand at the level of the individual combination, using Search Console data if the site already has some coverage, keyword tools for the head combinations, and sampling for the tail. Build the combinations that have demand; keep the rest out of the index until they do.
Data per page, not per template
The question is what will differ between two pages beyond the substituted values. For a coworking page: the actual spaces in that city, their addresses, prices, amenities, photos, reviews, proximity to transit. For a "[tool A] to [tool B]" conversion page: the real field mapping and the real steps. If the honest answer is "the city name and a paragraph written to sound local", there is no data and there should be no page.
| Page type | Pattern | Typical data source | Justified when | Fails when |
|---|---|---|---|---|
| Location pages | "[service] in [city]" | Listings, inventory, outlets, local pricing | Each city has real inventory or real operations | Same page with the city name swapped |
| Comparison pages | "[A] vs [B]" | Feature matrices, specs, pricing | Structured, accurate attribute data for both | Generated prose with no attribute differences |
| Integration / conversion pages | "[A] to [B]", "[A] [B] integration" | Product integration metadata | Each pair has documented fields, triggers, steps | "Connect A to B in minutes" and nothing else |
| Glossary / definition pages | "what is [term]" | Curated definitions, examples | Terms are specific to your domain and defined well | Generic definitions copied from the top result |
| Spec / attribute pages | "[category] [attribute]" | Product catalogue attributes | Attribute has demand and enough products | Hundreds of combinations with one or zero items |
Data sources
The dataset is the product. Templates are easy; good data is hard, and the quality of the build is capped by it.
- First-party data is the best source and the reason the approach works for marketplaces, SaaS products and catalogues: inventory, listings, product attributes, usage data, integration metadata, user content. It is unique to you and it updates itself.
- Official and open data (government statistics, census, regulatory registers, exchange rates, standards) is legitimate and often rich, but every competitor can use it too, so the differentiation has to come from how it is combined and presented.
- Scraped data is the most common source and the most dangerous: often of uncertain legality, usually stale within months, and frequently identical to what the sites you scraped already publish. I do not build on it.
- Generated text (from a language model) is not data. It can help phrase a page around real data; it cannot substitute for the data.
Whatever the source, the pipeline needs to be repeatable: the pages must regenerate when the data changes, and the data must have an owner who keeps it current.
Template design
A template is a page design plus a set of rules for how data fills it. The design goal is that two pages from the same template are different in the ways a searcher would care about, and that a page with less data is shorter, not padded.
Structure
A workable template usually has: a title and H1 pattern that reads naturally; a specific summary of what this page's data says (not a generic intro); the core data in the form that suits it (table, list, map, calculator result); contextual sections that only render when data exists for them; related entities (nearby cities, similar comparisons, sibling attributes) as real links; and a FAQ generated from real questions about this combination, if you have them.
Conditional rendering
This is the rule that separates good builds from bad. Variation should come from the data, not from spinning sentence structures; if the data varies, the pages vary. Every section renders only if its data is present and meaningful. A city with no transit data gets no transit section. A comparison where both tools share a feature does not get a sentence saying they share it. Empty sections filled with "information not available" or boilerplate are the visible signature of a template built without conditions.
Uniqueness and quality thresholds
A threshold is a rule that decides whether a generated page is allowed to be indexable. It is applied automatically, at generation time, and it is the main safeguard against the failure modes below. Without one, the number of indexable pages is simply the number of rows in the dataset, which is almost never the right number.
Thresholds I commonly use, adjusted per build:
- Minimum data completeness. The page must have values for a defined set of core fields. A listings page needs at least a minimum number of listings; a comparison needs a minimum number of differing attributes.
- Minimum unique content proportion. The share of the page's text that is data-driven rather than template boilerplate must exceed a set level. I measure this by rendering the page and comparing it to the template skeleton.
- Demand evidence. The combination has recorded impressions, search volume above a floor, or belongs to a head set validated by sampling.
- Near-duplicate check. If two generated pages are nearly identical (two localities with the same listings, two comparisons with the same differences), one is canonicalised to the other or both are consolidated into a parent.
Pages that fail a threshold still exist for users who navigate to them, but they are set to noindex, excluded from sitemaps, and linked less prominently. When their data improves, they cross the threshold and are promoted. This makes the build adaptive rather than binary.
Internal linking and hub structure
Thousands of pages with no inbound links except a sitemap are orphans, and orphans do not get crawled or ranked reliably. I tested this directly in the orphan pages experiment. A programmatic build needs a link structure designed at the same time as the template.
The structure I use is hierarchical with lateral links:
A hub page for the whole set
A real, hand-written page explaining what the set is and linking to the top-level groupings. "Coworking spaces in India", linking to states or major cities.
Intermediate hubs for groupings
State or category pages that list and link to the individual pages in their group, with enough content to stand on their own. These are often the pages that rank for the mid-tail queries.
Lateral links between siblings
Each generated page links to a small number of related pages chosen by data (nearest cities, most-compared alternatives, adjacent attributes), not randomly. These links are what make the set a graph rather than a list.
The internal linking framework covers the general method; for programmatic sets, the extra rule is that link selection must itself be data-driven, otherwise the links are as thin as the content they sit in.
Indexing control
Indexing control is how you make sure the search engine sees the pages you want it to see and not the ones you do not. On a build of any size this has to be designed, because the default (everything crawlable, everything indexable, everything in the sitemap) is almost always wrong.
- Sitemaps contain only pages that pass the thresholds, split by section, with accurate lastmod. The sitemap becomes the single source of truth for "pages I want indexed" and lets you compare against Search Console's indexed count.
- Noindex on pages below threshold, applied in the server response, not by JavaScript.
- Canonicals on near-duplicates, pointing to the richer page.
- Robots.txt for parameterised, sorted or filtered variants that should never be crawled. Test it with the robots.txt tester.
- Staged release. Release pages in batches, highest-demand first, and watch indexing and performance before releasing more.
Crawl budget is real for large builds. If the crawler is spending its requests on filtered variants and noindexed pages, the pages you care about are discovered and refreshed slowly. The crawlability guide covers how to read crawl stats and logs to check this.
Monitoring
A programmatic build is not finished when it is launched. It is a system that needs instrumentation, because problems at scale are invisible page by page.
What I watch, usually weekly:
- Indexed versus submitted. Pages in the sitemap compared to pages indexed, per section.
- Impressions distribution. What share of pages receive any impressions at all. A build where most pages get zero impressions after a few months has a demand problem, and those pages should be demoted.
- "Crawled, currently not indexed" and "Discovered, currently not indexed" counts in Search Console. These are Google's quality verdict on the set, and a rising count is the earliest warning.
Failure modes
Thin pages
The classic failure. Pages that consist of a template with values substituted and nothing a searcher would stay for. Google's response is usually not a penalty but indifference: the pages sit in "crawled, currently not indexed", and the ones that do get indexed rank briefly and fade. The fix is thresholds and conditional rendering; the prevention is the demand-times-data test before building.
Index bloat
Tens of thousands of indexable URLs on a site whose actual useful content is a few hundred pages. Even when the generated pages are individually acceptable, the sheer number can drag the site's overall quality assessment and starve the important pages of crawl attention. Symptoms: declining performance on non-programmatic pages after the build, rising "not indexed" counts, slow discovery of new content. The fix is aggressive: demote the pages that have not earned impressions, consolidate near-duplicates, and release the rest in stages.
Cannibalisation
Generated pages competing with each other or with hand-written pages for the same queries. "[Service] in Gurgaon" from the programmatic set competing with the editorial Gurgaon landing page; "A vs B" and "B vs A" both indexed; attribute pages overlapping category pages. The fix is a rule for which page owns which intent, applied in generation, with the losers canonicalised or merged.
Generated-text builds
The newest failure mode: thousands of pages whose only variation is paragraphs written by a language model around a thin dataset. These read well and contain nothing. They tend to be indexed initially and lose visibility in subsequent quality updates, taking the rest of the site with them. My position is the same as throughout: generated text can describe real data; it cannot replace it. The AI SEO guide has more on where generation does and does not belong.
Programmatic SEO scales whatever you put into it. Put in real demand and real data and it scales usefulness. Put in a template and a list of cities and it scales nothing.
Frequently asked questions
Is programmatic SEO against Google's guidelines?
No. Generating pages from data is how most large sites work. What the guidelines address is scaled content whose purpose is to manipulate rankings rather than help people, which is what a thin, template-only build is. The approach is fine; the thin version of it is not.
How many pages should a programmatic build have?
As many as pass the demand and data thresholds, and no more. That number comes out of the data, not from a target. A build of three hundred strong pages outperforms a build of thirty thousand weak ones and is less risky to the rest of the site.
Can I use AI-generated text in programmatic pages?
To phrase and summarise real data, yes, with review. As the main source of variation between pages, no. Pages that differ only in generated prose around the same thin data are thin content, and they tend to lose visibility in quality updates.
What do I do with programmatic pages that get no impressions?
After a few months for a well-linked set, demote them: noindex, remove from the sitemap, reduce internal links. Keep them for users if they serve a purpose, and re-promote only if the data or demand changes.
How is programmatic SEO different from the ecommerce or local pages I already have?
It is the same discipline applied deliberately. Category, facet and location pages are programmatic whether or not you call them that. The guides on ecommerce SEO and local SEO apply the same demand, data and threshold rules to those specific page types.
Where this connects
The Programmatic SEO Framework is the operational version of this guide: the demand-times-data scoring, the threshold definitions and the release checklist I use on builds. The programmatic page templates experiment in the SEO Lab compares template designs on indexing and performance. The programmatic SEO build case study follows one such build from data to release. If you want a build designed and implemented rather than explained, that is my programmatic SEO service.