Programmatic SEO has two reputations, and both are earned. Done properly it produces some of the most valuable page sets on the web: product categories, route pages, comparison pages, local inventory. Done carelessly it produces thousands of near-identical pages that damage the whole site.
Google's spam policies describe the failure mode explicitly: pages created mainly to manipulate rankings, without providing enough value to users, can be treated as scaled content abuse. That framing is useful, because it names the actual test — value to a user, not page count.
The mechanism that keeps you on the right side of it is a quality floor.
What a quality floor is
A written, enforced rule about the minimum a page must contain before it is allowed to be published and indexed.
Concretely, for a few common page types:
- Category × attribute (ecommerce): at least N in-stock products, at least one unique attribute description, and measurable search demand for the combination.
- Location × service (marketplaces, ecommerce, property): at least N live listings in that location, plus at least one genuinely local data point that is not the location name substituted into a sentence.
- Comparison pages (SaaS): both products actually documented, at least N compared dimensions with real values, and an honest statement of which product suits which case.
- Route or destination pages (travel): availability in a normal season, plus information that survives someone actually planning the trip.
The specific thresholds matter less than the fact that they exist, are written down, and are checked automatically at publish time.
Validate two things before writing any code
Most failed programmatic projects fail one of these, and both are cheap to check first.
Does real search demand exist for this page type? Not for the head term — for the combination. "Blue running shoes size 11" may have demand; "blue running shoes size 11 in Leeds" may not. Sample fifty combinations across the range and look at actual query data.
Can your dataset fill the template? Check field completeness across the whole dataset, not the demo rows. If 60% of records are missing the field that makes the page useful, you are about to publish 60% thin pages.
The answer to "how many pages should we build?" is almost always far fewer than the combinatorial maximum. That is a feature.
Design the page around a question, not a pattern
Write the user's question first, in their words. Then design a page that answers it.
If you cannot write the question — if the only justification for the page is that the URL pattern exists and a keyword tool returned a number — that page should not be built. This test is quick, it can be applied by anyone, and it removes most bad page types before they reach a sprint.
Pilot before you scale
Build a controlled subset. A few hundred pages across the range of data quality, from richest to thinnest.
Then measure, over 60–90 days:
- Indexation rate by data-richness band. If the thin band does not get indexed, that is your quality floor telling you where it sits.
- Engagement and conversion by band.
- Share of pages earning anything at all.
A pilot turns "how many pages should we build?" into a measured answer instead of an argument. It also means a bad template costs you a subset rather than a site.
Ship the controls with the pages, not afterwards
Retrofitting indexation control onto a live programmatic set is much harder than building it in. From day one:
- Indexation rules: which combinations are indexable, which canonicalise to a parent, which are blocked entirely.
- Canonical logic across similar combinations, so near-duplicates resolve to one destination.
- Sitemap segmentation by page type, so a coverage problem can be localised to a page type rather than a site.
- Internal linking: generated pages need real links from real hubs, or they are orphans regardless of quality.
- Per-page-type monitoring: indexation, traffic and conversion by type. A whole page type can lose indexation silently if reporting is site-wide.
Datasets change, so pruning is routine
The floor is not a launch-day check. Inventory sells, listings expire, products get discontinued, availability changes. A page that cleared the floor in March may not clear it in September.
So write the pruning rule at the same time as the publishing rule:
- Pages that fall below the floor get de-indexed or removed, on a schedule.
- Pages that have earned nothing after a defined window get reviewed.
- Removal handling is decided per page type — 404, redirect to the nearest useful equivalent, or keep with a clear status label — and implemented consistently.
If pruning only happens during a crisis, it will be done in a hurry with a heuristic, and it will remove things it should not.
Where AI fits, and where it does not
Useful: summarising structured data into readable prose, drafting descriptions from real attribute values, generating briefs, classifying and clustering demand, writing the checks that enforce the floor.
Not useful: producing text to fill pages that have no data behind them. That is precisely the scaled-content case the spam policies describe, and the fact that generation is cheap now is what makes the floor more important, not less.
A human has to own two judgements that cannot be delegated: whether the page type should exist, and where the floor sits.
The test, in one sentence
If a real person landed on this page from a real search, would they find enough here to be glad they arrived?
If the honest answer is no for a whole page type, do not build it. If the honest answer is no for 40% of the instances, that is your floor.
Want this done on your site instead of by you?
A Growth Diagnostic runs this analysis across search, technical, analytics, content, conversion and AI search, and comes back with what matters first.