Programmatic SEO templates: how to design pages that each answer their own search

If you have seen sites with ten thousand pages that differ by one word, you may worry that any template ends up that way. It doesn't have to, and the difference is decided in the design, before a single page exists. This section sets out the three kinds of block every template has, and a test that shows which ones carry the page.

• Data blocks show values from the row: a price, a list of features, a table of measurements. They should carry most of the page.
• Conditional blocks appear, change or disappear according to the values: a warning when a limit is unusually low, a section only when the row has the data for it.
• Fixed blocks are the same on every page: navigation, a note on method, a call to action. Keep them short.

The test: render two neighbouring rows and read them side by side. If the visible text is mostly the same and only the name has moved, the template carries too little data, however many pages it makes. Google's spam policies set no percentage of unique text, but one of their examples of doorway abuse is creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy, and that is what this test catches early. The guide to programmatic SEO covers when a set is worth building at all.

Conditional text is a set of rules, each tied to a value in the row, that decides which sentence appears. It is not a pool of synonyms rotated across pages: that changes the words without changing what the reader learns.

• Compare with the set. Store the median of each field across all rows, then write the sentence the gap calls for: when a town's price is more than 20% above the median, say so and by how much.
• Explain the extremes. A value in the top or bottom tenth of the set usually needs a reason or a caution, written once per condition rather than once per page.
• Admit missing data. When a field is empty, drop its block and say what is unknown, rather than printing a dash or a placeholder.
• Say the specific thing. One integration syncs both ways and another only one way; the sentence should say which, not hedge to fit both.

Google applies the same idea to titles: its title link guidance suggests including words such as video or lyrics only when that particular page contains video or lyrics. Write a dozen pages by hand from real rows before you write any rules; the sentences you keep reaching for become the conditions.

Decide before you generate anything, and write the rule down so new rows are judged the same way. A row earns a page when it passes three checks:

• Enough data. Every field the main answer depends on is present, and any figure averaged from observations rests on a minimum count you set in advance.
• A different answer. If two rows would produce the same page, publish one and fold the other into it. For pairs, pick one order and point the reversed address at it with a canonical tag or a redirect.
• Evidence of demand. Searches in your Search Console data, or results pages showing that people look for this variation.

Rows that fail stay out of the set rather than becoming empty shells. Google's documentation on HTTP status codes says that when a page returns a success code but its content suggests an error, such as an empty page or an error message, Search Console shows a soft 404. List those rows on their hub with what you do know, and promote them once they cross the threshold.

Say you run a removals firm with quotes for 1,200 towns, but only 180 towns have at least 20 completed moves behind their average price. Publish the 180, show the rest in regional tables with the regional average, and recheck the counts each month. The guide to indexing programmatic pages covers what happens once pages go live.

A title pattern needs the variable and the fact that makes this page different. [Tool] integration | Brand gives every page the same shape and nothing else; Connect [Tool] to [Product]: [direction] sync of [objects] carries the row's own answer, such as two-way sync of contacts and deals. Google's title link guidance names both problems to avoid: repeated or boilerplate text, and long titles that vary by only a single piece of information. Among the places Google may take a title link from instead of your title is the page's main heading, so keep the h1 pattern as specific as the title.

Meta descriptions are where large sets usually give up. Google's snippet guidance says that for larger database-driven sites, programmatic generation of descriptions can be appropriate and is encouraged, and that good descriptions are human-readable and diverse. Build them from two or three of the row's values, such as the price and the number of reports behind it, and vary the sentence by condition as you do in the body. Expect Google to use your description only some of the time: it says it primarily uses the page's content to choose the snippet.

Mark up what the page really shows, with the most specific type that fits, and nothing else. Google's general structured data guidelines say not to mark up content that is not visible to readers, that markup must be a true representation of the page, and that duplicate pages should carry the same structured data as the canonical one. They add that correct markup does not guarantee a rich result.

• BreadcrumbList suits almost every set. Google recommends breadcrumbs that represent a typical user path rather than mirroring the URL, and since January 2025 shows them in desktop results only.
• A type for the thing itself, such as Product or Place, when the page describes one such item and your data fills every required property.
• FAQPage no longer produces a rich result in Google. The FAQ rich result stopped appearing from 7 May 2026, and Google removed its documentation in June. Keep an FAQ block when the questions help readers, not for a rich result.

Generate the markup from the same row as the visible page so the two cannot drift apart, and validate a sample from each template after every change.

Links are part of the template and are generated from the data like everything else. Plan three directions:

• Up: a breadcrumb trail and a link to the hub that lists the set. Google's link guidance says every page you care about should have a link from at least one other page on your site.
• Sideways: three to six neighbours chosen by a real relation in the data, such as nearby towns, the next size up or tools in the same category, never at random.
• Down: from each hub to every page in it, paginated with plain links when the list is long.

Use ordinary links: Google says it can only crawl a link if it is an a element with an href attribute. Make the anchor text the neighbour's name or answer, such as removals in Leeds, rather than click here, and skip the footer of dozens of keyword links; Google's guidance also warns against chaining links next to each other. The programmatic SEO examples show how live sets link sideways.

Each outline gives the order of blocks, where each block's content comes from and what changes it. Adapt the fields to your own data.

Integration page (/integrations/[tool]):

• Answer: what connects, in which direction and on which plans, from the integration record.
• What syncs: objects and fields, with a note when sync runs one way only.
• Setup: the steps and the permissions the tool asks for.
• Limits: sync frequency and unsupported objects, with a caution when a limit is unusually tight.
• Neighbours: other tools in the same category.

Location page (/[service]/[town]):

• Answer: the local figure and how many observations it rests on.
• Comparison: the town against its region and the set's median, with the sentence the gap calls for.
• Local specifics: rules or seasons that differ here; the block disappears when there are none.
• Method: where the numbers come from and when they were last updated.
• Nearby: towns within a set distance, by name and figure.

Comparison page (/compare/[a]-vs-[b], one canonical order per pair):

• Verdict: who should choose which, from documented or measured differences.
• Differences first: only the fields where the two differ, then the full table.
• Prices as each vendor's own page states them, with the date checked.
• Switching: what moves across and what does not.
• Related comparisons: each product against its next closest alternative.

If your pages are articles rather than data pages, AutoPSEO's content engine follows the same idea: each content type has its own path, rules, counts and instructions, and every writer, AutoPSEO's own or your AI over MCP, works from the same brief and checks. The writing documentation lists the format settings.