Most programmatic SEO projects I am asked to review share one defect: someone generated thousands of pages first and asked whether anyone wanted them second. The Seven Gates is the framework I use to reverse that order. A build is a sequence of gates, each with inputs, actions, outputs and a hard check, and you pass a gate only when the check is green. The result is fewer pages, built later, that actually get indexed and clicked. For the conceptual grounding, read my programmatic SEO guide; this page is the operating procedure.
When to use this
Use the Seven Gates when you have, or can acquire, a structured dataset that maps to a repeating search pattern: "[service] in [locality]", "[product A] vs [product B]", "[tool] integration with [tool]", "[college] cut-off [year]". It works for marketplaces, directories, SaaS integration libraries, travel, education and real estate, at any scale from two hundred pages to two hundred thousand.
Do not use it for editorial content that happens to have many pages; if each page needs a human to think, it is a content system. And if the only "data" is a keyword list with a synonym swapped in, stop. That is the pattern Google's spam policies call scaled content abuse, and I explain why in programmatic SEO is not a shortcut.
The structure: seven gates, one rule
A gate opens only when its check passes. The sequence is Demand, Data, Template, Quality, Links, Index, Monitor. Gates one and two decide whether you should build. Gates three and four decide what you build. Gates five to seven decide whether it survives contact with Googlebot.
- Demand
- Data
- Template
- Quality
- Links
- Index
- Monitor
Gate 1: Demand validation
Inputs: the candidate pattern, fifty to a hundred real modifiers, Search Console data if the site exists, SERP samples. Actions: pull the long tail for the pattern, not just the head, and read the SERPs: if one authoritative aggregator owns every result, the demand is real but the slot is hard; if the results are forum threads and thin directories, the slot is open. Look for Hindi and Hinglish variants in India; "[locality] mein [service]" queries are often where uncontested demand sits. Outputs: a demand map showing which modifiers have volume, which match the template's intent, and which are empty. Check: a meaningful share of sampled modifiers show template-matching intent. If demand exists only for the top twenty modifiers, build twenty pages by hand instead.
Gate 2: Data model
Inputs: every data source you can lawfully use: your database, first-party user data, licensed feeds, public datasets. Actions: define the entity (what is one page about?), its attributes, its relationships and its freshness, and write it as a schema before anyone writes a template. Mark each attribute as unique (differs per page), shared (same across many) or derived (computed). Outputs: an entity schema, a coverage report showing what share of records have each field populated, and a freshness plan. Check: the unique attributes alone must make a page worth reading. If the only unique field is the modifier in the title, you have a mail merge, not a data model.
Gate 3: Template design
Inputs: the entity schema, the demand map, the best-ranking competitor pages for the pattern. Actions: design the template around the searcher's question, not around the data you happen to have. Order the blocks: answer first, then supporting data, then comparison or alternatives, then navigation to related entities. Make blocks conditional so a sparse record produces a shorter honest page rather than an empty table. Write title, H1 and meta description logic as rules with fallbacks. Outputs: an annotated wireframe, the template logic, and ten rendered samples across the data distribution (richest, median, sparsest). Check: the sparsest sample must still be a page you would show a customer. I tested how much template variation matters in my programmatic page templates experiment.
Gate 4: Quality thresholds
Inputs: the coverage report from Gate 2, the sample renders from Gate 3. Actions: set a minimum publishable standard as a rule, not a vibe: a minimum number of unique data points, at least one block of entity-specific text, a cap on boilerplate share, and no two records that render near-identically. Decide what happens below the threshold: not generated, generated but noindexed, or folded into the parent. Outputs: a threshold rule set and a count of pages that pass. Check: the publishable set justifies the build and every page in it clears the bar. Expect this gate to cut the page count substantially. That is the gate working.
Gate 5: Internal linking and hubs
Inputs: the relationships from Gate 2, the publishable set from Gate 4. Actions: design the hub hierarchy so every page is reachable within three or four clicks via a crawlable path: homepage, category hub, sub-hub, entity page. Add lateral links between siblings (same city, same category) and an upward link to the hub on every page. Hubs need their own content, not just a list of links. Outputs: a linking spec per template, hub pages, and a crawl showing depth distribution. Check: no orphans and nothing beyond the agreed depth. My internal linking framework covers the mechanics; the internal linking at scale experiment shows what happened when I changed hub structure on a large section.
Gate 6: Indexing control
Inputs: the publishable set, the threshold rules, every faceted and parameterised URL variant. Actions: decide explicitly what gets indexed and enforce it: canonicals for variants, noindex for below-threshold pages, robots rules for filter combinations, and XML sitemaps split by template so you can read coverage per type. Release in waves so you can see how Google responds before committing crawl budget to the rest. Outputs: a sitemap set, a canonical and robots spec, and a release schedule. Check: the first wave indexes at an acceptable rate before the second ships. If indexing stalls, the fault is nearly always at Gate 4 or 5. My guide to crawlability and indexability covers the mechanics.
Gate 7: Monitoring
Inputs: Search Console, log files, the per-template sitemaps. Actions: track four numbers per template: submitted, indexed, receiving impressions, receiving clicks. The ratios between them tell you which gate is leaking. Sample the sparsest pages monthly as data changes, and set a pruning rule for pages with no impressions after a reasonable window. Outputs: a template-level dashboard and a pruning log. Check: the indexed-to-impressions ratio holds or improves across waves. If it falls as you scale, you are diluting the section and need to stop adding pages.
The go / no-go scoring table
Before Gate 3, I score the opportunity on seven criteria, each from 0 to 3. The scores are judgments, not measurements, but writing them down forces the conversation that would otherwise happen six months later in a post-mortem.
| Criterion | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Demand across the pattern | Only the head terms have searches | Thin tail, mostly brand or navigational | Consistent tail with mixed intent | Deep tail, intent matches the template |
| Data uniqueness | Public, identical to competitors | Public but better structured | Partly proprietary | Proprietary or first-party at the core |
| Per-page value beyond the data | None; table only | Generic text block | Entity-specific text or media | Entity-specific insight the user cannot get elsewhere |
| SERP openness | Dominated by one or two authorities | Strong aggregators, some gaps | Mixed quality results | Weak or no dedicated pages ranking |
| Data freshness fit | Changes daily, no pipeline | Changes often, manual updates | Changes rarely or pipeline exists | Stable data or automated pipeline |
| Build and maintenance cost | Requires new platform | Significant engineering | Moderate, within current stack | Low; CMS or existing templates |
| Crawl budget risk | Site already has indexing problems | Large site, unclear crawl health | Healthy, moderately sized | Healthy, small, strong hubs |
My thresholds: 15 or above is a go. Between 10 and 14, go only if the two lowest criteria can be fixed before Gate 3. Below 10 is a no-go, and a zero on demand, data uniqueness or per-page value is a no-go regardless of total. I would rather lose a project at this table than build it and watch it get deindexed.
A worked example
This is a hypothetical built to show the gates in motion, not a client engagement. Imagine a coworking marketplace listing spaces across Indian cities that wants locality pages: "coworking space in [locality], [city]".
Gate 1. Sampling two hundred localities across six metros shows real demand for perhaps a third, concentrated in business districts and IT-park suburbs. Most Tier 2 localities return almost nothing. The demand map says: build for the localities with demand, not for all of them.
Gate 2. The entity is a locality. Unique attributes: the spaces listed, starting prices in INR, seat types, metro proximity. Shared: the city description. Derived: average day-pass price, space count, distance to the nearest metro. The coverage report shows many localities have fewer than three listed spaces.
Gate 3. The template leads with the count and price range, then the spaces, then a short locality block (commute, nearby business hubs), then links to neighbouring localities and the city hub. Sparse localities render without the comparison table.
Gate 4. Threshold: at least three listed spaces and two populated derived attributes. Localities below that roll into the city hub rather than publishing. The candidate list shrinks considerably. Good.
Gates 5 and 6. City hubs link down to localities, localities link sideways to neighbours and up to the city, and a crawl confirms nothing deeper than four clicks. Filter URLs canonicalise to the locality page, sitemaps are split per city, and the first wave is two cities, watched for a few weeks before the next four ship.
Gate 7. The dashboard tracks the four numbers per city; if a city's indexed-to-impressions ratio lags, its sparsest localities are reviewed first. Results from a real build are documented in the programmatic SEO case study.
Common failure modes
Template-first thinking
The build starts with "we can generate a page for every X" and demand is retrofitted. Gate 1 exists to prevent this.
Modifier swapping
Every page is the same paragraph with a different city name. Gate 2's uniqueness test catches it before you ship.
Publishing the sparse tail
Pages with one data point ship because "it might rank". They dilute the section and drag indexing down for the good pages.
Hubs that are only link lists
A hub with two hundred links and no content is a thin page that happens to be important.
Launching everything at once
Fifty thousand URLs in one push means you cannot tell which template is failing. Waves give you the signal.
Nobody watching the ratios
Indexed pages fall quietly for months while everyone looks at total clicks. Template-level monitoring is the early warning.
Run it yourself
- Write the search pattern and sample at least fifty real modifiers, including Hindi or regional variants.
- Score the opportunity on the go/no-go table; record the total and the two lowest criteria.
- Document the entity schema (unique, shared, derived) with coverage per field.
- Render ten samples across richest, median and sparsest records before building the set.
- Write the quality threshold as a rule and count the pages that pass.
- Map the hub hierarchy and confirm click depth with a crawl.
- Split sitemaps by template, set canonical and noindex rules, plan the first wave.
- Build the four-number dashboard per template and set a pruning rule with a review date.
If you would rather have me run the gates with your team, that is what my programmatic SEO service does.
FAQ
How many pages is too many for programmatic SEO?
There is no fixed number. The right count is however many pages pass Gate 4's quality threshold. A few hundred pages that each have a reason to exist and a crawl path will outperform fifty thousand that do not.
Can I use AI-generated text in the template blocks?
With care. Generated text that restates the data in prose adds little and reads as boilerplate. Text that draws on entity-specific inputs and is reviewed against the quality threshold can work. The test is unchanged: would the sparsest page still be worth showing a customer?
What if indexing stalls after the first wave?
Go back two gates, not forward. Stalled indexing almost always means pages are too similar (Gate 4) or too deep and poorly linked (Gate 5). Resubmitting sitemaps fixes neither.
Does this framework apply to a JavaScript-rendered app?
Yes, with one added check at Gate 6: confirm the rendered HTML contains the content and internal links before release. The mechanics are in my JavaScript SEO guide.