THE SHORT ANSWER
Programmatic SEO still works, and retrieval-based search arguably rewards it more than classic ranking did, because breadth beats depth when there is no single winning position. The condition has hardened, though. A page whose only variable is a place name adds nothing a model cannot generate itself. Each page needs at least one fact true only of that combination, a real data spine behind the template, and a quality gate that refuses to publish rows with insufficient data.
Programmatic SEO earned its bad reputation honestly. A decade of spun location pages, thin comparison grids and auto-generated category stubs taught everyone that scale without substance gets filtered eventually, and taught a generation of marketers to flinch at the word. The reasonable conclusion many people drew was that generated answers would finish the job off, since a machine can now produce the same shallow paragraph on demand and nobody needs a page for it.
The opposite happened, for a structural reason. Retrieval rewards having a passage that matches a specific question, and specific questions are numerous. A hundred pages each answering one narrow combination will be retrieved more often than one long page trying to cover all hundred, because the long page dilutes every individual match. Scale is an advantage again, provided the pages are not empty.
The numbers, at a glance
The condition: every page must carry at least one fact that is true only of that specific row and cannot be inferred from the template
Why breadth pays: with no position one to win, twenty pages cited occasionally beat one page fighting for a top slot it may never reach
The practical quality gate: refuse to publish any row whose data spine has fewer than a set number of populated fields, and accept a smaller page count
What gets filtered: sets where the only variable is a name substitution, which both classic ranking and retrieval treat as one page repeated
The data spine is the product, the template is packaging
Every programmatic set worth building starts from a table, not from a page design. One row per page, one column per fact, and the interesting question is how many columns you can populate with something genuinely variable. If the honest answer is one, you do not have a programmatic project, you have a find-and-replace operation.
For a lead supplier operating across twelve countries and ten trades, the spine has obvious variable columns: typical job value in that country, seasonality of demand, permit or grant regime, average number of installers competing per enquiry, the local price band, the language the enquiry arrives in. Each of those makes the combination page factually different from its neighbours, and each of them is something a model cannot invent reliably.
Building a template that does not read as a template
Vary the structure, not just the values. Write three or four section arrangements and select between them based on which data the row actually has, so pages with rich data look different from sparse ones.
Write conditional prose. Sentences that only appear when a threshold is crossed, such as a note about grant availability that renders only where a grant exists, make pages diverge naturally.
Lead with the row's own number. Put the fact unique to this page in the opening paragraph and in one heading, not buried in a table at the bottom.
Let the internal links differ. Link to genuinely related rows rather than emitting the same navigation block on every page.
Date the data. A visible as-of date per page both helps retrieval and forces you to maintain the spine.
The test is simple and brutal: print two pages from opposite ends of the set, cover the titles, and hand them to someone who does not know the project. If they cannot tell they are reading about different things, the set is not ready.
The quality gate nobody wants to build
Every programmatic project reaches a moment where the spine supports four hundred good pages and someone wants twelve hundred. The gate is a rule, written before that conversation, that refuses to render any row below a minimum threshold of populated fields. Rows that fail the gate either get researched properly or stay unpublished.
Holding that line is the whole discipline. Index bloat is not just an abstract risk: a set where two thirds of the pages are thin drags evaluation of the good third, because quality assessment operates at site and section level as well as page level. Publishing four hundred strong pages and no weak ones outperforms publishing twelve hundred mixed ones, consistently and by a wide margin.
How to know whether the set is working
Judge a programmatic set on coverage of the long tail rather than on the performance of individual pages. The right question is what share of the set has earned any impressions at all after ninety days. Anything above roughly half is healthy; anything below a quarter suggests the pages are too similar for the engine to see a reason to differentiate them.
For retrieval specifically, sample the set: pick ten rows, ask an assistant the exact question that row answers, and count how often your page is the cited source. That is a harsher test than impressions and a more honest one, because it measures whether the page is the best available answer to its own question rather than merely present.
Building a programmatic set that survives
Build the data table first and count how many columns vary genuinely per row.
Kill the project if the honest answer is one column, and go and gather data instead.
Write a quality gate that blocks rendering below a minimum number of populated fields.
Design three template variants selected by data richness rather than one layout for everything.
At ninety days, measure the share of the set with any impressions and prune or enrich the silent rows.
Want leads like this in your pipeline?
Flock runs the campaigns, screens the enquiries and hands you only the ones that match your service area, job size and capacity. You pay per lead, not per month.
Book a 15-minute fit check | See lead package pricing
Related answers
Frequently asked questions
Is programmatic SEO against search engine guidelines?
Scale is not the issue; the guidelines target content produced primarily to manipulate rankings with no value to a reader. A generated page carrying real, checkable data specific to its subject is fine. A page whose only variable is a place name is the thing being targeted, and always was.
How many pages is too many?
There is no absolute number. The constraint is your data, not the engine's tolerance. If you can populate a strong spine for two thousand rows, publish two thousand. If your data supports one hundred, publishing one thousand will underperform publishing the hundred.
Should each page have its own FAQ block?
Only if the answers differ per row. A repeated FAQ across four hundred pages is duplicate content that adds nothing and dilutes the distinctiveness you worked to build. Generate the questions from the row data or leave the block off entirely.
Do these pages get cited by assistants?
Yes, and disproportionately for narrow questions, because a page answering exactly one specific combination matches a specific query better than a broad guide. That is the main reason the technique has more upside now than it did when only classic ranking mattered.
NEED A CLEARER PLAN?
Let’s turn your next move into momentum.
Talk to us →