Search "programmatic SEO case study" and read the first ten results. Every single one is a success story. Sixty-seven signups to 2,100. Zero to 100,000 sessions. A niche site built to 4,000 pages. The genre has exactly one plot.
That is not because programmatic SEO always works. It is because nobody publishes the other outcome. So we did.
Over six months we ran a controlled programmatic build on a client site: 162 pages, three different template types, published in batches, tracked in Google Search Console and in server logs, with a deliberate pruning intervention at day 120 and an AI-citation check at the end. We measured not just what the new pages earned but what they cost the pages that were already working.
The headline: 11 of the 162 pages - under 7 percent - produced about three quarters of the program's organic clicks. The other 151 ranged from harmless to a genuine tax on the rest of the site. And when we deleted most of them, total traffic from the program went up 29 percent.
This is the whole data set, including the parts that make us look bad. If you are about to green-light a programmatic build, or you are already six months into one and quietly wondering why the dashboard does not match the deck, this is the piece we wish had existed when we started. The strategic framework for doing this properly lives in our programmatic SEO playbook; this article is the evidence underneath it.
What We Actually Built
The site is a mid-market B2B services business in India with an established domain, roughly 40 core commercial pages, and a small editorial blog of nine hand-written posts. It had never run a programmatic program. That made it a clean test subject: enough authority that pages could plausibly get indexed, not so much authority that anything would rank regardless of quality.
We built 162 pages across three template types, deliberately chosen to be different in kind rather than variations of one idea:
| Template | Pattern | Pages | Rationale |
|---|---|---|---|
| A | [Service] in [City] | 72 | The classic location permutation. 8 services x 9 cities. |
| B | [Option A] vs [Option B] | 45 | Bottom-of-funnel comparison pages within the category. |
| C | [Use case] for [Industry] | 45 | Mid-funnel application pages, the template most often pitched to us. |
Each page carried the same quality floor: a genuine first-party data point unique to that permutation, a minimum of 600 words of non-boilerplate body copy, hand-written meta, and internal links up to the relevant service page and sideways to two sibling permutations. This was not a thin-page experiment. We were testing whether decent templated pages work, not whether garbage does. Everyone already knows the answer to the second question.
Publishing ran in three batches over five weeks starting 6 January 2026, so we could watch indexing behaviour change as the volume grew rather than dumping everything at once.
The Effort, Honestly Accounted
We tracked hours, because hours are the part of these programs that gets hand-waved:
| Work | Hours | Share |
|---|---|---|
| Data preparation and validation | 34 | 32% |
| Template build and internal-link wiring | 22 | 21% |
| Quality control and hand-editing | 51 | 48% |
| Total | 107 |
That works out to roughly 40 minutes per published page. Note where the time went. Nearly half of it went into QA - the exact line item that gets cut when a programmatic program is sold on the promise of automation. Generating pages has been cheap for years. Making pages good enough that a search engine bothers to keep them is not cheap, and that cost scales close to linearly with page count regardless of what tooling you point at it.
The Method, So You Can Judge the Findings
Four measurement layers, all running from before publication so we had a real baseline:
- Google Search Console, at page level, exported weekly. We recorded indexing status, impressions, clicks and average position for every one of the 162 URLs individually.
- Server log analysis, so we could see what Googlebot was actually doing rather than infer it. This is the layer most teams skip, and it turned out to hold the most interesting finding. If you have never done it, our guide to log file analysis covers the setup.
- A control cohort: the site's 40 core commercial pages, tracked on the same cadence, so we could detect collateral effects rather than only measuring the new pages in isolation.
- An AI-citation battery: 60 category buyer questions run across ChatGPT, Perplexity and Gemini at baseline and again at day 180, using the same method as our 50-brand AI visibility audit.
Two honest constraints. This is one site in one category, so it is a case study and not a controlled trial - a point I come back to at the end. And we did not run a no-publish control site, which means seasonality and unrelated algorithm movement are confounders we can reason about but cannot eliminate.
Day 90: The Attrition Curve
Here is the raw result at the 90-day mark, before we intervened.
| Milestone | Template A (72) | Template B (45) | Template C (45) | Total (162) |
|---|---|---|---|---|
| Indexed | 51 | 41 | 26 | 118 |
| Ever earned an impression | 44 | 39 | 19 | 102 |
| 1+ click in trailing 30 days | 9 | 22 | 4 | 35 |
| 10+ clicks in trailing 30 days | 2 | 9 | 0 | 11 |
Read the last row again. Eleven pages out of 162 cleared the low bar of ten clicks a month. The program was producing 780 organic clicks a month at that point, and 611 of them - 78 percent - came from Template B alone.
This curve is the most useful artefact of the whole experiment, and it is the number we now put in front of clients before they commit. Almost every programmatic planning conversation implicitly assumes a hit rate close to 100 percent: build 500 pages, get 500 pages of long-tail traffic. Plan against a 7 percent rate instead and you make completely different decisions. You build a smaller set. You spend the saved hours on editing. And you build the pruning step in from day one rather than discovering you need one at month six.
Finding 1: Template Type Predicted Almost Everything
The variance between templates was far larger than the variance within them. Template B, the bottom-of-funnel comparison pages, got indexed at 91 percent and carried 78 percent of the clicks from 28 percent of the pages. Template C, the use-case pages, got indexed at 58 percent and produced under 3 percent of clicks.
The explanation is not mysterious once you see the numbers. A comparison query has a real person behind every permutation - someone in active evaluation mode, deciding between two named things, who wants exactly the page you built. Location permutations have real demand too, but it is wildly uneven: three of the nine cities carried nearly all of Template A's traffic, and the six smaller cities produced pages that were structurally identical and demonstrably pointless.
Template C was the failure, and it is worth dwelling on because it is the template most often pitched to us. "Inventory management for pharmaceutical distributors" reads like a query. It looks like a query in a spreadsheet. Almost nobody types it. We had generated 45 word combinations and convinced ourselves they were 45 demand pockets. They were not, and Google worked that out faster than we did.
The pre-build test we now use: take 10 random permutations from the proposed data set, search each one manually, and look at what comes back. If the SERP is populated with genuinely intent-matched results, the demand is real. If it is a scattering of loosely related pages and forum threads, you have found a word combination, not a query. Template C would have failed this test in twenty minutes. We did not run it.
Finding 2: The Crawl Tax Nobody Puts in the Deck
This is the finding we did not expect, and it only showed up because we were reading server logs rather than trusting Search Console alone.
Before publication, Googlebot was hitting the site's 40 core commercial pages roughly 410 times a day. In weeks three through eight after the batches went live, that fell to about 270 a day - a 34 percent drop - as the crawler worked through 162 new URLs. Impressions on those same core pages dipped about 9 percent over the same window.
Nothing about the core pages had changed. We had not touched them. They simply got less attention while the crawler evaluated the new inventory, and their performance softened accordingly.
Both metrics recovered. But for roughly two months, a program designed to add traffic was quietly taxing the pages that actually produced revenue. If the client had judged the experiment at week six, they would have concluded that programmatic SEO had damaged their site - and they would not have been entirely wrong. This is the same crawl-allocation dynamic that makes faceted navigation a crawl budget problem on ecommerce sites, and it is exactly the kind of movement that sends teams down the wrong path when they diagnose a Search Console traffic drop without a log-level view.
Two practical implications. First, do not publish a programmatic batch into a quarter where the core pages are carrying a revenue target you cannot miss. Second, if your site is not already crawled generously, adding hundreds of URLs will not increase your crawl allocation - it will divide the allocation you already have across more pages.
Finding 3: Pruning Increased Total Traffic
At day 120 we ran the intervention. The rule was mechanical, agreed in advance so we could not rationalise our way out of it: any page with zero clicks and fewer than five impressions over the previous 60 days gets noindexed.
That removed 96 of 162 pages. Nearly sixty percent of everything we had built, deleted from the index four months after publishing it.
| Metric | Day 90 (162 live) | Day 180 (66 live) | Change |
|---|---|---|---|
| Pages indexed | 118 | 58 | -51% |
| Pages with 10+ clicks / month | 11 | 14 | +27% |
| Programmatic clicks / month | 780 | 1,010 | +29% |
| Googlebot hits to core pages / day | ~270 | ~440 | +63% |
| Core-page impressions vs baseline | -9% | +6% | recovered |
Fewer pages. More traffic. A 29 percent increase in clicks from 41 percent of the page count.
Some of that is natural maturation - pages get better with age, and part of the gain would have arrived without pruning. But the crawl recovery is not ambiguous, and neither is the fact that three additional pages crossed the ten-clicks-a-month line after we removed their competition. Several of the pruned pages had been splitting impressions with their better siblings, which is keyword cannibalization in its purest and most self-inflicted form: we built the competitors ourselves, on purpose, and gave them identical templates.
The lesson generalises well beyond programmatic work. Pruning is not damage control after a failed program. It is a scheduled operation inside a working one, the same way a content decay audit is scheduled maintenance on a healthy blog rather than an emergency response. Build the prune date into the plan before you publish the first page, and put the threshold in writing while you are still unattached to the pages.
Finding 4: The Pages Ranked and Were Never Cited
We ran the AI-citation battery at day 180: 60 category buyer questions across ChatGPT, Perplexity and Gemini, logging every response for whether the site was named or cited.
The 162 programmatic pages were cited twice. Both times by Perplexity, both times a Template B comparison page.
The same site's nine hand-written editorial posts were cited 31 times over the same prompt set.
Nine articles out-cited 162 pages by a factor of fifteen. That is not a rounding error, it is a different mechanism. Templated pages are optimised to match a query pattern. AI engines are looking for a self-contained passage worth quoting, corroborated elsewhere, attached to something that reads like a source rather than an inventory row. A page assembled from a data table can rank perfectly well and still offer nothing an assistant wants to lift, which is the same disconnect we mapped in why brands rank on Google but stay invisible on ChatGPT, and the reason the formats that LLMs actually cite look nothing like a template.
This finding is the one that has most changed how we scope these programs. If the objective is long-tail capture on commercial queries, programmatic pages remain a legitimate instrument. If the objective is authority, share of voice inside AI answers, or being the source an assistant names when someone asks a category question, templated pages are close to the wrong tool - and the hours would return far more in original research or genuine editorial depth. That is a real allocation decision, not a philosophical one, and it is the core argument behind how we approach answer engine optimisation and AI SEO.
The Business Result, Which Is the Only One That Matters
Six months, 107 hours, 162 pages, one prune. What did the client get?
- 1,010 organic clicks a month from 66 surviving pages, still compounding at the point of writing.
- Seven qualified enquiries attributable to programmatic landing pages over the six months. Six of the seven came from Template B.
- A core-page recovery that finished 6 percent above the pre-experiment baseline, so no lasting harm.
- A validated template, which is arguably the most valuable output: they now know that comparison pages work in their category and that use-case pages do not, and the next 45 pages can be built entirely inside the pattern that earned its place.
Was it worth 107 hours? Marginally yes, and mostly because of that last point. If they had built 500 use-case pages instead - which is roughly what a volume-first pitch would have proposed - it would have been an expensive, slow-motion index-bloat problem with a crawl tax attached. The experiment's real return was in what it stopped them from building. And note which metric answered the question: enquiries, not sessions, which is the same argument for why blog traffic on its own means very little.
The Six Rules We Now Apply Before Building One of These
Everything above compressed into the checklist we actually use in scoping calls.
- Run the ten-permutation SERP test first. Pull ten random rows from the proposed data set, search each one by hand, and look at the results. Real intent-matched SERPs mean real demand. Loose, scattered results mean you have found word combinations. This takes twenty minutes and would have saved us 45 pages.
- Budget against a 7 percent hit rate, not 100 percent. Assume that a small minority of pages will carry the program. Plan the page count, the hours and the expected return on that basis, and you will build a smaller, better set.
- Start with the bottom of the funnel. Comparison and alternative pages beat mid-funnel use-case pages by a wide margin in this test, and they beat them again on conversion. Validate the template on 40 pages before scaling to 400.
- Write the prune rule before you publish. A specific threshold, a specific date, agreed while nobody is attached to the pages. Ours was zero clicks and under five impressions in 60 days, evaluated at day 120. It removed 96 pages and increased traffic.
- Baseline your logs and your core pages first. You cannot detect the crawl tax without a before. And if your existing pages are not already crawled generously, adding hundreds of URLs will spread a fixed allocation thinner rather than earning you a bigger one.
- Do not use programmatic pages to chase AI visibility. They rank; they do not get cited. If citations are the goal, put the hours into original research and editorial depth instead - topical authority is built by depth, and a blog rebuilt around real questions will out-cite a page factory every time.
Where to Start
If you are considering a programmatic build, the sequence is: run the ten-permutation test, pick the bottom-of-funnel template, build 40 pages rather than 400, baseline your logs, and put the prune date in the plan. If you already have a program in the ground and the dashboard is not matching the promise, start with a page-level export from Search Console and sort by clicks. If the shape of that list looks like our attrition curve, you do not have a traffic problem - you have a pruning problem, and the fix is faster and cheaper than a rebuild.
The strategic framework for all of this sits in our programmatic SEO playbook, and the diagnostic work - index bloat, crawl allocation, orphan pages and internal link architecture - is what our technical SEO team does on engagements like this one.
If you would rather have someone else run the numbers on your existing page set before you commit another quarter to it, that is the first thing an SEO audit is for. And if you are scoping a large build across thousands of URLs, enterprise SEO is where the crawl-allocation maths starts to dominate every other consideration.
We will publish the twelve-month follow-up either way. Including if the pages we pruned turn out to have been the wrong ones.

Aditya Kathotia
Founder & CEO
CEO of Nico Digital and founder of Digital Polo, Aditya Kathotia is a trailblazer in digital marketing. He's powered 500+ brands through transformative strategies, enabling clients worldwide to grow revenue exponentially. Aditya's work has been featured on Entrepreneur, Economic Times, Hubspot, Business.com, Clutch, and more. Join Aditya Kathotia's orbit on LinkedIn to gain exclusive access to his treasure trove of niche-specific marketing secrets and insights.