Programmatic SEO with AI, built two ways
There are two builds behind this page, and they suit different kinds of pages. The first is an n8n workflow that takes a row from a data sheet and fills a section template into a WordPress draft. The second is a set of Claude Code generators that build pages from verified data and test every page against the others before any of them ships.
The first is quicker to set up. The second is what you reach for when the pages name real companies or quote real numbers.
Why most generated pages read like one page repeated
A template with the noun swapped out is the textbook shape of a page search engines learn to ignore. The usual AI version makes it worse: the model fills every section with fluent, general prose, so the pages differ in wording and say the same thing.
This site runs 71 industry playbooks built on the opposite rule, where a page only exists if it can make an argument no sibling can. The builds below are how that kind of rule gets enforced in code rather than by good intentions.
The n8n template filler
The workflow reads one planned row at a time and builds the page section by section:
- Create a Drive folder and a Google Doc titled with the row's meta title.
- Read the page structure from a second sheet, with each section's name, its size in words and what it must include, filling an industry placeholder from the row.
- Write the introduction, then loop through the body sections, giving each one the topic and two randomly chosen secondary keywords at an exact word count.
- Add three key takeaways, each under 15 words and each carrying a number from the article.
- Write the conclusion and five FAQs, with questions under 15 words and answers of 35 to 45 words.
- Convert everything to HTML and create a WordPress draft with the slug from the sheet.
Every section prompt carries the same style rules: eighth-grade English, no em dashes, and no sentence longer than 20 words.
What the template version showed
It works, and it shows its limits quickly. Rotating two random secondary keywords per section keeps pages from sharing keyword patterns, but it can't stop them sharing an argument, because every page is still answering the same section brief.
That is why the later builds stopped trusting the template and started testing the finished pages against each other.
The Claude Code generators
For Awesomic, three page families were built from structured data, each with its own test suite:
Page family | Size | What guards it |
|---|---|---|
Competitor alternatives | 29 pages and a hub | A sourced quote behind every claim, 24 checks per page |
Design examples | 44 pages | 30 live captures, 35 curated Reddit quotes, 92 checks |
Service pages | 49 rows | All 7,399 cells round-tripped into a CSV for Figma |
The repetition test is the one that changed the pages most. Across the alternatives set, the share of copy repeated between pages fell from 39.3% to 9.9% before the set was considered finished.
Handing pages to design as data
Not every page family is built as HTML. The service pages went to design as a spreadsheet: an 81-row plan was merged down to 49 rows, each with 159 columns following the structure of a service page the client had already approved.
Two scripts guard that hand-off. One reads every cell back after the CSV is written, and the other compares 151 fields against the approved page, so a missing section or a changed heading shows up before a designer opens the file. Matching that page's voice also meant fixing 817 contractions, because the approved page used them and the first draft didn't.
Deciding which pages should exist
Neither build decides which pages to make. That comes first, from keyword research automation grouped into page families, with each family phased by how much demand actually sits behind it.
On the Awesomic examples grid, 182 design verticals across 5 sections made 910 possible pages. The keyword data, not the grid, decided how many of them were worth building.
When the data can carry the pages
Programmatic SEO AI tooling fits when you hold structured data that is genuinely different per page: real attributes, real prices, real examples. SaaS products tend to have the richest data for it, which is why integrations, alternatives and use-case pages dominate programmatic SEO for SaaS.
It is a poor fit when the only thing that changes between pages is a place name or an industry noun. That is the pattern the tests exist to catch, and no model writes its way out of it.
What a page family costs
The template filler calls a small model once per section, so a page costs little to draft. The generators and their tests run locally.
Builds run under execution capacity, $2,000 a month for the automations route, flat, added to a fractional Head of Content retainer. A first page family takes two weeks or more, because the data and the tests take longer than the template.
Start with your data, not a template
Send the dataset you'd build pages from, even as a rough export. On a call we'll look at how much of each row is genuinely unique, which decides whether the pages should exist before anyone builds them.
Case studies built on this
Related automations
Automated SEO reports for client retainers
A monthly n8n run that pulls Search Console tables, GA4 organic reach, and live checks of published articles and placed links into the client's report sheet.
Read the build →
SEO competitor research
For every keyword in the plan, pull who ranks, how long their articles run, the search intent, secondary keywords and Reddit quotes, then hold the row for approval.
Read the build →
SEO content automation
An n8n + GPT workflow that takes a keyword + product, analyzes the SERP, builds the article structure from what's ranking, and ships a full draft into a Google Doc.
Read the build →