Programmatic SEO is seductive for one simple reason: the promise of covering thousands of long-tail queries without writing thousands of pages by hand. One page per city, per product, per use case, per combination of criteria, generated from a template and a database. It is the machinery that powers the giants: Airbnb's listing pages, Zapier's integration pages, Canva's template pages. Millions of pages, millions of organic visits.
Except the same machinery, badly used, produces exactly what Google decided to crush in 2026: farms of empty pages, recolored on an assembly line. Since the tightening of the scaled content abuse policy (begun in 2024, sharpened by the March 2026 update), the line between asset and liability has never been clearer. This article is a field report on what separates the two, drawn from projects run on Odoo and PrestaShop catalogs: how to generate at scale without over-optimizing, and without waking the filter.
Programmatic SEO is not a shortcut to producing content. It is a method to industrialize pages that deserved to exist anyway. That nuance is the entire difference between an asset that appreciates and a liability that ends up in noindex.
Programmatic SEO, concretely
The principle comes down to two ingredients: a template (the page structure, the internal linking, the content zones) and a data source (a spreadsheet, a database, a product feed). You design the model once and fill it as many times as there are rows in the data. A page for "plumber in {city}", "spare part for {model}", "alternative to {software}": each row becomes a URL targeting a precise query that nobody searches in isolation, but which, added to thousands of others, represents considerable volume.
On an e-commerce catalog, this is the natural ground for the approach: category pages, filter pages, brand pages, compatibility pages. It is exactly the logic I detail in my article on catalog architecture and facets. Programmatic SEO is its industrial extension. The question is not "can we generate these pages?" (technically, both Odoo and PrestaShop allow it), but "which ones deserve to exist?".
The red line of 2026: scaled content abuse
Google does not penalize bulk page generation in itself. What its scaled content abuse policy targets is the production of large volumes of pages whose primary purpose is to manipulate rankings rather than help users. The definition rests on two words: volume and intent. The March 2026 update hit hard. Sites publishing thousands of near-identical pages, often AI-generated without review, saw their traffic collapse by 60 to 90% almost overnight.
The good news is that the survival criterion is clear, and it depends on neither volume nor automation. A programmatically generated page survives if it meets three conditions: it contains data of its own (that the other pages in the set do not have), it answers a distinct query that no other page on the site already covers, and it generates engagement signals confirming it does that job. Zapier, Airbnb and Canva are not spared because they are big, but because each of their pages delivers verifiable, unique data. The penalty does not land on the method; it lands on the void.
Field report: Odoo and PrestaShop at scale
On a technical catalog running on Odoo (tens of thousands of references, many variants and compatibilities), the temptation is to generate everything: one page per reference, per filter combination, per conceivable query. That is precisely where over-optimization happens. The first useful decision was not to produce, but to sort: which queries have real demand (volume, purchase intent), and which are merely theoretical permutations nobody searches for.
The result comes down to one discipline: generate far fewer pages than the combinatorics allow, but make them full. On PrestaShop, I have too often seen the opposite: modules that open every facet URL to indexing, creating tens of thousands of pages with strictly identical content except one variable. Crawl budget evaporates, authority dilutes, and the parent page itself ends up suffering from cannibalization. The rule I apply: a page exists only if it brings something no other page on the site brings. Everything else goes to noindex or canonicalizes to the reference version.
Unique data, the only real fuel
What makes the difference between a programmatic page that ranks and one that falls is never the introductory text (often generated, often useless), it is the data it exposes. On a "part X compatible with model Y" page, the value is not in the wrapper paragraph: it is in the compatibility table, the exact dimensions, the availability, the price, the equivalent references. That data is, by construction, proprietary to the page, and that is exactly what Google rewards.
Hence a reversal of the writing reflex: instead of padding each page with a 300-word block spun from the template (the most visible marker of abusive scaled content), you concentrate the effort on the richness and accuracy of structured data, and you add text only where it genuinely informs the buyer. A page can be short and excellent if its data is unique and useful. This is also where structured data (Schema.org) earns its keep: it makes that data readable by search engines and by generative AI, which increasingly feed on it.
| Programmatic page type | Proprietary added value? | Verdict |
|---|---|---|
| Product / reference page with unique specs | Yes (proprietary technical data) | Index |
| "Compatibility X ↔ Y" page with a real table | Yes (useful cross-reference) | Index |
| Category/brand page with selection + content | Yes (intentional grouping) | Index |
| Low-demand facet (color × size × price) | No (permutation with no search) | Noindex / canonical |
| "City" page duplicated with no local data | No (recolored template) | Do not generate |
| Variant with 90% spun, identical text | No (disguised void) | Remove / merge |
The most expensive mistake
Confusing scale with volume. Generating 50,000 pages because the database allows it, dressing each in an interchangeable paragraph "to have content", and pushing everything to indexing. The post-March-2026 result is predictable: a scaled content signal, diluted authority, wasted crawl budget, and often a drop that takes the healthy pages down with it. The right reflex is the opposite: generate few but full, index even fewer, and keep only what answers real demand with real data. Five hundred pages you would defend one by one beat a fleet of 50,000 nobody searches for.
Launching a programmatic project without getting burned
The method I apply comes in four steps. First, demand research: you only generate the query patterns for which real volume and clear intent exist, not the full combinatorics. Next, the data-dense template: each page must expose proprietary, verifiable information, with text coming as a complement, never as filler. Then, indexation control: noindex and canonical rules decided upfront, a sitemap that lists only the pages to index, internal linking that establishes hierarchy (programmatic pages reinforce pillar pages, not the other way around).
Finally, progressive rollout and measurement: you open a subset, observe real indexing and engagement before widening. A programmatic set that receives neither clicks nor impressions after a few weeks is not a set to extend, it is a set to prune. This logic of structure and linking ties directly into the semantic cocoon: a generated page only has value when connected to an ecosystem that gives it context and authority. That is the whole point of my SEO expertise: turning scale into a structured asset, not a mass that worries the algorithm.
In the crucible: turning volume into value
Programmatic SEO is neither dead nor dangerous in itself. What is dead is the idea that you can turn void into traffic by multiplying it. The method remains one of the most powerful in technical SEO, provided you use it for what it is: a way to industrialize pages that had a reason to exist, each carried by data the others do not have. The lead, here, is the hollow permutation; the gold is unique data in service of a real query.
If you run an Odoo or PrestaShop catalog, a directory, or any site where data lends itself to scale, the challenge is to sort before producing and to structure before indexing. I tie demand research, architecture, linking and indexation control into a single profitability logic on my SEO expertise page, so your pages at scale become an asset that appreciates, not a risk that lies dormant.
Industrialize your pages without risking a penalty
I audit your programmatic potential (real demand, data density, indexation, internal linking) and hand you a plan: what to generate, what to set to noindex, and in what order to roll out.