
AI Summary
Programmatic SEO works when each generated URL is backed by data nobody else has published, and fails when a template is stretched over thin rows. The difference is a publish gate: uniqueness, internal links and sitemap segmentation checked before a batch ever goes live.
- The unit of programmatic SEO is one trusted data row equals one URL. If the row is thin, no template can rescue it.
- Hold every generated URL to three checks: uniqueness above 30 percent, at least 2 internal links in, and a segmented sitemap entry.
- Ship in batches and gate the next batch on the indexed rate of the last one, rather than publishing the whole set at once.
- Boilerplate ratio is the metric to watch: if over 70 percent of rendered words are shared across siblings, the set will not index.

Case study overview
This case study documents a successful organic growth strategy, demonstrating how strategic SEO implementation drives measurable business results. The approach provides actionable insights for practitioners facing similar challenges.
Challenge and Context
Every successful SEO initiative begins with understanding the starting position and objectives. This case study reveals the initial challenges, competitive landscape, and business goals that shaped the strategy. Understanding context helps practitioners assess applicability to their own situations.
Strategic Approach
The methodology employed combined technical optimization, content strategy, and authority building in a coordinated approach. Key decisions around prioritization, resource allocation, and tactical execution provide a template for similar initiatives. The strategy balanced quick wins with sustainable long-term growth.
Implementation Details
Moving from strategy to execution required specific technical implementations, content creation processes, and measurement frameworks. This case study documents the practical steps taken, tools used, and workflows developed. These implementation details help practitioners translate strategy into action.
Results and Analysis
The outcomes demonstrate the effectiveness of the approach through measurable metrics: traffic growth, ranking improvements, and business impact. Analysis of what worked best and what could have been done differently provides learning value beyond the raw results.
This case study contributes to the evidence base for effective SEO strategy, helping practitioners learn from documented successes.
Why a tool using its own product is the useful version of this story
A company that builds a data syncing product and then uses that product to generate its own pages is running the honest version of the experiment. The data is real, the sync is real, and the pages either earn traffic or they do not. That makes it a better teaching case than most programmatic write ups, which tend to show the template and skip the part where thousands of URLs sit unindexed for a quarter.
The mechanic underneath every implementation of this pattern is the same regardless of stack. You hold structured data somewhere, you map fields into a page template, and you publish the result. The stack choice, whether that is a no code sync, a static site generator, or a WordPress import, changes the effort but not the outcome. What changes the outcome is whether anything stops a weak row from becoming a live URL.
For the underlying concept and terminology, see what is programmatic SEO. For the full build discipline, including template design and data QA, see programmatic SEO done right.
The five layers of a programmatic build
Most failed programmatic projects are missing a whole layer, not a detail. Below is the stack, what each layer is really for, and how the project breaks when it is absent.
| Layer | What you are actually building | Failure mode if skipped | How to check it |
|---|---|---|---|
| Data layer | A single source of record where one row equals one URL, with required fields enforced | Rows with empty fields generate pages that say nothing | Query the source for rows below your populated field threshold before generation runs |
| Template layer | A static shell plus dynamic slots, where the dynamic part carries the value | Boilerplate dominates and every page reads the same | Render two sibling URLs, strip nav and footer, and diff the remaining text |
| Internal link layer | Hub and category pages that link down, plus sibling links across | Orphaned URLs that are in the sitemap but unreachable by crawl | Screaming Frog crawl, then Crawl Analysis, then the Orphan Pages report |
| Sitemap layer | Segmented XML sitemaps, one per batch or template type | You cannot tell which batch indexed and which did not | Search Console, Sitemaps report, indexed count per submitted file |
| Monitoring layer | A per segment indexed rate tracked over time | Bloat accumulates silently until site wide quality drops | Search Console Page indexing report filtered by sitemap |
The layer teams consistently skip is internal linking. A sitemap tells Google a URL exists. Internal links tell Google the URL matters. A 5,000 page set with no hub structure typically indexes at a fraction of the rate of the same set wired into category pages, because crawl priority follows link paths, not sitemap membership.
The publish gate, check by check
The gate is the entire difference between the two outcomes in the diagram. It is a script that runs before publication and refuses to release URLs that fail. Every threshold below is a default to start from, not a law.
| Check | Threshold | Measured how | If it fails |
|---|---|---|---|
| Uniqueness | Above 30 percent of body text differs from the nearest sibling | Render 2 siblings, strip the shell, compare token sets | Add data fields, or cut the URL from the batch |
| Data completeness | Every required field populated, 60 percent of optional fields populated | Validation query against the source table before generation | Hold the row until the data exists. Do not generate a stub |
| Internal inlinks | At least 2 contextual internal links pointing at the URL | Screaming Frog Internal tab, Inlinks column, sorted ascending | Add hub, category or sibling links before publishing |
| Sitemap membership | URL is in a segmented sitemap of under 5,000 entries | Sitemap index diff against the generated URL list | Regenerate sitemaps. Never publish outside a segment |
| Indexed rate of last batch | 80 percent or above after 21 to 30 days | Search Console Sitemaps report for that segment | Stop shipping. Fix quality on the existing batch first |
| Title and description uniqueness | No exact duplicate title across the set | Crawl export, Page Titles tab, Duplicate filter | Add a differentiating field value into the template |
Measuring uniqueness properly
Uniqueness has to be measured on rendered text with the shell removed, because nav, footer and sidebar are identical everywhere and will inflate the similarity score into uselessness. The practical method: fetch two sibling URLs, extract only the main content container, normalise whitespace and case, then compare word sets. If the shared proportion is above 70 percent, the pages are siblings in name only and the set will not sustain indexation.
The fix is almost never rewriting sentences. It is adding fields. A page with six real data points and a derived comparison has something to say. A page with two data points wrapped in 300 words of connective prose does not, no matter how the prose is varied.
Batching and the indexed rate loop
The single most useful operational habit in programmatic SEO is refusing to publish the whole set at once. Release a batch, wait a crawl cycle, and read the indexed count for that batch's sitemap segment in Search Console under Indexing then Sitemaps. That number is your quality score. It is far more honest than any content grading rubric, because it is Google's own verdict on the template.
Interpreting the result:
- Above 80 percent indexed: the template holds. Release the next batch and consider increasing batch size.
- 40 to 80 percent: the template is borderline. Look at which rows failed. It is usually the sparsest data, which tells you exactly where the completeness threshold should sit.
- Below 40 percent: stop. More URLs will not fix this. The pages are being judged as insufficiently distinct, and the excluded ones are dragging on how the whole directory is assessed.
When URLs stall in the excluded bucket, the diagnosis path is in crawled, currently not indexed. When too many low value URLs are already live, the cleanup path is in index bloat.
A worked example: 3,000 integration pages
Suppose you are generating pages for every pairing of two apps in a directory, giving roughly 3,000 combinations. The naive template produces a title, a sentence describing both apps, and a signup button. That is a near duplicate factory: the only variable is two names.
The version that survives the gate carries per pair data that has to be looked up, not generated:
- Which specific fields sync in each direction, listed explicitly rather than described.
- Sync latency and update frequency for that pair.
- Known limitations, such as field types that do not map cleanly.
- A worked setup sequence with the actual screens and field names for those two tools.
- The three questions support receives most often about that pair.
Now the boilerplate ratio drops naturally, because the unique portion is large and factual. Just as importantly, the coverage rule earns its keep: any pair where you cannot fill those fields is a pair you should not publish yet. In practice that usually removes a third of the combinations, and the remaining two thirds index far better than the full set would have.
What to instrument after launch
Four numbers, reviewed monthly, cover the health of a programmatic directory:
| Metric | Where | Healthy direction | What it tells you |
|---|---|---|---|
| Indexed URLs per sitemap segment | Search Console, Sitemaps report | Rising toward the submitted count | Whether the template is accepted |
| Clicks per indexed URL | Search Console Performance, Pages tab | Flat or rising as the set grows | Whether new URLs add value or dilute |
| Share of set with zero impressions | Performance export joined to the URL list | Falling | How much of the directory is dead weight |
| Crawl requests to the directory path | Search Console, Settings, Crawl stats | Proportional to the value of the section | Whether crawl budget is being wasted |
The second row is the one that decides whether to keep expanding. If clicks per indexed URL falls as the set grows, each new batch is taking attention from the ones already working, and the correct move is to prune and deepen rather than generate more.
FAQ
Generating pages from a database is not itself a violation. What Google's spam policies target is scaled content abuse, meaning pages produced primarily to manipulate rankings that offer no value of their own. The test is whether each URL answers a real query with information a user cannot get more easily elsewhere. A directory of 5,000 genuinely distinct data records is fine, while 5,000 permutations of the same paragraph is not.
Publish in batches and let indexation govern the pace. A workable default is 200 URLs, then wait 21 to 30 days and check the indexed count for that sitemap segment. If more than 80 percent get indexed, release the next batch. If the rate is below half, the problem is page quality or internal linking, and shipping more URLs will make it worse.
Aim for at least 30 percent of rendered body text differing from the nearest sibling page, measured after stripping nav, footer and sidebar. Below roughly 20 percent, pages behave as near duplicates and typically end up in crawled currently not indexed. Uniqueness comes from data density, not from spinning sentences.
Yes, and they should be templated from real field values rather than a fixed string plus the page name. Include a differentiating data point in the description, such as a count, a price band or a date, so the snippet answers something. Identical descriptions across thousands of URLs are one of the fastest ways to have the whole segment treated as low value.
Keep the generated set at a different intent level from your editorial pages. If the programmatic template targets modifier queries and the editorial guide targets the head term, they rarely compete. Then check reality in Search Console: filter by the head query, open the Pages tab, and confirm only one of your URLs is receiving impressions for it.
Yes. Split them into segmented sitemaps of a few thousand URLs each, ideally one per batch or per template type. Search Console reports indexed counts per sitemap, so segmentation turns indexation into a measurable per batch number instead of a site wide guess.
Planning a programmatic build, or cleaning up one that stalled?
An audit measures uniqueness, indexed rate per segment and internal link coverage across the generated set, then tells you what to ship, fix or cut.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







