Programmatic SEO: how to build thousands of pages people actually need

Programmatic SEO is a way of publishing pages in bulk. You find a search that repeats with one part changing, collect the data that answers each variation, and generate one page per variation from a shared template. The pattern [your app] integration with [tool] becomes a page for every tool you connect to; cost of living in [city] becomes a page for every city in your dataset.

The difference from editorial SEO is where the effort goes. An editorial article is written once, for one search and its close variants. A programmatic set is designed once, and then the work moves to the data: finding it, cleaning it, keeping it current, and deciding which rows deserve a page at all.

Most programmatic sets follow a handful of shapes:

• Integrations: one page per tool a product connects to, with the setup, the limits and what syncs.
• Locations: one page per city or country where the answer really differs by place.
• Comparisons and alternatives: one page per pair of products a buyer weighs.
• Conversions and calculations: one page per unit pair, currency pair or input value.
• Directories and glossaries: one page per entity or term in a defined set.

If you have seen sites with thousands of city pages that say the same thing with the name swapped, you are right to be wary of the whole idea. This section gives you a test to run before you build anything, so you know which side of that line your plan sits on. It comes down to three questions.

• Does the search repeat with a real variable? People must search the pattern with many different values, not just the head term.
• Does each variation need a different answer? If the answer for Leeds is the same as the answer for Bristol, one page serves both searches better than two.
• Do you have, or can you build, the data? The data is the page. A public dataset anyone can copy makes weak pages; your own product data, prices, measurements or tested results make strong ones.

Sets fail in predictable ways: pages that differ only in the keyword, pages for variations nobody searches, and pages whose data is copied from elsewhere with nothing added. Google's spam policies describe the last two directly. Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users, no matter how it's created. The doorway policy names substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy.

Start from demand, not from a dataset you happen to have. Write the pattern as a head term plus a modifier, then list the modifiers: the tools you integrate with, the cities you serve, the competitors buyers compare you with. Then check each pattern three ways.

• Demand across the whole set. Single variations often show little or no measured search volume. What matters is the total across all of them, and whether people search the pattern at all.
• What ranks now. If the results for several variations are already pages of one type, one per city or one per integration, searchers want that format. If the results are long guides, a templated page will struggle.
• Your own Search Console data. Searches you already get impressions for, with no page that matches them, are the best evidence you have. Filter the Performance report for queries containing the head term and note which modifiers appear.

Take a scheduling app that sees impressions for searches like "sync with Outlook calendar" and "Zoho calendar sync", all landing on its single integrations page far down the results. Each calendar has its own setup steps, permissions and sync limits, so each search has a different answer. That is a pattern worth a page per calendar, and the guide to programmatic SEO keyword research shows how to size one like it.

A template is a set of blocks, each filled from the data. The page is useful when the blocks that change carry most of the value and the blocks that stay the same are short. A structure that works for most sets:

• The answer first: the specific fact the searcher came for, taken from the row: the rate, the price, the steps, the compatibility.
• Data only this page has: a table, a list of limits, figures you measured.
• Text that changes with the data: sentences written for the values, such as a warning that appears only when a limit is unusually low, rather than one paragraph with the name swapped in.
• Neighbours: links to related pages in the set, which also give crawlers a path through it.
• Questions about this variation, answered from the data.

Decide in advance which rows do not get a page. A row with missing data should not become a page with gaps; leave it out, or list it on a hub page until it has enough to stand alone. The guide to programmatic SEO templates goes through the blocks and those thresholds in more detail.

Publishing a page does not mean Google will index it. Google's own help for the Page indexing report says not to expect every URL on your site to be indexed, and that non-indexed URLs can be fine as long as your important pages are. Make the important ones easy to reach and easy to tell apart:

• Sitemaps. One sitemap holds at most 50,000 URLs or 50 MB uncompressed; larger sets go in several files listed in a sitemap index. Google uses lastmod only when it is consistently accurate, and ignores priority and changefreq.
• A browseable hierarchy. Hub pages that link to every page in the set, and pages that link to their neighbours, so no page depends on the sitemap alone.
• No near-duplicates. Google's crawl budget guide asks you to eliminate duplicate content so crawling focuses on unique content rather than unique URLs. It is written for sites with over a million pages, or over ten thousand that change daily, but the principle holds for any set.

Watch the Page indexing report as you publish. Discovered, currently not indexed means Google found a URL but has not crawled it yet, typically because crawling it then was expected to overload the site. Crawled, currently not indexed means Google fetched the page and chose not to index it for now. A large, growing share of either across one set is a reason to look for near-duplicates, thin rows and weak internal links before blaming the server. For Bing and the other engines that support IndexNow, you can also announce new and changed URLs directly; Google does not use it.

Google has no rule against pages built from templates and data; much of what it shows for prices, places, products and software is made that way. Its spam policies target purpose and value. The scaled content abuse policy lists examples such as using generative AI tools to generate many pages without adding value for users, scraping or automatically transforming other content (including by translating it) where little value is provided, and stitching content from different pages together without adding value.

Google's guidance on generative AI says the same from the other side. It describes generative AI as useful for researching a topic and adding structure to original content, and says it is critical to manually fact-check and review all AI-generated content for accuracy before publishing. Its guide to helpful content adds two questions worth asking of any set: are you using extensive automation to produce content on many topics, and is the content primarily made to attract visits from search engines? If the honest answer is yes, the set needs better data or fewer pages. The article on whether Google penalises AI content goes through those policies in detail.

A programmatic page is only as true as the row behind it. Prices change, integrations add features, a city's figures are revised, a product you compared with is discontinued. Plan the upkeep before you publish:

• Rebuild pages when their data changes, and set lastmod only when the content really changed. Google's helpful-content guidance specifically warns against changing dates to make pages seem fresh.
• Track each page's clicks over time. A page that loses most of its clicks has usually been overtaken by a better answer or has gone out of date.
• Retire pages cleanly. When two pages answer the same search, merge them and redirect the weaker one with a 301; when a variation stops existing, remove the page rather than leave it to decay.

AutoPSEO runs this process from your own Search Console data. Its content engine scans your site, picks out searches you appear for without a page that answers them, sets aside the ones your pages already cover, and writes articles in your site's format and languages. Each article is delivered to your own site through a signed webhook, and articles that lose clicks are refreshed later; by default you approve every article before it goes live. The content engine documentation explains each step and what you control.