Programmatic SEO for SaaS without building 5,000 pages nobody indexes

A client shipped 3,100 templated pages on a Friday. By the following Thursday, 212 were indexed. Six weeks later it was 190. They had spent about nine engineering weeks on it.

The postmortem was short: every page was the same 300 words with two variables swapped, and Google worked that out faster than anyone expected. This happens constantly, and the reason is that programmatic SEO gets discussed as a technical technique when the hard part is entirely editorial.

The test that decides everything

Before any of this is worth engineering time, one question: would a person who landed on page 847 find something there they could not get from page 848?

If the honest answer is no, you are building doorway pages and they will be treated as such. Not because of a penalty — the pages will simply not get indexed, and the ones that do will not rank.

The way to answer that question properly is to hand-build ten pages first. Write them yourself, no template. If the hand-built version is boring, the generated version will be worse, and you have spent two days instead of two months learning that.

We killed a project last year at exactly this stage. The client wanted a page for every combination of job title and industry — around 4,000 pages. We hand-wrote ten and every one of them was filler, because there was nothing genuinely different to say about a Head of Finance in logistics versus one in manufacturing at the level the product operated. The client was annoyed for about a week and grateful later.

Where the differentiation actually comes from

The page sets that work are the ones sitting on top of a real data asset. In SaaS there are usually four candidates, and most companies have at least one without realising.

Your integration catalogue is the most common. If you connect to 180 tools, each of those is a page with genuinely distinct content: what the integration does, which fields sync, what the setup takes, what breaks. The trap is publishing a logo and a Connect button, which is what most integration directories are.

Your template or example library is the second. Notion, Canva, and Airtable built enormous organic footprints this way. The content is the template itself, which is inherently unique.

Usage data you already collect is the third and the most underused. If your product processes invoices, you know the average approval time across your customer base, and you can publish benchmarks by industry and company size that nobody else can produce. These pages earn links as well as rankings.

Public data you structure better than anyone else is the fourth. Riskier, since someone else can copy the source, but the structuring and the interface are real work and real differentiation.

Building the template

Once the data exists, the template needs enough distinct content per instance that each page justifies its own URL. Our working rule is five genuinely unique elements minimum, and by unique I mean specific to that instance rather than a sentence with the variable inserted.

For an integration page that might be: a description of what the specific integration does at field level, a setup walkthrough with real screenshots, the specific limitations of that connector, a customer example using both products, and the API endpoints involved. That is five things that differ page to page.

Compare with the failure mode: a heading with the tool name, a paragraph reading “Connect {ToolName} with Acme to streamline your workflow,” a logo, and a form. That is one variable across four elements.

The template also needs somewhere for editorial to accumulate. The pages that end up performing best are usually ones where, six months in, someone added an FAQ or a troubleshooting note because support kept getting the same question. Build the field for that on day one or nobody will add it later.

Ship in cohorts and watch the index rate

This is the part that separates the projects that survive from the ones that get quietly deleted.

Do not publish all of it at once. Ship 200 to 300 pages. Put them in their own sitemap file so you can see index coverage for that cohort in isolation rather than mixed into your site total. Wait four to six weeks.

Then look at the index rate. Above 70% is healthy and you can expand. Between 40% and 70% means the template is thin and needs more per-page substance before you build more. Below 40% means stop and rethink the whole pattern.

The segmented sitemap trick matters more than it sounds. On a site with 800 existing pages, adding 3,000 and watching one aggregate index number tells you nothing. Split by cohort and the diagnosis is obvious in a glance.

Internal linking is the other half of this. Programmatic pages are orphaned by default — they exist in the sitemap and nowhere else, and sitemap presence is a weak crawl signal. You need hub pages that link to them in a browsable structure, contextual links from your editorial content, and ideally links from the product itself. On one client, adding a browsable directory hub with pagination took the index rate on an existing set from 44% to 81% in seven weeks without changing a single page’s content.

Pruning is part of the build, not a cleanup

Roughly a third of any large page set will fail to earn impressions. Left in place they dilute crawl budget and drag the average quality of the set, which appears to affect how the rest is treated.

Build the monitoring on day one: any page with fewer than N impressions after 90 days gets flagged for review, then merged, improved, or noindexed. Automate the flagging, keep a human on the decision.

We run this quarterly. On a 900-page integration set, the first prune removed 210 pages and organic traffic to the remaining set went up 18% over the following two months. Correlation, and I would not claim to have proven causation, but we have seen the same pattern on four other accounts.

The engineering side, briefly

Static generation or incremental static regeneration, not client-side rendering. A programmatic set rendered in the browser is the fastest way I know to build thousands of pages Google sees as empty.

Watch build times. A 4,000-page Next.js site with unoptimised data fetching will take 40 minutes to build and your team will start avoiding deploys. Cache aggressively at the data layer.

And put the data behind a real schema with validation. Half the quality problems in these projects are missing or malformed fields producing pages that say “Connect with Acme” because a name was null.

When not to do this at all

If your product has no natural data asset, if your category has under a few thousand relevant monthly searches in total, or if you have no engineering capacity to maintain the set after launch, this is the wrong project. A programmatic set is a permanent maintenance commitment, not a launch.

The good version of this is one of the highest-leverage things a SaaS company can build. The bad version is nine engineering weeks and 212 indexed pages.