Use when a data driven template is about to generate thousands of URLs you would then have to clean up.
programmatic-page-template-qa.md
You are reviewing a programmatic page template before thousands of URLs are generated from it. You are not building the data pipeline.
Template structure (headings, fixed copy, variable slots): {{TEMPLATE_STRUCTURE}}
Rendered sample pages from across the data range: {{SAMPLE_PAGES}}
Data fields available, with their fill rates: {{DATA_FIELDS}}
URL pattern: {{URL_PATTERN}}
Planned page count: {{PLANNED_VOLUME}}
Output four numbered sections.
1. Uniqueness read: what share of a page is fixed boilerplate from {{TEMPLATE_STRUCTURE}} against what genuinely varies, with two passages quoted from {{SAMPLE_PAGES}} that read almost identically.
2. Failure mode table: Failure mode | Present? | Evidence | Fix. Cover empty variable slots, broken grammar from insertion, duplicate titles and descriptions, single record pages, zero result pages, pages that only restate the data table, and problems in {{URL_PATTERN}} such as casing, encoded spaces, sort parameters and slot ordering.
3. Publishing threshold: given the fill rates in {{DATA_FIELDS}}, the rule for which records earn a page, and roughly how many of {{PLANNED_VOLUME}} clear it.
4. Staged rollout: batch sizes, what to measure between batches, and the result that would stop it.
Constraints:
- Do not estimate a fill rate that is not in {{DATA_FIELDS}}.
- If {{SAMPLE_PAGES}} does not span the data range, name the extremes that are missing.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When do I run this rather than auditing the pages afterwards?
Before generation, while the template is still cheap to change. Auditing afterwards means pruning at scale, and a mass de-index of thousands of thin URLs is slower and more visible than never publishing them. Run it once samples render and before anyone points the pipeline at the full data set.
What do I need in front of me?
The template with its fixed copy and variable slots marked, rendered samples from across the data range, field fill rates, the URL pattern and the planned page count. Include a sparse record and a rich one. If the samples do not span the range the output will name the extremes it could not see.
What comes back?
A uniqueness read quoting two passages that read almost identically, a failure mode table with evidence, a publishing threshold, and a staged rollout. The threshold is the part to keep: it turns fill rates into a rule for which records earn a page, and an estimate of how many of the planned pages clear it.
What goes wrong most often?
Sampling only the well populated records, because those are the ones that look good in a demo. Empty slots, broken grammar from insertion and single record pages all live at the sparse end of the data, and those are exactly the pages that get generated in bulk and then indexed badly.