How many pages will this produce?

However many rows survive the completeness rule, which is normally fewer than the number you have in mind. We agree a minimum field list before any code is written, and any row missing one of those fields is written to a list of gaps instead of being published. Sixty complete pages that get indexed are worth more than a hundred and fifty half-empty ones, because the empty ones drag the judgement on the whole set down with them.

Is this the thing Google penalises?

What Google acts against is doorway pages and scaled content abuse — near-identical pages where one variable changes, made to catch a search rather than to answer it. The test is blunt. Put two of your generated pages side by side. If you cannot say what is different about them, neither can Google. Pages built on genuinely different data pass that test. Pages built on a city name do not.

Our data lives in three spreadsheets. Does that change anything?

It changes the price and the schedule more than any other factor on this page. Reconciling scattered data is its own piece of work with its own timeline, and we scope it separately rather than absorbing it — otherwise half the build disappears into fixing columns and the pages arrive late. We look at a sample first and tell you which situation you are in before quoting.

Can it be built inside our existing CMS instead of a new codebase?

Often yes, and sometimes it should be. A static build in Astro or Next.js generates faster and hosts cheaper, but if your team already edits in a CMS, a generated section inside it avoids handing you a second system to keep alive. The deciding question is who maintains it in a year, not which framework is fashionable.

How soon will we know whether it worked?

Two weeks after the first tranche, from the indexation ratio rather than the page count. We compare submitted URLs against indexed URLs in Search Console and read the exclusion reasons. Crawled — currently not indexed is the one that matters, because that is Google saying it looked at the page and decided not to store it. Finding that on tranche one is the entire reason we launch in tranches.

Will you tell us if the idea is bad?

Yes, and the first stage exists partly to do that. A set of pages nobody searches for is a poor purchase however well engineered it is, and it is far cheaper to stop at the end of week one than to discover it after two thousand URLs are live.

SEO & Organic Growth

Programmatic pages generated from your data, not from a template with a word swapped

Hundreds or thousands of pages built from a real dataset, with a hard rule in the code that refuses to publish a page when the data behind it is missing.

From: $1,500–$12,000
Typical time: 3–8 weeks
Usually bought by: Marketplaces, SaaS

Why two thousand pages is a wish, not a plan

Two situations bring people here and they need different answers.

In the first, you have data and you know there is demand for it. Every city and service combination in a marketplace is a real question somebody types. Every entry in a directory carries facts nobody else has collected. Every integration and comparison in a SaaS product is a page that ought to exist. The obstacle is arithmetic — writing two thousand pages by hand is not a plan. This is where SEO and code stop being separate jobs, which is exactly why the work is priced the way it is.

In the second, it has already been built. A few thousand URLs went live, Search Console shows a fraction of them indexed, and the rest sit under Crawled — currently not indexed with no explanation attached. That is not a bug that a plugin fixes. It is a judgement about the content, and the way back is almost always to publish fewer and better pages rather than to push harder on the same ones.

Both situations reduce to one line, and the whole service is built on it. If you cannot tell two of your pages apart when you put them side by side, Google cannot either. A page for every HS code with its actual duty structure is real. A page for every city with the city name substituted into the same sentence is a doorway page, and Google has a published policy about those.

How the build runs

The order is deliberate. Every stage before the code exists is there to reduce the number of pages, not to increase it.

Pressure-test the idea against real demand. We describe one specific example page and exactly what data it would show, then check whether those combinations are searched at all using Keyword Planner and whatever your Search Console already shows for similar queries. This is the stage that kills projects, and it is much cheaper than the alternative. Two to four days.
Audit the data and set the completeness rule. Where each field comes from, how complete it is, how often it changes, and who owns it when it goes stale. Out of this comes a hard rule expressed in code — the minimum fields a row must have before a page may be generated at all. Rows that fail are written to a gaps list for someone to go and find the missing values. Two to five days, longer if the data needs reconciling first.
Design the template, then hand-build one page from it. One page, written properly, before anything is generated. If that single page would not do the job for someone who arrived needing the thing it covers, no amount of generation improves it. The summary text has to vary with the actual values rather than being one fixed sentence with a name dropped into it. Three to four days.
Build the generator. A dynamic route that produces one page per row at build time, with structured data appropriate to the content type, a last-verified date on every page for trust, and the completeness rule enforced in the build rather than in a checklist somebody is supposed to follow. One to two weeks depending on the template count.
Set up the indexing architecture. Sitemaps split to stay inside the 50,000 URL limit per file, an internal linking scheme that puts any generated page within three clicks of the home page, and an index page that groups the set so a crawler has a route in. Orphan pages get almost nothing from the rest of the site, and generated pages orphan themselves very easily. Two to three days.
Launch in tranches and watch the indexation ratio. Publishing five thousand URLs on one day invites scrutiny and teaches you nothing. We release a first tranche, wait two weeks, compare submitted against indexed in Search Console, read the exclusion reasons, and only then release the next. Spread across two to three weeks, and continuing after handover.

