Real programmatic SEO examples show where AI genuinely helps and where it creates thin-content risk, plus the PR review gate that keeps scaled pages safe.
Zapier's integration pages pull in roughly 2.6 million organic visits a month, and the "connect Descript to Notion" page alone earns about 1,100 of those visitors on its own, according to a breakdown of Zapier's programmatic pages by Practical Programmatic. It's one of the most-cited programmatic SEO examples in the industry, one page targeting one specific app pair, built from a template. It's also the opposite of what Google's John Mueller was describing in 2023 when he called programmatic SEO "often a fancy banner for spam."
Both things are true at once, and the gap between them is the whole subject of this post. Programmatic SEO with AI can produce Zapier's kind of page or the kind that gets a domain wiped in the next spam update. The mechanics look almost identical from the outside: a template, a dataset, a batch of URLs. What separates them is what's actually on the page once you strip the template away, and whether anyone checked before it shipped.
This is the examples-and-limits companion to our practical guide to programmatic SEO for SaaS, which covers the build mechanics in depth. Here, we look at real programmatic SEO examples worth studying, where AI genuinely earns its place in that pipeline, and where it creates the thin-content risk Google now enforces against by name.
Programmatic SEO is a production method: you find a search pattern that repeats across many entities, build a dataset covering those entities, and render one page per row through a shared template. An integration-page template fed with 300 tools produces 300 pages. A comparison template run against your competitor list produces a page for every "X vs Y" search worth catching.
What changed by 2026 isn't the method. It's who's building the dataset and the wrapper. AI now drafts the unique-per-page prose, checks the facts on each row, and can flag a thin entity before it ever gets a URL. That's a genuine capability shift. It's also exactly why Google's enforcement got sharper: the same tooling that makes a strong programmatic set faster to build makes an empty one faster to mass-produce, and the search results were full of both by early 2024.
The definition that matters here is Google's own. Its spam policies documentation defines scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users," and names "using generative AI tools or other similar tools to generate many pages without adding value for users" as a direct example. Read that twice. The violation is the purpose and the value, not the tool. A dataset-backed page set built to answer real queries clears that bar regardless of what wrote the sentences. A page set built to catch search traffic with nothing behind it doesn't clear that bar regardless of who wrote the sentences.
Case studies of blocked-out template pages don't tell you much. The examples worth studying are the ones still ranking years after launch, because they show what the dataset actually needs to contain.
Zapier's app-connector pages ("connect Descript + Notion," "connect Steam + Twitter") look, at a glance, like the textbook programmatic pattern: one template, thousands of app pairs, a URL for each. What holds them up isn't the layout. Each page lists the specific triggers and actions supported for that exact app pair, plus real workflow examples built from that pair, not a generic "automate your work" paragraph with two names swapped in. Practical Programmatic's traffic breakdown puts the entire integration-page set at around 2.6 million organic visits a month, with individual pages like Descript + Notion pulling roughly 1,100 visitors on their own, a small number for any one page, but the kind of number that adds up across a dataset Zapier is uniquely positioned to publish because it's the platform actually running those integrations.
That's the data moat. Nobody else can publish an accurate "supported triggers and actions" list for a Zapier-run integration except Zapier. Strip the template wrapper off one of these pages and the trigger list, the action list, and the workflow examples remain: real, specific, useful content. That's what separates it from a page where stripping the wrapper leaves nothing.
The other programmatic pattern that consistently holds up is comparison and alternative content, run at the scale of a competitor list instead of a single flagship "X vs Y" post. We cover the conversion and format mechanics in depth in our guide to SaaS comparison pages that convert and rank, but the pattern-level point here is simpler: a comparison page set only survives as a set if each page carries a genuine, page-specific value-add, a real feature table, an honest verdict, a specific use case, rather than the same three paragraphs with the competitor's name swapped in.
Review platforms are the extreme version of this pattern. G2 and Capterra's per-product pages are effectively programmatic, built from a shared template, but the content on each page is user-submitted reviews unique to that product. That's a data moat nobody can template around, which is also why AI answer engines lean on those review pages so heavily when someone asks for a software recommendation.
The pre-AI version of this playbook already knew the rule: unique data per page, not a swapped variable. What AI adds isn't a new rule, it's throughput on two specific jobs. It can draft the unique-per-page prose around a dataset row far faster than a human writer working row by row, and it can check that prose and the data behind it before the page ships. Neither of those jobs existed at scale for most teams five years ago. Both are why "programmatic SEO with AI" is a meaningfully different proposition in 2026 than the template-and-spreadsheet version SEO teams ran in 2015, not because the underlying rule about thin content changed, but because the tooling that can either honor or violate that rule got dramatically more capable.
AI's real job in a programmatic pipeline is narrow, and it's worth being precise about it, because the failure mode is treating AI as the thing that generates the page instead of the thing that fills in and checks the unique layer.
The template, the layout, the recurring headings, the boilerplate intro, is plumbing. Write it once. What AI is actually useful for is the part that has to differ meaningfully from page to page: turning a dataset row (a tool's trigger list, a competitor's feature set, a customer segment's use case) into prose that reads like someone who understands that specific row wrote it, not like a mail-merge. That's a drafting job, and it's one AI does well when the dataset row genuinely has something in it to write about.
It's also a job that fails the same way a human writer fails when the input is thin. Feed a template only a tool name and a category, and both a human and a model will produce two sentences of filler around it. The ceiling on what AI can add is set by the dataset, not the model. If your rows only have tool_name and category, upgrading your AI won't fix a thin page; upgrading your dataset will.
The second job is the one most teams skip, and it's the one that matters most once you're publishing dozens or hundreds of pages a month. Every factual claim, every number, every external link on every page needs to be checked against a live source before that page ships, and doing that by hand across a large batch is where most review processes quietly stop happening. We cover the mechanics in how AI content fact-checking actually works: pull every claim out of the draft, confirm it against a current source, fetch every link and confirm it resolves and says what the page claims it says, and block anything that doesn't check out instead of shipping it with a caveat.
This is the AI capability that has no real pre-AI equivalent at this speed. A model can check 200 pages worth of claims and links in the time a human editor checks 10. That throughput is what makes it realistic to run a real quality gate across a programmatic set instead of skipping the gate because nobody has time to run it by hand.
The same speed that makes AI useful for drafting and fact-checking makes it just as fast at producing the pattern Google explicitly penalizes. Nothing about using AI causes that risk on its own; across roughly 600,000 ranking pages, the correlation between how much AI a page contains and where it ranks is effectively zero. The risk shows up specifically when AI is used to generate volume with no gate checking what comes out the other end.
In July 2023, replying to a thread about sites scraping data into hyper-specific landing pages, Google's John Mueller wrote that "programmatic SEO is often a fancy banner for spam," a line that's since become the shorthand critics reach for whenever the practice comes up. It's worth reading as a description of a pattern, not a ban on a technique. Mueller was describing pages built by scraping someone else's data and repackaging it into thousands of near-identical landing pages: the swapped-variable version of the template, with nothing added on top.
The line lands because it's frequently true. A huge share of programmatic pages built this way genuinely are spam with a template on top, which is why the phrase stuck. It doesn't mean every dataset-plus-template page is spam, any more than every listicle is clickbait. It means the burden is on the page to prove it isn't, and a lot of programmatic sets never bother to try.
The policy Mueller's comment anticipated arrived with the March 2024 core update. Google's spam policies documentation defines scaled content abuse as pages "generated for the primary purpose of manipulating search rankings and not helping users," and it's explicit that this applies "no matter how it's created": by automation, by AI, by a human copying a template by hand, or any combination. Google framed the enforcement around results quality, not around any one production method: it said it expected the March 2024 work to "collectively reduce low-quality, unoriginal content in search results by 40%," and later reported the actual reduction reached 45% as of April 2024.
Read the policy carefully and the target is narrower than "programmatic SEO" as a category. It's pages that exist to catch a search, full stop, with nothing behind them for the person who clicked. A 400-page set where every page carries a real, distinct fact isn't the target. A 400-page set where page 1 and page 400 differ only in a swapped city name is exactly the target, and it's the pattern that got wiped in the enforcement waves that followed.
Two checks decide whether a programmatic SEO template is safe to scale before you generate a single page, and both are mechanical enough to run on a sample before you commit to a full batch.
Take one finished page and remove everything the template contributes: the layout, the recurring headings, the boilerplate intro paragraph. Look at what's left. If a real, useful fact remains, a specific number, a screenshot, a genuine comparison, an actual workflow, you've built an asset. If nothing is left but a name where the template inserted it, you've built a doorway page with extra formatting. Run this on a handful of pages before generating the full set, not after.
Every page needs at least one fact, number, or example that exists nowhere else on the internet: a specific integration detail, a live price, a computed result, a real screenshot. That's the survival bar, and it's a dataset requirement, not a writing requirement. No AI drafting skill fixes a row that only has two thin columns. If you want the fuller mechanics of building a set that clears this bar, including the field-by-field data model, our programmatic SEO for SaaS guide walks through it, and programmatic SEO after the scaled-content-abuse crackdown covers how the enforcement wave changed what "enough" looks like.
Common thin-content programmatic SEO templates worth naming so you can avoid rebuilding them: location pages with only a city name swapped and no local price or example, "top 10 [category] tools" pages generated per keyword variant with an identical list underneath, and glossary pages that just paraphrase a dictionary definition per term with no worked example. All three fail the strip-the-wrapper test immediately.
Fact-checking and link verification catch what's wrong with a page. They don't catch what shouldn't have been generated in the first place, a page whose dataset row was technically present but not actually useful, or a draft that drifted off the brand's voice in a way no automated check flags. That's a judgment call, and it needs a human who can say no before the page reaches the index, not after.
The gate that works in practice is the one most engineering teams already run for code: review before merge. If your blog lives in a git repo, a programmatic batch can go through a pull request the same way a code change does, scored, fact-checked, with the diff visible, and nothing ships until someone approves it. That's the model Lyra is built around: she drafts each page in your blog's existing voice, fact-checks every claim and number against a live source, verifies that every link resolves and is relevant, scores the draft, and opens a pull request and tags you. Nothing auto-publishes. You review the diff and the fact-check notes, and you merge, or you don't. She runs on your own Anthropic key, encrypted at rest and never marked up, so running that check across a real batch of pages doesn't turn into a per-page tax you start skipping under deadline pressure.
A review step that takes minutes per page is cheap insurance against the pattern that gets scaled sets de-indexed. Skipping it because the batch is large is exactly the shortcut Google's policy is built to catch.
Further than most teams assume, as long as the dataset does the work the template can't. Zapier runs thousands of integration pages. NerdWallet and Wise run thousands of live-rate pages. Neither reads as thin, because neither one is: the constraint was never page count, it was whether each page earns its own existence. A small team with a genuinely unique dataset (your own integration list, your own competitor comparisons, your own customer segment data) can scale a programmatic set safely into the hundreds or thousands of pages. A team trying to scale a dataset with nothing unique in it will hit the same wall at 50 pages that it would at 5,000.
None of this is a case against programmatic SEO, or against using AI inside it. It's a case against skipping the check. Zapier's integration pages and the "plumber in every city" spam page use the same production method. Only one of them would survive having its template stripped away.
Lyra drafts each page in your blog's existing voice, fact-checks every claim, verifies every link, and opens a pull request you review before anything ships, the same discipline that keeps a programmatic set on the right side of Google's policy.
FAQ
Zapier's app-integration pages (roughly 2.6 million organic visits a month across the set), NerdWallet and Wise's live-rate comparison pages, and G2's review pages all share the same trait: a data moat unique to that page. Each entity's page carries facts nobody else can publish at the same scale, which is the opposite of a swapped-variable template.
Scaled content abuse is Google's spam policy term for pages generated mainly to manipulate rankings rather than help users. Google's spam policies documentation names 'using generative AI tools or other similar tools to generate many pages without adding value for users' as a direct example. Volume isn't the trigger; emptiness is.
No, not by itself. Google's policy applies 'no matter how it's created,' meaning automation, AI, or a human template all get judged the same way. AI drafting a page inside a reviewed pipeline is fine. AI mass-producing pages with nothing unique on them, unreviewed, is the pattern the policy targets.
Give every page at least one fact, number, or example that exists nowhere else, then run it past a human before it ships. Strip the template wrapper off a sample page: if nothing useful is left, the dataset is too thin to scale, no matter how good the design looks.
Integration pages, comparison and alternative pages, and location or use-case pages, in that order, because each has a well-documented data source behind it: your own integration list, your competitors' feature sets, and your customer base by segment. Start with whichever pattern you already have real data for, not the one with the biggest keyword list.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
Keyword cannibalization, fixed. How two pages targeting one keyword hurt rankings, how to spot it in Search Console, and how to consolidate or differentiate.
A content audit SEO process for finding posts that are quietly losing traffic, diagnosing why each one decayed, and deciding refresh, prune, or merge.
Pillar page SEO explained: what actually belongs on the pillar, how to map a cluster before writing, and how to scale AI-assisted posts without diluting quality.