Programmatic page brief template

The reason most templated page sets underperform has nothing to do with Google’s tolerance for scale. It is that an SEO lead described the idea in a Slack thread, an engineer built a reasonable interpretation of it, and neither of them agreed in writing what a page must contain to be allowed to exist. This brief is the artifact that fixes that. Ten blocks, signed off by both sides before a single row of the data table becomes a URL.

The ten blocks, and who signs each one

Print this table at the top of the brief. If a block is empty, the set is not approved.

Blocks 9 and 10 are the ones that get skipped, and they are the two that decide whether this becomes an asset or a liability. Read the programmatic page indexation study before you argue for skipping them.

Block 1: define the entity and the modifier precisely

Every programmatic set is one entity crossed with one modifier list. Write both as a set, with the exclusion rules attached.

Entity: App in our integrations catalogue (source: integrations table, 312 rows)
Modifier: Our product name (single value, not a cross product)
Pattern: [our product] + [app] integration
Exclusions: apps with fewer than 4 synced fields
 apps in private beta
 apps whose vendor name is a registered trademark we cannot use in a title
Resulting set: 312 rows minus 84 exclusions = 228 pages

The exclusion list is where the quality gate starts. Write the arithmetic out, because the difference between 312 and 228 is the difference between a set that can be defended and one that cannot. This is the same discipline that separates programmatic and editorial content as production models.

Block 2: data source and refresh frequency

Name the table, the owner and the cadence. Stale data on a scaled page set is a legal exposure, not a ranking problem, particularly on anything showing competitor pricing.

Block 4: the unique value block and its floor

This is the block that decides indexation, and it is the one engineers push back on because it cannot be generated. Set a hard floor: five unique data points per page plus 120 words of page specific prose that no sibling page carries.

Blocks 5 and 6: URL patterns and link rules

URLs first. Pick the pattern before anything is built, because changing it later means redirecting the whole set.

URL: /integrations/[app-slug]/
Title: [App name] integration for [Product] | Two way sync in [X] minutes
H1: [Product] and [App name] integration
Meta: Connect [Product] to [App name]. Sync [field count] fields two ways,
 set up in [X] minutes, no code required.
Canonical: self, absolute

Now link rules, which are where most sets quietly fail. Inbound: every templated page needs at least one link from an editorial page or a hub, because a page reachable only from a sitemap gets crawled late and often not at all. Outbound: three to five links back, split between the parent hub, two sibling pages chosen by shared category rather than alphabetically, and one relevant guide.

Keep the parent hub page in your SaaS keyword map template as a single row representing the whole set, rather than 228 rows nobody will maintain.

Blocks 8 and 9: sitemap segmentation and numeric indexation gates

One sitemap file per template, referenced from a sitemap index. Search Console reports coverage per sitemap, so this is the difference between knowing your integration pages sit at 78% and your use case pages at 11%, and staring at one blended number that tells you nothing.

Then the gates. Write numbers, not intentions.

Gate	Threshold	When measured	Action if failed
Batch 1 size	25 to 50 pages	At launch	Do not exceed, regardless of pressure
Indexed share	60% or higher	Week 6	Halt rollout, audit uniqueness and links
Impressions per page	Median above 0	Week 8	Rewrite the unique block on the zero set
Crawl to index lag	Under 21 days	Week 6	Check internal links and sitemap submission
Full set rollout	Only after two clean batches	Week 10+	Scale in 200 page increments

The operational side of running these batches sits in the programmatic page launch playbook, and the strategy case for doing any of this is in the programmatic SEO for SaaS guide.

Block 10: kill criteria, written before launch

Here is the position this template exists to argue. A page set without written kill criteria should not be approved. Nobody ever volunteers to delete 4,000 pages, because by then the set has a champion, a slide in a QBR and a traffic number that looks fine until you segment it.

So write the conditions now, while nobody is attached to them.

Attach an owner and a review date to the criteria themselves. Quarterly is enough. The review takes twenty minutes and consists of running five queries against Search Console and the data warehouse.

A filled example: the integration set

Pulling it together for the 228 page integration set described above. Entity: apps in the catalogue with four or more synced fields. Data refreshed nightly from the integrations table, with setup times maintained quarterly by product marketing. Each page carries the synced field list, sync direction, setup time, two limitations, one screenshot and a named use case, which clears the five point floor.

URLs follow /integrations/[app-slug]/, server rendered, self canonical, in a dedicated sitemap-integrations.xml. Every page links up to the integrations hub and across to two category siblings. Batch one covers the 40 apps with the highest search volume, including Slack, Stripe and HubSpot, which also happen to be the ones with the richest field data.

Gates: 60% indexed at week six or the rollout halts. Kill criteria as above, reviewed each quarter by the SEO lead. Modelled pipeline for the full set runs through the SaaS SEO ROI calculator at three conversion tiers, because integration intent converts far better than the volume suggests. The detailed page anatomy lives in the SaaS integration pages guide, and the same brief structure adapts to alternatives pages with the modifier swapped for competitor names.

The honest cost

Writing this brief properly takes a day, and the unique value block takes longer than the engineering. For a 228 page set, budget two to three weeks of a writer and a product marketer producing the per page prose and screenshots, because that part cannot be generated from the table. Teams that skip it ship in four days and index at 12%.

Before you approve anything

Fill blocks 1, 4, 9 and 10 first. If those four are weak the rest does not matter. Send the brief to the engineer who will build it and ask them to reject anything ambiguous rather than interpret it. Then launch 40 pages, not 400, and put a calendar reminder six weeks out to check indexation. Definitions and background sit in the programmatic SEO entry and the wider SaaS SEO hub.