The three tests a template has to pass
Programmatic SEO has one genuinely great use case and about forty terrible ones. The great one: you hold structured data answering a query pattern people really search, and no human could reasonably write 4,000 pages by hand. Marketplaces, travel, real estate, integration directories, price comparison, job boards, anything with inventory.
The terrible ones all look identical from the outside — a spreadsheet, a template, and a number in a deck. Before we build anything, a template clears three tests, in this order, because each one is cheaper to fail than the next.
- Unique data per page. Cover the row, not the template. If the only difference between page 412 and page 413 is a swapped city name in three sentences, you haven't built 500 pages — you've built one page 500 times, and the index will treat it that way. The test is blunt: strip the template out and see what's left. Under roughly 40% of the page, it fails.
- Real query demand, per row. Not the head term — the actual permutation. We sample 30–50 rows across the full range, including the tail at the bottom. Templates usually pass on the first twenty rows and collapse by row 500, which is the whole problem: the tail is where the page volume lives, and it's where the demand doesn't.
- A reason a human would stay. The page has to answer the query on its own, without a form or a signup. If visitors bounce in four seconds because it's a stub wrapped around a CTA, Google works that out from the behaviour of everyone who lands there. This test kills the most proposals and it's the one clients argue about most.
The 50-page pilot, and the numbers that kill it
Nobody gets to bulk-generate on day one, including us. We build the template properly, publish 50 pages spread across the range — best rows, middle rows and deliberately weak rows — and then we wait, because the index is the only opinion that counts.
The kill criteria go in writing before the pilot ships. That matters: agreeing thresholds after you've seen disappointing data is how projects get rationalised into existence.
- Under 60% indexed at day 45 — stop. Google is choosing not to store these pages. More of them will not change its mind.
- Indexed but zero impressions on more than 70% of pages at day 60 — the demand test was wrong. Cut the tail, keep the head, don't scale.
- Impressions arriving but almost no clicks across the set — usually an intent mismatch rather than a title problem. Fix the template before multiplying it by a hundred.
- Engaged sessions well below your site's own median — the pages don't hold anyone. This is the test three, failed in public.
- Any manual action, or a sitewide drop that starts after publication — revert immediately, noindex the set, and we sit down and work out what we got wrong.
Where scaled content abuse starts
Google's spam policies name this directly. Scaled content abuse is described as creating many pages primarily to manipulate rankings rather than to help users — and Google is explicit that it makes no difference whether automation, humans, or a combination produced them. The method isn't the offence. The absence of value is.
Two consequences founders routinely miss. First, "a human edited it" is not a defence; someone lightly rewriting 3,000 templated stubs is exactly the behaviour described. Second, and more expensive: this is a sitewide judgement. When a domain gets classified this way, the pages quietly earning you leads for four years go down with the generated ones. That asymmetry is the entire reason we pilot instead of launch.
The line, in practice, sits at intent. Would this page exist if search engines didn't? If the answer needs a paragraph, it wouldn't. Longer argument in programmatic SEO and the scaled content line.
Patterns we'll refuse to build
- City pages for locations you don't serve, with an address you don't have.
- "[Competitor] alternative" pages generated across a scraped list, with no real comparison in them.
- Spun variations of the same 600 words with synonyms swapped by a model.
- Question pages generated from an autocomplete scrape, each answering in two sentences.
- Anything where the dataset belongs to somebody else and we'd be republishing it.
Patterns that usually work
- Inventory or catalogue pages where the data genuinely differs per row and updates over time.
- Integration and compatibility pages, when each one documents real behaviour rather than asserting it.
- Comparison pages built from specifications you actually hold, with the numbers on the page.
- Location pages where a real outlet, real staff and real reviews exist — that's local SEO with a template, not programmatic filler.
What's included, and what isn't
Programmatic work sits inside the SEO retainer from ₹75,000/mo, ex-GST. There's no separate build fee — the pilot and the template work are part of the engagement, which also means we're not incentivised to ship 5,000 pages to justify a project invoice.
| Included | Not included |
|---|---|
| Demand validation across the full row set before anything is generated | Building a dataset you don't already have |
| Template design: what varies per page, what each page has to prove | Scraping or licensing a third party's data on your behalf |
| The 50-page pilot, published, indexed and measured | Bulk generation on day one because the deck promised 5,000 pages |
| Internal linking architecture, sitemap segmentation, index management | Front-end engineering inside your application |
| Kill criteria agreed in writing before the pilot ships | Continuing after the kill criteria trigger |
| Monthly index-coverage and per-cluster performance reporting | Any promise of a ranking position for a generated page |
| Pruning and noindexing the rows that never earned their place | Pages we judge likely to trip scaled content abuse — we'll decline |
What it costs, and who does the data work
The retainer starts at ₹75,000/mo and covers strategy, template, pilot, measurement and ongoing maintenance. What sits outside it is engineering time on your side: exposing the data, wiring the template into your CMS or app, and keeping the feed fresh. We estimate that in hours before anything starts — usually a week or two of one developer for a first build, less if the data already sits behind an API.
Maintenance is the line nobody budgets for and everybody needs. A programmatic set isn't a launch, it's a system: rows go stale, inventory disappears, pages 404. Ongoing work means index monitoring, pruning dead rows, refreshing the template as the SERP shifts, and expanding only where demand appears.
The full rate card sits on the pricing page. If your foundation is the problem — crawl budget burnt on faceted URLs, a slow render path, duplicate canonicals — fix that with technical SEO first. Publishing 2,000 new URLs onto a site Google already struggles to crawl turns one problem into two.
What we guarantee on a programmatic build
Two things, both measurable, both frozen on day one.
First, indexation rate on the pilot. We commit to a target — normally 80% of the 50 pages indexed by day 45 — and if we miss it, we don't invoice for scaling work we haven't earned the right to do. That's the honest version of a programmatic guarantee, because indexation is the one part of this we can actually influence through template quality, internal linking and sitemap hygiene.
Second, the company guarantee: your trailing-90-day qualified leads from organic search, frozen at kickoff. Beat it within 90 days or we keep working free until we do. It's the same promise on every SEO engagement, and it's why we only take three clients a month — you can't carry that risk at volume, and you certainly can't carry it while publishing thousands of pages you haven't validated.
What we won't guarantee: a position for any generated page, a page count, or a traffic number. A page count is the easiest promise in this discipline to keep and the most likely to cost you the domain.