Programmatic SEO for B2B catalogues: a 5-stage production process

“Programmatic SEO” usually means one of two things: “we'll generate 500 pages overnight with a script” or “we have a template that fills fields.” Neither survives contact with a B2B catalogue, where half the queries are long-tail with very specific specs, and where Google indexes thin content only long enough to demote the whole site.

Our programmatic SEO is a concrete 5-stage production process with an independent QC filter. Below — what each stage does, why the engines differ, and where this breaks.

Step 0: the reference page

Before any pipeline you need a reference — one real, hand-built page you want 80 / 200 / 500 of. Not a Tilda template, not a brief; a live HTML page with copy, Schema.org, internal links, FAQ, images and metadata.

The reference is written by an expert + the client, because only the expert knows what must be in a “Scraper conveyor” card and what only inflates the page without value. Tone, length, mandatory blocks, spec tables, FAQ format — all agreed on the reference. Takes 1–2 weeks, billed as its own task.

You cannot start the pipeline without a reference. Not because “it won't work” — it will: you'll get 500 identical thin pages, Google will index them, and the whole site goes down. That's the signature of cheap programmatic, and it's visible at a glance: one title template, identical H2s, the same paragraph with one word swapped.

The 5 stages

1. research — brief assembly

Takes a row from the semantic table (query + intent + cluster) and assembles a research brief for one page: SERP top-10, real People-Also-Ask FAQ, competitor mentions, key product specs from the CMS. Output: a structured ~5 KB brief.

Under the hood is a dedicated engine tuned for context and clustering. The budget is set here once and the stack is matched to it, so you don't confuse “research” with “generation.”

2. draft — HTML generation

Input: brief + reference + a link to the product card in the CMS. Output: an HTML fragment matching the reference structure, with specs pulled directly from the client's CMS API. No “roughly 2–3 kg”: if the CMS says 2.4 kg, the text says 2.4 kg.

The main requirement at this stage is strict adherence to the reference structure. Any “creative drift” here breaks the whole production line.

3. check — checklist validation

Runs the draft output through a checklist: does the structure match the reference, are all required tables / FAQ / Schema present. Returns approved or fix: [list]. Cheaper than publishing and rolling back later.

4. publish — auto-publish

The task is mechanical: hit the client's CMS REST API (Bitrix, WordPress, Tilda), push the page, write the changelog. No creativity — just POST, PUT, response handling, snapshot for rollback.

This stage is optimised for speed and cost — critical when publishing 500 pages in a row and every cent multiplies by the hundred.

5. qc — independent 10×10 audit

The most expensive stage. Input: a screenshot of the live page + its HTML. An independent auditor scores the page across 10 criteria (headings, schema, specs, internal linking, readability, length, uniqueness, metadata, mobile render, alt) × 10 points each.

Threshold: 90/100. Below — the page goes back into fix-loop with a concrete list. Experience: ~30% of first-pass generations don't make it. After fix, ~95% pass on the second attempt.

Where this breaks

Not on the long tail. Not on thin content. It breaks on two things:

• Unaligned reference. Expert and client interpreted the card differently. Pipeline ran, generated 200 pages off the wrong reference. Only fix — realign and re-run. Cost: a week of downtime.
• CMS API returning garbage. Bitrix REST quietly replaces em-dash with hyphen in fields, WordPress has edge cases with Application Passwords, Tilda has no webhooks. Each CMS gets wrapped in a client-specific adapter — that's why month 1 always takes longer than month 2.

Cost

The infrastructure-call cost of running the pipeline across 500 pages is incomparably lower than the alternatives. Context: a copy studio would quote $3–5k for the same 500 pages and spend 2–3 calendar months. The production process does it in a week at a fraction of that.

Clients don't pay “engine cost + markup.” They pay for the reference, the CMS adapter, the pipeline tuning to their domain, the independent QC loop and production accountability. The calls themselves are just the engine inside.

When you need this

Don't, if you have 30 pages and a stable catalogue — hand-writing is cheaper and faster.

Yes, if:

• your catalogue is 100+ pages and growing;
• there's a long tail of low-frequency queries (1–10 impressions/mo each) that together carry half the niche traffic;
• you have visible gaps right now — duplicate product cards, missing descriptions, empty alt — and no team will close them in reasonable time;
• a new cluster of 50–200 landings is on the roadmap for next month.

FAQ

“Does Google penalise auto-generation?” — Not auto-generation. Google penalises thin content without value. If your programmatic spews 500 near-duplicate pages, Google demotes the whole site. If the same 500 pages actually answer different queries, carry different specs from a real database and pass independent QC — Google indexes and ranks them.

“Can we run this pipeline ourselves?” — Technically yes: everything above runs on public APIs and well-known tooling. But the reference + CMS adapter + pipeline tuning for the niche is ~6 weeks for a small dev team. Clients come to us not for “how” but for “run it and own the outcome.”