Programmatic SEO results: benchmarks from real case studies
Real programmatic SEO results from public case studies: indexation rates, click timelines, and how to measure each template in Search Console.
Most published programmatic SEO results are a single traffic screenshot, taken at the best moment and with no denominator. That doesn’t tell you what to expect in month three, how many pages Google will actually index, or when to stop adding URLs. This post collects the few public case studies with real numbers, sets rough benchmarks from them, and shows how to measure results by template in Search Console so you can decide what to improve, merge or delete.
One warning first. Almost every number below is self-reported, usually by a vendor. No independent study of pSEO results exists. Treat the figures as ranges to compare against, not targets.
Programmatic SEO results: what the public case studies show
Three cases publish enough data to be useful:
- theStacc, 512 pages over 18 months. In its own case study, 87% of pages were indexed within 90 days and monthly clicks reached 11,840 by month 18.
- Linkscope, about 8,000 pages. According to SEOSkit’s write-up, 5,210 pages (about 65%) were indexed by early June 2026. The site earned 5,120 clicks from 2.11M impressions between May 12 and June 30, at 0.2% CTR and an average position of 11.4.
- A developer postmortem, about 8,000 pages. The author submitted 8,653 URLs and got 0 indexed. They judged about 89% of the pages to be thin near-duplicates.
Avoid the “programmatic SEO examples” lists that quote traffic for Zapier or Wise. Those figures are third-party estimates, and they disagree badly. Ahrefs puts Zapier’s app directory at about 306K visits a month, while AI Growth Agent says 8.65M. That is a 28x gap, so neither number tells you what the site gets.
Does programmatic SEO still work?
Yes, when each page carries data the next page doesn’t have. The failures in the public record are all thin variants. The postmortem above got 0 of 8,000 pages indexed. Miquel Palet told Search Engine Journal that his roughly 50,000 AI-generated long-tail pages got early clicks and millions of impressions. Then “Pages started getting deindexed. Traffic plummeted overnight.”
Google’s spam policies describe the pattern directly. Doorway abuse includes “pages targeted at specific regions or cities that funnel users to one page” and “substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy.” I covered the 2026 updates in more detail in Is programmatic SEO dead?.
So does programmatic SEO work? The template matters less than the rows behind it. theStacc won’t generate a page from a row with fewer than 3 unique data points. That is a reasonable floor to copy.
How long does programmatic SEO take to show results?
The first 90 days are slow. theStacc’s monthly clicks grew like this:
| Months | Pages live | Monthly clicks |
|---|---|---|
| 1 to 3 | 62 → 180 | 240 → 1,140 |
| 4 to 6 | 180 → 320 | 1,140 → 3,420 |
| 7 to 9 | 320 → 410 | 3,420 → 6,890 |
| 10 to 12 | 410 → 460 | 6,890 → 9,210 |
| 13 to 15 | 460 → 488 | 9,210 → 10,640 |
| 16 to 18 | 488 → 512 | 10,640 → 11,840 |
The growth started in months 4 to 6, and it had slowed by month 13.
Linkscope’s timeline was stranger. The site was built from October 2025. Search Console first picked it up in late April 2026, and thousands of pages were indexed within days in mid-May. By the end of June it was getting about 95K impressions and up to about 180 clicks a day. Ahrefs estimated zero traffic for the first seven months. Its estimate then jumped from 19K to 7K to 34,337 within two months, so use Search Console for your numbers and not a third-party tool.
Fixes are slow too. Google’s core updates page says “it could take several months” for its systems to recognise quality improvements. If you plan for 4 to 9 months before clicks build up, you are planning realistically.
theStacc lists some early signs that a page is working, visible around month 4:
- positions 15 to 30 for at least 2 keywords
- CTR above 3%
- GA4 bounce rate below 60%
What percentage of programmatic pages should get indexed?
Google sets no target. Its page indexing report help says “you shouldn’t expect full coverage.” Only the canonical versions of your important pages need to be in the index.
The public range is wide:
| Source | Indexed |
|---|---|
| DEV postmortem | 0% |
| LinkedIn experiment (unverified) | about 18 to 21% |
| Vizup “mini case” (likely composite) | 31% |
| Linkscope | about 65% |
| theStacc | 87% |
The average for the whole site hides a lot. theStacc broke indexation down by template. Glossary pages reached 94%, location pages 89%, and integration combinations 73%. 35 integration pages never got indexed. The pages that stayed out had thin data, sat 4 or more clicks deep, or targeted near-zero search volume.
Vizup gives rules of thumb but cites no dataset for them:
- A first batch with 70% or more indexed, plus impressions within 30 days, supports scaling.
- Below 50%, stop scaling and prune.
- Below 40%, fix quality before you add any URLs.
I’d use those as starting points and judge each template on its own numbers.
Expect a few pages to earn most of the clicks
At month 18, theStacc’s clicks were spread like this:
| Cohort | Pages | Share of clicks | Median clicks per page per month |
|---|---|---|---|
| Top 10% | 51 | 42% | 97 |
| Next 20% | 102 | 31% | 36 |
| Next 40% | 205 | 22% | 13 |
| Bottom 30% | 154 | 5% | 4 |
The bottom 30% of pages earned 5% of clicks. That is normal, and you shouldn’t prune by it alone. A page with 4 clicks a month may still be the best answer for a rare query. Compare cohorts within a template, and look for templates where most pages sit in the bottom band.
How do I track performance per template in Google Search Console?
The Search Console UI caps exports at 1,000 rows, so with thousands of URLs you need to split the data before you can read it. There are three tools for this, and I’d use all three. The measurement hub has more on the setup.
URL-prefix properties per template
A URL-prefix property can be limited to a path such as https://example.com/integrations/. It then reports only URLs under that path. Google suggests one property per subsection plus a broader property that contains them all.
A few rules:
- The prefix must match exactly, including protocol, subdomain and trailing slash.
- An account can hold up to 1,000 properties.
- Data starts collecting as soon as the property is added.
That last point means you should create these properties on launch day, before the pages go live if you can.
One sitemap per template
The page indexing report can be filtered by a specific sitemap URL. If you split sitemaps by template, you get indexation per template with no extra tooling. theStacc goes further, with sitemaps of 50 to 100 URLs each, split by template family. It also runs URL Inspection on 10 pages every Friday.
There are two caveats. The example lists in the report are capped at 1,000 URLs and aren’t guaranteed to be complete. The “crawled, currently not indexed” status is also ambiguous. Google says those pages may be indexed later. Indexing Insight found that 70 to 80% of such URLs from sitemaps had been indexed before, so the status can mean a page was removed from the index. See the indexing hub for more.
Bulk Data Export to BigQuery
The API caps you at 50,000 rows per day per site per search type. Bulk Data Export has no row cap: it dumps all performance data daily, except anonymized queries. Only property owners can set it up, and exports start within 48 hours. There is no historical backfill, which is another reason to set it up on launch day.
You can then group searchdata_url_impression by URL pattern. Average position follows Google’s formula:
SELECT
REGEXP_EXTRACT(url, r'^https://example\.com/([^/]+)/') AS template,
COUNT(DISTINCT url) AS pages_with_impressions,
SUM(impressions) AS impressions,
SUM(clicks) AS clicks,
SUM(sum_position) / SUM(impressions) + 1 AS avg_position
FROM `project.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY template
ORDER BY clicks DESC;
Then divide impressions by the indexed count from the sitemap-filtered report. For Linkscope, my own arithmetic gives 2.11M ÷ 5,210 ≈ 405 impressions per indexed page over about seven weeks. That number lets you compare templates of different sizes.
Which metrics show a programmatic page should be improved, merged or deleted?
No source gives tested cutoffs for merge versus delete. Here is what the public material supports:
| Signal | Source | Action |
|---|---|---|
| Lost 30% or more from peak traffic | theStacc | Review: refresh, merge or noindex |
| No impressions and not indexed for 6+ months | Vizup | Prune |
| Not crawled in 130 to 190 days | Indexing Insight | Probably dropped from the index |
| Near-duplicate of a stronger page | Merge with a 301 |
theStacc’s month-12 audit found 61 pages down more than 30% from their peak. It refreshed 47, merged 9 with 301s and noindexed 5. Portfolio decay then fell from 19% to 7% by month 18.
On noindex versus delete, I side with Google. Its crawl budget guide says noindexed pages are still requested before they are dropped, so they keep using crawl. Pages you remove for good should return 404 or 410. Google calls deletion “a last resort,” but adds that “deleting the unhelpful content can help the good content on your site perform better.”
When the numbers say the whole pattern was a mistake
Sometimes the problem is the template, not a few weak pages. I’d suspect the pattern itself when:
- one template’s indexation stays below 40% while the other templates on the site index normally
- most of its pages sit in the bottom click cohort for months
- improving the pages doesn’t move indexation after the “several months” Google mentions
The Vizup mini case, probably a composite, cut 12,000 city and service pages to 3,200. Six months later, indexation on the remaining pages was 84% and traffic was 4x. The DEV author cut their sitemap from about 8,600 to about 560 URLs and saw no improvement at the time of writing. Pruning helps when the pages you keep have real data. If none of the rows does, you need a different dataset, not a smaller sitemap.