Pull Two Programmatic Pages Off the Line Before Launch

Picture a home services company with a spreadsheet of forty towns and a template for "water heater repair in [town]". An AI writes each page from its row: the town name, the county, a line about the town, the same service list and the same phone number. The first page reads well. So does the second. Nobody reads two of them together, which is the only way to see the problem.

Before any programmatic page goes live, I'd run one test that takes about fifteen minutes. Pull two finished pages off the line, put them side by side and remove everything they share. What's left is the whole value of the second page to the person who searched for it. If what's left is a town name and a sentence of local color, the program is one page printed forty times.

The free guide Programmatic SEO at AI Scale: The Quality-First Playbook covers the full program. This post is the pre-launch test I'd run first, because it takes minutes and answers the question everything else depends on.

What Google calls this pattern

Google's spam policies describe it directly. Its examples of doorway abuse include pages aimed at specific regions or cities that funnel visitors to one page, and substantially similar pages that behave more like search results than like a browsable structure. Its examples of scaled content abuse include using generative AI tools to produce many pages that add no value for users (Google Search Central).

The same policy lists automated rewording, synonymizing among it, as one way scaled pages get disguised. That matters for AI programs in particular. Asking a model to phrase each page differently changes the words and leaves the information identical. The side-by-side test is meant to see through that, so read for facts and ignore the phrasing.

Run the test

1. Pick the two most similar rows. Two neighboring towns, say, or two products in the same category. A program is only as good as its weakest pair, so skip the random sample.
2. Render both pages in full, exactly as they would publish, including every AI-written section.
3. Remove what they share. A text diff tool does it in seconds once you strip the navigation and footer; a highlighter on two printouts works too. Cross out every sentence that appears on both, and every sentence that says the same thing in different words.
4. Read what's left. List each remaining fact that belongs to that row and no other.
5. Ask the searcher's question. Would someone who searched for the second page be worse off landing on the first? If not, the second page shouldn't exist on its own.

What a real difference looks like

A page earns its place when the row behind it carries information that differs and that the searcher cares about. For the water heater example, that might be the permit rules for that town if they really differ, photos of jobs actually done there, reviews from customers there, or a price that depends on location. For a software comparison, it's the real feature and pricing data of the two products. For a page per job title, it's often nothing, and that's a finding in itself.

Notice where that information comes from. None of it should come from the model. A model describes a fact well, but asking it to supply facts your dataset doesn't hold is how invented details end up on pages with your name on them. If the columns are thin, a better prompt only produces more fluent copies.

Structure matters as well as content. Google's doorway examples contrast similar pages that act like search results with "a clearly defined, browseable hierarchy". In practice that means a visitor can reach each page by browsing: a service page that lists the towns, a town page that links back up and across to its neighbors. Pages that exist only to catch a search, with nothing linking to them but the sitemap, fail that description whatever their text says.

So the useful question at the spreadsheet stage is which columns change the answer for the searcher. Count them per row. Rows that come up short don't get a page yet. They can wait until the data exists, or fold into a broader page that covers the region.

When the test fails

A failed test is cheap before launch and expensive after it. If the difference comes up thin, you have a few honest options:

• Build fewer, stronger pages. One well-made service-area page that names the towns you cover can do more than forty thin ones.
• Collect the data first. If the difference would come from job photos or local reviews, the program starts when enough rows have them.
• Narrow the program to the rows that pass, and add the rest as their data fills in.
• Drop the pattern. Some page types never differ enough, and it's better to learn that from a spreadsheet than from a traffic report.

If thin pages are already live, run the test on them anyway. The guide includes a remediation playbook for thin programmatic pages that are already published, for deciding which pages to improve and which to remove.

Automate it after you've done it by hand

Once you've run the test by hand a few times, a script can run a rough version on every page. Compare each page's text with its nearest neighbor after stripping the shared template, and flag the pairs whose remaining text is mostly the same. The guide's quality gates section covers checks of this kind, automated and human, before anything publishes.

Do the manual version first anyway. A script tells you two pages are similar. Reading them tells you whether the difference matters to the person searching, which is the judgment the whole program rests on, and no threshold makes it for you.

Keep pulling pages after launch

The test isn't a one-time gate. Data goes stale and templates get edited. A new batch of rows can also be thinner than the first. Pull a pair every month, one of them from the newest rows, and run the same check. It's the closest thing to reading the program the way a searcher will.

I'll concede that this test is blunt. It can't tell you whether a page will rank, and two pages that pass can still lose to a better site. What it does is catch the failure that no amount of ranking work fixes later.

For the rest of the build, from qualifying the use case to data architecture, template design, quality gates and index management, the free programmatic SEO guide is the place to start. Run your own closest pair through the side-by-side test while you read it.

← Back to all articles