Programmatic SEO: A Case Study From Our Own 1,100-Page Platform

Programmatic SEO generates a set of pages from one template joined to one dataset. It works when the dataset is the thing the reader came for. It fails, publicly and permanently, when the template is the only thing you have.

That sentence is the whole decision, and most of the arguing about programmatic SEO is really arguing about the dataset. A tool directory with a real record per tool, a route planner with real timetables, a salary site with real survey data: those page sets earn their place because the page carries something the reader cannot assemble from the template. A page set built by pouring the same three paragraphs over a list of city names carries nothing, and Google has a policy with its name on it.

This article is the mechanics plus one worked case. The case is our own platform, which is the only build whose workings we can show you in full.

What programmatic SEO actually is

Three parts, and each one fails differently.

A dataset with real variance per row. Not a list of nouns. A record per instance carrying facts that differ: specifications, prices, availability, compatibility, dates. If two rows produce two pages a reader would consider interchangeable, the dataset is not ready and the page set should not exist.

A template that renders the record, not around it. The template supplies the heading structure, the schema, the breadcrumb and the internal links. The record supplies the content. When a template contains three paragraphs of general prose and one variable, the ratio is inverted and every page in the set is thin by construction.

An internal link graph the template emits automatically. This is the part hand-built sites never get right and generated sites get for free. Every page links its parent, its siblings, and the specific comparisons that make sense for its record. Done properly, the link graph is the main reason a page set outperforms the same content published as isolated pages.

Where the policy line actually sits

Google Search Central's spam policies define scaled content abuse as "many pages are generated for the primary purpose of manipulating search rankings and not helping users", and say it applies "no matter how it's created". Read the two clauses together: the policy is about purpose and value per page, and it deliberately refuses to make automation the test. It also lists doorway abuse separately, as pages "created to rank for specific, similar search queries" that lead users to "intermediate pages that are not as useful as the final destination".

So the line is not templated versus hand-written. It is whether the page a searcher lands on is the destination or a turnstile. That is a question you can answer per page, before you generate ten thousand of them.

The worked case: vibecoding.app, our own platform

Everything in this section is about a platform Silkdrive owns. vibecoding.app is a 1,100-plus page AI-coding tools directory and content platform, built and operated by Patric Sawada. It is not a client engagement, and we are showing it precisely because we can open the build.

What was templated

Three page types carry the programmatic load.

Tool pages. One page per tool, generated from a per-tool record: what the tool does, what it costs, what it integrates with, what it is weak at. The record is the page. Where the record is incomplete the page says so rather than filling the gap with prose.

Comparisons. One page per meaningful pair, generated from the two records side by side. This is the page type that most obviously distinguishes a dataset from a template: a comparison is only worth reading when the two records genuinely differ, so the generation rule is a property of the data, not a cartesian product of every tool against every other tool.

Alternatives. One page per tool, listing the substitutes a reader would actually consider, derived from the same records. The internal link graph this produces is dense and, unlike an editor's cross-links, it stays correct when a record changes.

What keeps them from going thin

Gates that run in the build, so a defective page cannot ship and wait to be noticed.

A page fails the build when required fields are missing from its record, when an internal link points at a route the site does not generate, when a category is not registered in the taxonomy, or when a referenced image does not exist on disk. Those are unglamorous checks, and they are the difference between a generated page set that ages and one that rots. Decay in programmatic SEO is a data problem before it is a content problem: a stale price, a dead integration, a tool that shut down. The check belongs where the data is assembled, not on a quarterly review calendar that nobody keeps.

The content pipeline is agent-operated: research step, draft step, human review before merge, gates underneath. The agents do the volume. They do not get the last word, on that platform or on this one.

What the rank data did

DataForSEO Labs, US index, March to August 2026:

Metric	March 2026	August 2026
Ranked keywords, US top 100	527	1,345
Top-10 positions	about 9	69
Estimated monthly traffic value	about $18,700	about $53,800
Estimated organic traffic (ETV)	about 2,018	about 5,233

Read those with the caveats attached, because they matter more than the numbers.

They are third-party estimates. DataForSEO Labs models rankings and infers the traffic and paid-equivalent value those rankings imply. Traffic value is what the same clicks would cost to buy, which is a useful scale marker and is not revenue, not spend avoided, and not money that changed hands. Estimated organic traffic is a model output, not a session count.

They are not our analytics. No GA4 or Search Console figure for vibecoding.app appears in this article, because none is published yet. When they are, they will be added to the case entry rather than quietly replacing the estimates here.

And they are association, not proof. One site, one window, no holdout, and other things shipped in the same five months. The honest statement is that a programmatic build ran and the third-party footprint grew alongside it. Anyone who offers you a causal claim from a single rank series is selling something.

What does not transfer

Two things travel badly from a case like this, and both are worth naming.

Thin doorway pages. The temptation, once a template works, is to fan it out across every query variant the keyword tool returns. That is the doorway pattern the spam policy describes, and it converts a working page set into a liability. The generation rule has to be a property of the data. If the data does not distinguish two pages, do not generate the second one.

Unmoderated AI text. Generating a thousand pages of model output and shipping them is the failure mode the scaled-content policy is written for, and it is the one readers detect fastest. Model drafting inside a pipeline with review and gates is a different activity from model output as the product, even though the tooling looks identical from the outside.

There is a third, quieter one: our platform is a directory, and a directory is the easiest case programmatic SEO has. The dataset already existed as a reason for the site to exist. Most companies asking about programmatic SEO do not have that dataset and would need to build one first, which is a data project with an SEO benefit rather than an SEO project.

When programmatic SEO is the wrong call

Programmatic SEO is the wrong call when the variable you are templating does not change the answer. If the only difference between two generated pages is a swapped noun, you have produced one page in many costumes, and the scaled-content-abuse policy is aimed squarely at it. It is also the wrong call at low query counts: where an intent is worth real money and exists in a handful of variants, one deeply researched page beats two hundred shallow ones. Most cross-border service work is that shape, fewer than fifty commercially meaningful queries, each needing an argument rather than a row from a table, which is why this site is hand-written and the directory is not. Programmatic earns its place when the dataset itself is what the reader came for and there are hundreds of genuinely distinct instances of it.

Where this fits

A generated page set is one instrument. It sits inside the wider question of how a site gets found now that answers arrive before clicks do, which is the subject of AI SEO, GEO and AEO as a service and of AEO and GEO for European B2B as a playbook. The entity graph, the schema and the machine-readable index that make a page citable by an answer engine are the same infrastructure that makes a large generated page set legible in the first place.

For the multi-market version of the architecture question, international SEO strategy covers per-market keyword research and hreflang, and how search works in Japan is the hub for this cluster: it is the market where a templated page set most often needs to be rebuilt rather than translated.

Sources

• Rank and traffic figures: DataForSEO Labs historical_rank_overview, US index, pulled 24 August 2026 for vibecoding.app. Third-party estimates of rankings and modelled traffic value, not first-party analytics.
• On scaled content and doorways: Google Search Central, Spam policies for Google web search, opened 24 August 2026.
• On the platform: vibecoding.app is built and operated by Patric Sawada and is a Silkdrive project. Page count and pipeline description are repo-verifiable rather than externally cited.

Claim provenance for this article is recorded in content/blog/research/programmatic-seo-case-study-claims.md.

Related Resources

• AI SEO, GEO and AEO, the service page this article feeds
• AEO and GEO for European B2B, the playbook for being cited by answer engines
• How Search Works in Japan, the cluster hub
• International SEO Strategy, per-market keyword research and hreflang
• International SEO, Silkdrive's multi-market search engagement