Programmatic SEO for indie hackers: a teardown of our own

Programmatic SEO is one page template multiplied by one real dataset. We run 46 such pages on Favors.dev, and for six straight weeks they out-performed all 45 of our hand-written blog posts combined. This is the teardown, with the actual Search Console readings, including the part where we shipped an article that competed with our own templated pages and lost badly.

Almost everything written about this topic is a vendor explainer illustrated with Zillow, Nomad List and Zapier integration pages. Those are useful as proof the technique works and useless as instructions, because none of them are a company of one with no traffic and no links. So here is the version at our scale: what we built, what it did week by week, what it cost us, and what I would do differently.

What is programmatic SEO?

Programmatic SEO is the practice of generating a set of pages from a single template and a structured dataset, so that each page targets one specific long-tail query. One template, many rows, one page per row. It is often shortened to pSEO, and it is a production method rather than a separate ranking strategy: the pages still have to earn their rankings the ordinary way, by being the best available answer to the question they target.

The distinction that matters is between a dataset and a word list. If your rows differ only by a noun you drop into the same sentences, you are generating filler. If your rows differ by facts a reader would actually want (what it costs, what it requires, whether it is worth the afternoon), you are publishing a reference work that happens to have been assembled by a script.

What happened when we shipped 46 templated pages

Our property went from 511 impressions to 2,050 in six weeks, and for most of that period the templated pages, not the blog, were the reason. The dataset behind them is a verified index of places a founder can submit a startup: 46 directories, each with its submission route, whether it costs anything, whether it needs an account, its domain authority, and a date stamp for when we last confirmed it was alive.

Every row below is a real reading from our own Google Search Console property, pulled on the date shown over the preceding 28 days.

Three things in that table are worth more than the headline growth.

The child pages beat the hub, consistently. Our index page for the whole set has spent every reading around position 27 to 35, while the individual directory pages sit between positions 3 and 8. The specific page wins the specific query, and the overview page competes against every other overview page on the internet. That is the entire argument for the technique in one comparison, and it held across seven consecutive readings.

Impressions arrive long before clicks. Our clicks went 9, 11, 11, 10, 11, 14, 15 while impressions quadrupled. Long-tail pages get seen far more often than they get clicked, and if you judge the experiment on clicks in month one you will kill something that is working. Watch the number of ranking pages and the impression trend first.

Average position gets worse as this succeeds. Ours drifted from 12.3 to 18.7 while impressions quadrupled. Every new page enters the index at a deep position and drags the site-wide average with it. That number is close to meaningless during a pSEO rollout, and watching it will convince you that you are failing while you are winning.

One honest correction to the story, because the most recent reading complicates it: in the window to August 15 our blog jumped to 844 impressions across 32 ranking posts, 41% of the whole property. The editorial content did eventually compound, and it compounded harder per page than the templated set. The right conclusion is not that programmatic beats writing. It is that programmatic buys you a surface that ranks while your writing is still maturing.

What flopped, and what it cost us

We cannibalized ourselves. Three weeks after the templated pages were live, I published an editorial post targeting the same directory-listing intent the hub already served. In the next reading, the blog post was catching its target query at roughly position 76 while the hub was doing 137 impressions at position 27 on the same theme, with 40-odd child pages ranking between 3 and 8 underneath it. We had entered two runners in one race, and the slower one took the traffic that would otherwise have consolidated.

The fix is a decision, not an optimization: pick which surface owns the intent, then rewrite the other one to funnel into it rather than duplicate it. In our case the hub owns it, because it is structurally better at that job, and the post exists to explain the strategy and hand the reader off. If you take one thing from this section, take that ordering. Decide before you publish, not after you notice the split in the data.

The second thing that did not work was assuming impressions would convert on their own. Across the readings, most of our clicks landed on app profile pages, the founder directory and the homepage rather than on either the blog or the directory pages. High-impression informational pages are the top of a path, and if you do not build the next step into the template, the visit ends there. Every one of our directory pages now carries a route into the apps directory for exactly that reason.

