Programmatic SEO means building a large set of pages from a database instead of writing each one by hand: one template, many rows of data, one page per row. Done well, it lets a property portal, job board, directory or marketplace answer thousands of specific searches that no writing team could ever cover. Done badly, it produces thousands of near-identical pages that Google treats as spam. I help UK businesses that hold genuinely useful structured data plan, specify and check a page set that stays on the right side of that line.
What programmatic SEO is, and when it works
The programmatic SEO test I apply before anything else is simple. Does each page carry information the searcher cannot get from the page next to it? A page for two-bedroom flats to rent in Walthamstow works if it lists real flats, real rents and the nearest stations. A page for a plumber in Walthamstow that swaps the town name into the same 300 words does not, and Google’s guidance describes that as one of the doorway pages it demotes.
Google’s spam policies also name scaled content abuse: producing pages in bulk mainly to rank rather than to help anyone, whether the pages come from people, templates or AI. The method itself is not the problem. Pages with nothing distinct to say are. Programmatic SEO earns its place when three things are true at once: searches follow a repeating pattern, such as a service plus a place or a product plus a use; you hold data that answers each variation differently; and your template presents that data better than the pages already ranking.
I made the opposite choice for this site. The pages listing the areas I cover are designed individually and kept to places where each page has something specific to say. A page per UK town with the same service description and a different place name would be exactly the pattern Google warns against.
Who this suits, and who it does not
It suits UK businesses whose product is the data, or who hold data that maps neatly onto how people search:
- property portals, lettings and estate agency groups with listings by area, street or property type
- job boards and recruitment firms with live vacancies by role, sector and location
- directories, comparison and review sites covering many providers
- retailers and marketplaces with large, well-attributed catalogues, alongside the wider work covered by ecommerce SEO
- software companies with integration, template or use-case pages built from product data
- travel and leisure businesses with routes, venues or destinations
It does not suit a service business that wants a page for every town within thirty miles. If you have real branches, multi-location SEO is the right approach: one properly built page for each location that actually exists. If you serve an area from one base, local SEO and a well-kept Google Business Profile will do more than any number of generated pages.
It also does not suit a site whose foundations are already shaky. If Google is ignoring half of your existing pages, adding ten thousand more makes the problem bigger, not smaller. Fix crawling and indexing first with technical SEO, then build.
What the work covers
Search pattern research
I start with keyword research organised by pattern rather than by single term: the head term, the modifiers that change it, how many realistic combinations there are and which of them have enough demand to deserve a page. Many combinations do not, and leaving them out is part of the job.
Data audit and enrichment
I check your dataset for gaps, duplicates and stale records, then decide what each page needs beyond the core fields to be worth reading. In the UK, useful enrichment often comes from public sources such as ONS statistics, HM Land Registry price paid data or Food Standards Agency hygiene ratings, much of it published under the Open Government Licence. Some data, Royal Mail’s Postcode Address File for example, needs a paid licence, so I check the terms before anything is built on it.
Template specification
I specify the template in detail: the title and H1 patterns, which fields appear where, what genuinely changes from page to page, the minimum data a page needs before it is allowed to go live, and what happens to rows that fall short. Structured data is defined at template level, so every page in the set carries it correctly.
Indexing and linking rules
A page set needs a plan for how Google finds it and which pages it should index at all. I set the rules for canonicals, noindex on low-value combinations and XML sitemaps split by section, along with an internal linking structure of hub pages, breadcrumbs and links between related pages, so that no page relies on the sitemap alone to be found.
Quality checks at scale
Before launch I crawl a staging build and read a sample of pages across the whole range, from the richest rows to the thinnest. I look for duplicated text, empty or broken fields, pages that compete with each other for the same search, and anything that would embarrass you if a customer landed on it.
How I run a programmatic project
- Feasibility. I look at your data and the search patterns and tell you plainly whether a page set is worth building, and at what size. Sometimes the honest answer is a few hundred pages rather than tens of thousands, or none.
- Specification. You get the pattern map, the template specification, the publishing threshold and the indexing rules, written so your developers can estimate and build from them.
- Pilot. A small batch goes live first, usually one section or one region, and we watch in Search Console how Google crawls and indexes it before going wider.
- Staged rollout. If the pilot pages are indexed and earning impressions, the set grows in steps, with checks at each one.
- Maintenance rules. Data goes stale. I agree what happens when a listing expires, a branch closes or a row loses its data, so the set does not decay into dead or empty pages.
The pages themselves are built by your developers or your platform supplier from the specification, and the staging review and post-launch check confirm that what goes live matches it.
Problems I see most often
- A place name swapped into identical copy. The most common pattern, and the clearest doorway risk.
- Every combination published. A page for every colour, size and town combination creates index bloat and spends Google’s attention on pages nobody searches for.
- No minimum data threshold. Pages with one listing, or none, go live and read as empty. Google often treats a page that says “0 results” as a soft 404.
- Weak internal links. Thousands of pages reachable only through the XML sitemap rarely get indexed in full.
- Filler between the data. Paragraphs generated to pad each page out add words rather than information, and they are what the scaled content policy is aimed at.
- No plan for expiry. Listings disappear and leave behind thousands of thin or broken URLs that nobody owns.
What you receive
- a feasibility note with a clear recommendation, including when that recommendation is not to build
- a pattern map showing which combinations get a page, which do not, and why
- a template specification covering titles, headings, content blocks and schema
- canonical, noindex, sitemap and internal linking rules
- a pilot plan and the Search Console measures to judge it by
- a staging review with issues listed by severity, and a post-launch check
Each document is written so that the people who approve the budget and the developers who build the templates can both act on it without a translator.
Next step
If you have a dataset and a feeling that it could support a page set, send me a sample of the data and a handful of searches you think it could answer. I will tell you whether it is worth pursuing and roughly what it would involve. If you would rather begin with how your current site is doing, request a free SEO audit and I will tell you what I would fix first.