Programmatic SEO is the generation of pages from a structured data source at scale. One page per combination of variables, built from a template, published without anybody writing each one. Zillow generating a page per neighbourhood, Indeed per job title and city, a travel site per route pair (Paris to Lyon, Lyon to Nice, and so on down the timetable).
It works spectacularly when two conditions hold and produces a liability when they don’t. The technique itself is neutral. What decides the outcome is whether the pages have a reason to exist that survives somebody asking out loud in a meeting.
The two conditions programmatic SEO needs to work
First, there has to be genuine demand for each combination. Not demand for the head term with the modifiers bolted on. People actually searching that specific combination, in enough volume to justify a URL that Google has to crawl, index and store. Demand that only exists inside a keyword tool’s combinatorial export isn’t demand. It’s arithmetic.
Second, there has to be genuinely differentiating data behind each page. Zillow has sale prices, school ratings and inventory per neighbourhood. Indeed has live postings and salary ranges per title and city. If the only thing changing between page A and page B is the string you substituted into the H1, the title and three body sentences, you don’t have differentiating data. You have find-and-replace with a build step attached.
Both conditions, not one of them. A site with excellent proprietary data and no demand per combination should build one good page with a filter on it. A site with real demand and no data should write the pages by hand, fewer of them, better. Both mistakes cost more than doing nothing, and the second is the more expensive because it feels like progress for a couple of quarters.
Where programmatic SEO crosses into doorway pages
This is the argument I have most often, so the position plainly. The difference between programmatic SEO and doorway pages has nothing to do with templating. Every large site is templated. A product detail page on a Shopify Plus store gets generated from a database (thousands of them, identically) and nobody calls it a doorway.
The distinction is whether the page resolves the query on its own or exists to funnel the visitor somewhere else. Google’s spam policies describe doorway abuse as sites or pages created to rank for specific, similar search queries, which then lead users to intermediate pages less useful than the final destination.
That’s the test. It’s behavioural, not technical.
The same page adds a second test that catches a lot of generated estates: scaled content abuse, where many pages get generated for the primary purpose of manipulating rankings rather than helping users. Note what neither definition mentions. Neither says anything about how the HTML got made.
Two questions settle it in practice. Strip away the template chrome (nav, footer, CTA block, generic supporting copy) and ask whether anything’s left that a person who searched that term actually wanted. Then ask whether you’d build the page if search engines didn’t exist. If either answer is no, they’re doorways whether or not a script generated them.
If the only unique thing on the page is the phrase you substituted into the title, you haven’t built a page. You’ve built a redirect with a paragraph attached.
The quality floor your generator has to enforce
The control that matters is a publish gate in the generation logic, not a cleanup pass six months later. Every combination has to clear a data-completeness threshold before it gets a URL.
A minimum number of populated data fields. A route page with no pricing, no schedule and no operator isn’t a page, it’s a headline.
A minimum count of underlying records. Fewer than n listings, jobs, products or reviews and the combination doesn’t publish. Pick n before you see the results, never after.
Unique content that’s data rather than prose padding. A table, a chart or a set of figures that differ meaningfully from the neighbouring combinations.
A human-readable reason the page exists, written once per template and checked against a sample of twenty generated pages before launch.
The consequence is arithmetic, and it’s where these projects go wrong politically rather than technically. On the estates I’ve worked on, a gate like this turns a planned 90,000 pages into something closer to 4,000, and the person who approved the 90,000 will not enjoy that meeting.
Have it anyway. The alternative is worse. You publish 86,000 pages that drain crawl from URLs that deserve it, and Google is explicit that crawling time wasted on low-value URLs is time not spent on the pages that matter.
Crawl and internal linking for generated pages
A generated page that nothing links to isn’t really a page. Google says plainly that a sitemap helps search engines discover URLs but doesn’t guarantee that everything in it gets crawled and indexed. A sitemap full of URLs with nothing linking to them is a reliable way to grow a large “Discovered – currently not indexed” bucket in Search Console. Google’s definition of that state is that the page was found but not crawled yet, which on a generated estate usually means it wasn’t judged worth the fetch.
So the linking model has to get built alongside the generator, not after it. Hub pages per dimension, cross-links between adjacent combinations a user would plausibly want, and a depth target keeping every generated page within three or four clicks of an entry point.
If you’re generating 4,000 pages, you’re also generating the navigation that reaches them.
Ship in tranches and measure indexation before the next goes out. Publish 500, watch the logs to confirm Googlebot is fetching them, watch the indexed proportion over two or three crawl cycles, then release the next batch. If tranche one indexes at 30%, tranche two won’t fix it. It’ll make it worse and cost you crawl you needed elsewhere. The crawl budget mechanics behind that are worth reading before you start.
Governance, or the page count runs away from you
The failure mode of a successful generator is that it succeeds. Somebody sees the traffic and adds a third dimension to the template. The page count goes from 4,000 to 340,000 in a quarter, without anybody re-testing the demand or the data floor. This has happened on every large programmatic estate in the portfolio.
The generator has a named owner in engineering, not in marketing. Adding a dimension is a code change with a review, not a spreadsheet upload on a Friday.
Every new template or dimension requires a demand case and a data-completeness spec before anybody builds it.
A quarterly prune, scheduled and owned by a named person, is the difference between an estate that stays useful and one that quietly turns into the thing Google’s policy describes. Indexed pages that earn zero impressions over six to twelve months (accounting for seasonality) get consolidated or removed rather than left to accumulate.
A hard ceiling on total generated URLs, agreed in advance, that takes a deliberate decision to raise.
Pruning is the part teams resist, because deleting pages feels like deleting assets. It isn’t. A page that has never taken a single impression is a page Google has had every opportunity to rank and chose not to. Leave thousands of them in place and the estate starts to look, from the outside, like the scaled content that policy describes.
How to get started with programmatic SEO
Take your top 30 proposed combinations and check real search volume for each individually, not as a multiplication. Then build one page by hand, to the standard you intend to hit, and ask whether you’d be happy for it to rank.
If the answer is uncomfortable at one page, it doesn’t improve at forty thousand.
Write the data-completeness gate before the template, and run it against your data to see how many pages qualify. Design the internal linking and hub structure as part of the build rather than afterwards. Then launch 500, measure indexation over two crawl cycles, and make the next tranche conditional on the result.
Built with those constraints, programmatic pages are among the best returns available on a large site. Built without them, you’ve bought a machine that manufactures a problem faster than anybody can audit it. Settling the demand modelling and the architecture before anything ships is the front half of my technical SEO work.