I maintain two programmatic page sets. One is a local services directory on WordPress, just under 3,000 listing pages. The other is a tool with 62 pages, one per format it supports. The small one was the harder decision to make. The large one is the one that got me in trouble with Google, and fixing it taught me more than the build did.
Programmatic SEO is generating a set of pages from one template and a structured data source, so a single build covers a family of long-tail searches at once. The template holds what never changes. The data holds what does. It works when each row answers a genuinely different search, and it fails when the rows are one page wearing different words.
TL;DR
- Programmatic SEO is one template plus a data source, generating a family of pages that share a shape
- The real decision is whether each row deserves a page or the set deserves one page with a filter
- Write your two most similar rows out longhand before building; if you only swap a noun, you have a filter
- Templated near-duplicate copy across a few thousand pages read as scaled content to Google and cost me an AdSense approval; the fix was unique per-row content grounded in real data
- Never hardcode a count in a template: one project of mine reports 47, 36 and 45 for the same number
- Thin content is the symptom, rows that do not differ is the cause
Page one for this term belongs to companies selling SEO tools. Semrush, Zapier, Ahrefs and seoClarity, all with the same definition-then-steps shape, and Reddit sitting above all of them. So here is the version from someone who has a set live and has had to maintain it.
What programmatic SEO actually means
Take a page you already have that works. Find the one thing about it that changes across a real list: a city, a product type, a file format, an integration. Move that thing into a data source and let your build loop over it.
That is the whole mechanism. A programmatic SEO template is a page with holes in it, and your data source fills the holes.
The difference from normal SEO is scope, not method. Normal SEO is one hand-written page per intent. Programmatic SEO is one build covering a family of intents that share a shape.
Everything else carries over. Your page still has to answer the query, still needs internal links, still needs to be worth landing on. Scale does not exempt a page from being useful, and that is where most of these projects die.
The decision that comes before the template
If someone searching row A and someone searching row B want materially different answers, build the pages. If they want the same answer with one word swapped, build one page and a filter.
Getting this backwards is how you end up with a doorway problem, because you have produced volume without producing difference. And the failure is quiet. Nothing breaks, nothing errors, the pages just never earn anything.
You can usually tell before you build. Write two rows out longhand, by hand, no template. If the second one bores you to write, it will bore Google to index.
Two sets, two ways of earning the page
The small set is the easy case to reason about. Sixty-two pages, one per format the tool supports, and each page is a working generator rather than a description of one. A WiFi code encodes a network credential. A contact card encodes a person. Someone searching for one does not want the other, and the page does the thing instead of explaining it. Difference is structural there: it comes from the tool, not from the writing.
Sixty-two pages that only described those same formats would be the thin-content version of an identical build. That is worth sitting with, because it is the whole distinction. The tool behind each page earns the URL. The template that generated it earns nothing.
The directory is the harder case, because nothing structural distinguishes one listing from another. Every row has the same fields: a name, a location, a rating, a list of services. The page shape is identical by design. So the difference has to come from the content, which is exactly where these sets fail.
Both are the same technique. Only one of them can lean on the product to justify the page, and if you are building a directory or a marketplace you are in the second category, where you have to earn it in the data.
The data is the hard part
Writing the template takes an afternoon. The data source is where the actual work lives.
Your data needs three things. It needs to be complete, because a half-filled field renders as an awkward gap and you will not spot it on row 34 of 62. It needs to be genuinely distinct per row, which is the decision above showing up again as a data problem. And it needs an owner, because a static list rots and a page that was accurate at launch stops being accurate without telling you.
Then there is counting, which is where I got it wrong. One of my projects reports the number of formats it supports in three different places. The widget says 47. The marketing page says 36. The config file behind both says 45. Same project, three numbers, because each was typed into a different place by hand instead of counted from the source.
None of those numbers is a lie. They were all true when someone wrote them down. That is exactly the problem with a hardcoded count in a programmatic set: it is accurate for a week and quietly wrong forever after.
Where these sets get killed
Thin content is the risk everyone names, and it is real, but it is a symptom. The cause is building rows that do not differ.
Google's guidance targets scaled content abuse, which is pages made mainly to game search rather than to help. A 200-page set swapping a city name into the same paragraphs meets that description whether or not you intended it. Handing the job to AI agents makes it easier to do badly and faster to do at volume, which is the real change of the last two years, and why the thin content risk now arrives at a scale that used to need a team.
I know the shape of this because I walked into it. On the directory, every listing carried an About section built from one template with the venue name and services dropped in. Thousands of pages, near-identical prose, all technically accurate. Google's verdict was low value and scaled content, and the concrete cost was an AdSense rejection. Nothing had broken. The pages loaded fine and the data was correct. They simply did not differ from each other.
The fix was not fewer pages. It was rewriting the About section on 2,735 of them so each one was grounded in that specific venue's own review text, with the rating and review count rendered as live tokens rather than typed in. Afterwards I measured it: highest 5-gram overlap between any two pages was 0.42, and zero near-duplicate pairs remained. That is the number worth checking, because uniqueness you have not measured is uniqueness you are guessing at.
The version that survives is boring to describe. Fewer pages, or the same pages carrying something the others do not have. A working tool, real data, a number pulled from its source. Programmatic SEO on WordPress and on Webflow will both happily generate a thousand URLs for you. Neither will mention that nine hundred should not exist.
The check I run before building
- Pick the two rows in your list that are most similar to each other. Not the two most different. The two most similar.
- Write both pages out by hand, fully, without the template.
- If they come out meaningfully different, the set is safe and you can go build.
- If you find yourself changing one noun and calling it done, you have a filter rather than a page set.
That check is cheap, and it is the only part of this process that gets more valuable the larger your list gets. An hour spent on two rows can save the entire project. It also sits inside a bigger picture: where a page set fits in a site's structure is a strategy question, and I keep that thinking in the SEO skills I run in Claude Code.