How do you find a pSEO-shaped dataset?

Look at the data you already maintain to run your product, and ask which part of it a stranger would want. Founders reach for keyword tools here and end up generating pages about queries they have no claim to. The dataset that works is almost always something you were already collecting because your product needs it, which is why competitors cannot copy it in an afternoon.

Ours came from an internal table. We were already tracking submission directories to help members get listed, including which ones needed an account and which ones had quietly died. That table was operations infrastructure for about a year before anyone noticed it was also the best public answer to a question thousands of founders type.

Run any candidate through one question before you build anything: if a reader landed on a single page from this set, having never heard of you, would they be glad they did? If the honest answer is no, the set will not rank no matter how many rows it has, and the fifty hours you spend generating it are fifty hours you did not spend on the two pages that would have.

Why does most programmatic SEO get filtered?

Because most of it carries no value per page. Google's spam policies name scaled content abuse directly: generating many pages primarily to manipulate rankings rather than to help people, regardless of whether automation, a model or a person produced them. The method is not the violation. The emptiness is. Their companion guidance on creating helpful, reliable, people-first content is the standard each individual page has to clear, and it does not get easier because there are a thousand of them.

In practice, four tests separate a reference work from filler. We apply them per row, not per set.

The test that saved us was the third one. Every directory in our set carries a last-verified date, and a scheduled job re-checks the rows and removes the dead ones. Roundups rot silently: we once found a recommendation on our own blog pointing at a product whose domain had quietly become somebody's personal site, while every other directory on the internet still listed it as active. Freshness is not a ranking trick here. It is the only reason a reader should prefer your page to the source.

How do you actually build it?

A pSEO surface needs three pieces: a data source, one dynamic route, and a build step that turns every row into a static page. Ours runs on Next.js and Supabase, and the whole thing is a single route file of a few hundred lines.

The data source is a Postgres view exposing only verified, active rows, so an unverified directory cannot leak into the public index by accident. The route is /startup-launch-directories/[slug], and generateStaticParams enumerates every slug at build time so all 46 pages are prerendered rather than assembled per request. A 24-hour revalidate window means an edit to the dataset appears without a deploy. Each page emits its own metadata, breadcrumb structured data and FAQ structured data built from that row's own content.

The part worth copying is where the per-page prose comes from. It is not a template with holes. Each row carries a stored block of content generated once from the verified facts we hold about that directory (what it is, who it suits, how submission works, whether it is worth an afternoon, and half a dozen grounded questions), then re-checked when the row is re-verified. That is what makes the pages differ from each other in substance rather than in nouns, and it is the single largest determinant of whether a set like this survives.

Budget it honestly: a weekend for the route and the template, considerably longer for the dataset. The engineering is the easy half. We shipped 46 pages, and the constraint was never the code.

How should templated pages and posts link together?

Treat them as one system with two jobs: the templated pages catch the specific queries, the editorial pages explain and persuade, and each links to the other in exactly one direction per intent. Our rules, learned the expensive way:

• One surface owns each intent. If a post and a templated page target the same query, the post gets rewritten to funnel into the page. No exceptions, because the alternative is the split we measured.
• Every templated page links up and sideways. Up to the hub, sideways to two or three genuinely related rows. This is what gets deep pages crawled without a link-building campaign.
• Posts link down to specific rows, not just the hub. A named example in the middle of a paragraph passes more useful signal than a nav link, and it reads better.
• Every page has a next step. Informational traffic that lands and leaves is a vanity metric. The templated page should offer the obvious next action for somebody who just learned the thing.

If you want to see the surface this whole post is about, it is public: the startup launch directories atlas is the same 46 pages the numbers above describe. The strategy behind it is in our guide to startup launch directories, the link-value case is in directory backlinks for SaaS SEO, and the weekly rhythm that keeps any of it maintained is in SEO for solo founders. For where programmatic fits in the wider zero-budget picture, start at SaaS marketing on no budget.

Frequently asked questions