A template that ranks, not a mad-lib.

“Programmatic page” sounds like a euphemism for “auto-generated junk.” It doesn’t have to be. The technique is just this: build one good page layout, then fill it from a spreadsheet where every row is a real thing — a city you actually serve, two products worth comparing, a question buyers actually type. The technique is neutral. What separates a template that ranks from a doorway-page generator is whether each row brings enough genuine substance that the page would deserve to exist even if a human had typed it out by hand. If it wouldn’t, no amount of clever templating saves it — and Google’s “scaled content abuse” policy exists precisely for the sites that skipped that step.

Two layers: the boilerplate and the variable layer

Every programmatic template has two parts, and the whole game is in keeping them honest about their jobs.

The boilerplate is everything that’s the same on every page in the set — and it should be the same, deliberately. The header and footer. The navigation. The page structure: where the H1 sits, where the proof block goes, where the contact form lands. The shared trust signals — your license number, your years in business, your “100 sites shipped” line, the schema markup. None of that needs to vary, and reinventing it per page would be worse, not better. Boilerplate that’s consistent is a feature: it’s what makes 50 or 184 pages shippable in a fortnight without quality collapsing, and what keeps them maintainable when something changes — you edit the template, not 184 files. That’s the same systems-over-snowflakes logic behind topical authority done at scale, and it’s why programmatic SEO is fast to build in the first place.

The variable layer is the part that earns the URL. This is the genuinely page-specific content: the real data for this row, the local fact only true here, the unique angle. On a service-area page that’s the response time you actually offer in that suburb, the housing stock that area is known for and what breaks in it, a recent job there, the landmarks a local would recognize. On a comparison page it’s the actual feature-by-feature difference between A and B, the situations where each one wins, the price reality. On a glossary term it’s a definition written for someone who genuinely doesn’t know the word yet, with an example that fits your industry. The variable layer is not “[city] HVAC services since 1998” with the city swapped — that’s a swapped noun, and a swapped noun is not value. If the only thing different between two sibling pages is a proper noun, you’ve built one page and published it twice.

• Healthy ratio. There’s no magic percentage, but a useful gut check: if you stripped the boilerplate away, would what’s left read like a real, specific page on its own — or like a stub? If it’s a stub, the row doesn’t have enough behind it to publish yet.
• Variable doesn’t mean tiny. The variable layer can be most of the page. A good city page is mostly the local stuff; the boilerplate is the frame around it, not the content.

The “would this page deserve to exist?” test

Before any row goes on the build list, it has to pass one question, asked honestly: would this page deserve to exist if I weren’t generating it from a spreadsheet? Three sub-questions get you the answer.

Is there a real search behind it? Someone, somewhere, actually types this. If nobody searches “[your service] in [tiny hamlet you’ve never worked],” the page is targeting demand that isn’t there, and Google will leave it un-indexed — correctly. We unpack what that means in why aren’t my programmatic pages ranking.

Is the intent distinct from a page you already have? “AC repair Tampa” and “emergency AC repair Tampa” might be one page or two depending on whether the search behavior genuinely differs. “AC repair Tampa” and “AC repair in Tampa, FL” are the same page — don’t build both.

Can you say something specific and true on it? If you can’t write the variable layer honestly — because you’ve never worked that area, because there’s no real difference between those two products, because the data behind the row is empty — the page shouldn’t be built. Padding the set with it makes the whole set weaker, not stronger. The thin-content line gets its own full treatment in the thin-content line; the short version is that a cell that fails the test gets noindex‘d or skipped, not shipped.

One template, many data rows — not one shell, many proper nouns. If swapping the noun is the only edit, you didn’t build a page; you photocopied one.

How much unique substance a page needs

The honest answer is “enough that it isn’t a near-duplicate of its siblings, and enough that a person reading it would learn the thing they came for.” That’s not a word count — a 400-word answer page can be substantial and a 1,200-word city page can be padded fluff. What it means concretely: the variable layer has to carry real, checkable information that’s true of this row and not the next one. Where the data comes from is the whole job — your own records first, then public datasets, then carefully sourced external data — and it gets its own deep-dive in where the data comes from. The point here is just that the template can only ever be as good as the rows you feed it. A beautiful template fed empty rows produces empty pages. The work isn’t the template; it’s making sure every row has something behind it.

The page families that actually work

Some patterns lend themselves to a template because each instance genuinely has its own data. These are the ones that earn their place — done with real substance, not just a swapped noun:

• City / location pages. “[Service] in [city]” — the canonical local-business case. Each page carries that city’s actual service reality. (This is where service-area pages live; see service-area pages for the local-SEO version.)
• [Service] × [city]. The matrix — AC repair in Brandon, furnace installation in Wesley Chapel. The cells multiply fast, which is exactly why the “deserve to exist” test matters: build the ones with a real local angle, skip the ones without.
• Comparisons — [A] vs [B]. Two products, two approaches, two providers. Real differences, real “when each one wins.” Only works if the comparison is genuine.
• “Alternatives to [X].” A roundup of real options with honest pros and cons — useful when you actually know the alternatives.
• Integrations. “[Your product] + [other tool]” — what it does, how to set it up, what it’s good for. One row per integration that genuinely exists.
• Directory / listing entries. One page per item in a catalog — a service, a location, a resource — where each item has its own attributes worth a page.
• Glossary terms. One page per term in your field, each a real definition with an industry-relevant example. Cheap to do badly, valuable when done well.

What unites all of these: the pattern repeats, and each instance has its own genuine data. What’s not on the list: anything where each instance needs original judgment rather than a different data row. More on the boundary in what kinds of pages can be programmatic.