What sets the fee

The range is $1,500–$12,000 over 3–8 weeks and three things decide where a project sits in it.

The state of the data. This dominates everything else. Data already in a clean database with stable field names is a fast build. Data spread across three exported spreadsheets with inconsistent city spellings and a column that is sometimes a number and sometimes a range is a separate project that has to happen first, and it needs its own line in the scope. Skip that conversation and half the budget disappears into cleaning while the pages arrive late.

How many distinct templates there are. One template across four thousand rows is one design problem. Five templates with different fields, different structured data types and different internal linking rules is five, and the testing multiplies with them.

Where it has to live. A standalone static build is the cleanest and quickest. Generating inside an existing CMS, or inside an application with its own routing and deployment process, means working to constraints that are already there and testing against a system you did not design.

Where these projects fail

Pages are generated for rows the data does not support. This is the single failure that destroys the whole set rather than one page. A row missing its address, its price or its timings still produces a page that renders, and that page is thin. Enough of them and Google's assessment of the set as a whole turns negative, taking the good pages with it. The rule has to live in the build, refusing to emit the page and logging the gap, because a rule that depends on someone remembering is not a rule.

Everything is published on one day. Five thousand new URLs appearing at once is a pattern worth looking at, and more practically it removes your ability to learn anything. If sixty of the first two hundred get indexed, that is a content quality result you can act on while the remaining rows are still unbuilt. If the whole set is already live, the same finding costs you the entire build.

Success is measured in pages instead of indexation. The count of generated URLs is the number that feels like progress and means the least. What matters is the ratio of submitted to indexed two weeks after each release, and the reason attached to the ones that failed. A set where fifty-five of sixty pages are indexed has passed the quality test. A set where twelve of sixty are indexed has been assessed and rejected, and building more of the same is the worst available response.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How many pages will this produce?: However many rows survive the completeness rule, which is normally fewer than the number you have in mind. We agree a minimum field list before any code is written, and any row missing one of those fields is written to a list of gaps instead of being published. Sixty complete pages that get indexed are worth more than a hundred and fifty half-empty ones, because the empty ones drag the judgement on the whole set down with them.
Is this the thing Google penalises?: What Google acts against is doorway pages and scaled content abuse — near-identical pages where one variable changes, made to catch a search rather than to answer it. The test is blunt. Put two of your generated pages side by side. If you cannot say what is different about them, neither can Google. Pages built on genuinely different data pass that test. Pages built on a city name do not.
Our data lives in three spreadsheets. Does that change anything?: It changes the price and the schedule more than any other factor on this page. Reconciling scattered data is its own piece of work with its own timeline, and we scope it separately rather than absorbing it — otherwise half the build disappears into fixing columns and the pages arrive late. We look at a sample first and tell you which situation you are in before quoting.
Can it be built inside our existing CMS instead of a new codebase?: Often yes, and sometimes it should be. A static build in Astro or Next.js generates faster and hosts cheaper, but if your team already edits in a CMS, a generated section inside it avoids handing you a second system to keep alive. The deciding question is who maintains it in a year, not which framework is fashionable.
How soon will we know whether it worked?: Two weeks after the first tranche, from the indexation ratio rather than the page count. We compare submitted URLs against indexed URLs in Search Console and read the exclusion reasons. Crawled — currently not indexed is the one that matters, because that is Google saying it looked at the page and decided not to store it. Finding that on tranche one is the entire reason we launch in tranches.
Will you tell us if the idea is bad?: Yes, and the first stage exists partly to do that. A set of pages nobody searches for is a poor purchase however well engineered it is, and it is far cheaper to stop at the end of week one than to discover it after two thousand URLs are live.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Programmatic SEO All SEO & Organic Growth services