DEV Community: Baibhab Bose

500 programmatic pages, 15 days live — here are all the numbers, including the 6 clicks

Baibhab Bose — Sat, 19 Sep 2026 20:07:37 +0000

The one-line version

Fifteen days ago we put 500 programmatic pages live for a real client. As I
write this, the site has earned 6 clicks and 89 impressions. We're
publishing that anyway — because the curated-screenshot version of this
industry is exactly the problem, and because those two numbers mean something
different when you read the rest of the file.

The client and the problem

Bishal is a bridal and event makeup artist in Kolkata (muabishalmakeup.in).
His business lives and dies on being found for exactly the queries brides
type before their wedding — by service, by neighborhood, by tradition, by
occasion. One homepage can't rank for that universe; a human-written page per
query would take a year. Programmatic was the honest fit: a real query
space, real service data, a page per distinct intent.

The page plan

Honest disclosure first: we didn't record the exact candidate count while
planning. That's a tracking gap we won't repeat in the Glasshouse log, where
every rejected page gets counted in public from week one. What survived
planning was 500 pages across service × locality × tradition × occasion
intents for the Kolkata market.

Every surviving page had to pass three tests: a distinct demand we could
name (no keyword-enumeration filler), a data backbone specific to that page
(service inclusions, price band, locality, tradition-specific detail), and
an intent no sibling page already claimed. The plan mixed service intents
(bridal makeup, engagement makeup, SFX) with tradition intents
(traditional Bengali bridal) and occasion intents — because "bengali bridal
makeup artist near me" and "bridal makeup cost in kolkata" are different
searchers with different questions.

The review gate

Gate rejections for this project: not tracked — the gate ran inside the
build sessions and we didn't log its kill counts. We're not going to guess
them now; estimates dressed as data are exactly what this industry doesn't
need more of. From the Glasshouse build onward, rejections are counted and
published weekly. What the gate is for, in practice: it kills the pages that would have made this case study a spam
story — template twins with no unique value, near-duplicate intents, pages
whose data backbone was too thin to be worth a URL. The gate is also why we
can publish this file: everything that shipped survived a deliberate
before-publish inspection, and this article's numbers describe what that
process produces, not a promise of what it always produces.

The timeline

Planning start: not tracked — we never timestamped when research began; the honest anchor is the launch date below
500 pages live on the client's own subdomain (services.muabishalmakeup.in): 31 August 2026
432 keywords under rank tracking from day one
This snapshot: first 15 days (1–15 September), pulled 19 September

The numbers — first 15 days, labeled precisely

Important framing: GSC's "last 3 months" filter only contains 15 days of
data, because the site went live 31 Aug. Reporting this as "3 months"
would be the dishonest kind of framing — in the direction of making us look
worse. The honest window is: two weeks.

Totals: 6 clicks · 89 impressions · 6.7% CTR · 28.9 avg position.

Now the part the totals hide:

6.7% CTR is a good number. When Google surfaced these pages, roughly 1 in 15 searchers clicked. Thin pages don't earn that; intent-matched ones do.
28.9 average position at day 15 is on schedule. A weeks-old domain with pages already oscillating around page 2–3 is what the early pSEO curve looks like before the compounding phase.
The best line in the file: traditional-bengali-bridal-kolkata — 64 impressions in 15 days, zero clicks, position trending up. That page is knocking on page 1 for its exact target query, two weeks in. This is the page we'll be watching in public.
The query list validates the page plan. "bridal makeup kolkata" (26 impressions), "kolkata bridal makeup package", "kolkata bengali bridal makeup", "bridal makeup cost in kolkata", "bengali bridal makeup artist near me" — these are the long-tail intents the plan predicted, surfacing

(drag the image here in the dev.to editor, then delete this line)

Only 6 of 500 pages have any impressions yet. That is normal and it is the least-understood fact about pSEO: Google evaluates a fresh long tail for months, not weeks. The other 494 pages aren't failing; they're queueing. We'll find out together — see the pledge below.

(drag the image here in the dev.to editor, then delete this line)

One real defect the data surfaced, reported here first: our Pages report
shows both http:// and https:// variants of the homepage earning
clicks — a canonical/redirect imperfection from launch week. Not fixed yet
as of this snapshot. It's at the top of the fix list, and the public log
will mark the week it ships. It's exactly the kind of thing this project
exists to show instead of hide.

What underperformed

Everything outside the handful of surfacing pages — which, at day 15, is
most of the site. Impressions on several service pages (engagement makeup:
16, SFX: 12) haven't converted to clicks yet, and the homepage's 5 clicks
came mostly from branded navigation. The current best explanations: the
crawl is still shallow (most pages not yet evaluated), and the pages with
impressions are mostly ranking just below the click zone. Both are testable
over the coming weeks — and they'll stay testable in public.

What we'd do differently

The honest list: we launched all 500 pages at once, which bought speed at
the cost of a cleaner crawl story — in hindsight, an initial wave of the
strongest ~100 pages with the rest rolling weekly would have given Google
(and us) cleaner signal per batch. And the http/https canonical slip
shouldn't have survived launch review; it did, and the data caught it, which
is both the mistake and the argument for the review gate.

What's next — the pledge

That was us building for a client, quietly. Starting this week, we do it
again from zero, in public: a new wedding-vendor programmatic site, every
number published weekly for 12 weeks, flops included.

For 12 weeks we publish the build's real numbers every Thursday — traffic,
indexing, gate rejections, decisions, mistakes. If it flops, you'll watch
it flop and read our autopsy. No edits to the pledge.

Today's snapshot (6 clicks, 89 impressions, one page knocking on page 1)
becomes what we'll call a week-0 baseline — the starting line the weekly
log measures against. Bring popcorn. Bring your page plan for the free
teardown slot, too.

💬 Questions about your own page plan? Chat with our AI assistant now: t.me/quantumcx_growth_bot — instant answers, free trial, no card.

The Uniqueness Budget: Why Some Programmatic Pages Survive Spam Updates

Baibhab Bose — Sat, 19 Sep 2026 05:01:27 +0000

You build 1,000 programmatic pages. Five months later an update lands and half of them vanish from the index overnight. Meanwhile a competitor with the same number of pages barely blinks; their scaled pages hold rankings right through the same update. The difference is not luck, not backlinks, not the size of the site. It is how much distinct value each individual page carries before anyone ever links to it.

Call it a uniqueness budget. Every page you generate draws down from one pool: the amount of real, page-specific substance you can put behind it. Spend it thinly and the update wipes you. Spend it well and scale stops being a weakness. Treat these four properties as design constraints, not as things to worry about later.

Constraint one: one page, one job

The clearest failure pattern of wiped pages is that they are the same body of text with a city name swapped into one paragraph. The page passes a human scan but fails the deeper test: it says nothing that its thousand siblings do not also say.

So give each page a uniqueness rule: it must contain at least one claim no other page on the internet makes about that topic. Concrete sources that scale well:

Local specifics that are hard to fake: actual transit context, neighborhood references, real opening hours, regional pricing.
Entity relationships: the page connects the thing, the place, and the person in a way a generic page does not.
A specific answer that surrounding pages route around because it takes effort.

A fast test before you publish any template: strip the city name and the page number. If the page reads identically to its neighbor, the template is not generating pages, it is renaming them. Fix the template, not the individual pages.

Constraint two: pages come from a dataset, not from a template

The sites that survive treat each page as a rendered view of one row in a real database. Names, prices, latitudes, schedules, contact details, and the copy blocks that reference those fields all live in structured rows. When the data is real, every page describes something that actually exists in the world, and the page works as a reference document rather than as a placeholder.

This is the difference between a table you filled with facts and a template you filled with synonyms. Set the constraint when you design the schema: every page must have a data backbone with at least three non-obvious fields unique to that row. Then let the page render those fields so the page literally cannot be produced without its data. If a row is empty of substance, that page should not exist yet.

Constraint three: a human sees the page before it goes live

The updates that thin out programmatic sites are built to find unhelpful content at scale. A mechanical production line with no checkpoint in front of the publish button is exactly the signal they are designed to catch. Put a person in the loop.

Not to rewrite every page; to sample the batch against the source data. Verify a random set against the dataset for hallucinated specifics, check that the generated copy does not invent a fact, and fix the pattern when a batch fails rather than the individual page. This acts as a forcing function: if a human cannot sanity-check the output of a batch, the batch is too large or the template too thin. Make review a hard design constraint, not a nice-to-have, and the review becomes the quality ceiling that protects you.

Constraint four: velocity that matches your review capacity

Publishing five thousand pages in a week and then going quiet looks, to a ranking system, like an automation burst. So does growing at a pace your review loop cannot sustain. The alternative that wins is steady, reviewable output: pages you can fact-check, maintain, and update.

Set your ceiling with a simple formula: pages per week equals the review capacity of your available humans, never the generation capacity of your script. A page that goes stale is also a liability over time, so budget for updates, not just launches. Slow, correctable growth survives long after a burst has been rolled back.

The method you can apply this week

For any programmatic plan, write four lines before you generate a single page:

What unique data lives in each row?
What source does that data come from and how current is it?
Who reviews a sample of each batch, and at what cadence?
What is the maximum weekly volume that same person can actually review?

If you cannot fill in all four lines, the plan will not survive an update. If you can, the pages are no longer anonymous template output. They are a database, checked by a human, published at a sustainable pace. That is not a trick and not a hack. It is simply giving each page a reason to exist, and letting the update punish the sites that never bothered to think about why they were publishing in the first place.

Full disclosure: I work on pSEO Engine, which does exactly this at https://pseo.quantumcx.net, turning a query space into a page plan, generating a landing page per row from your dataset with a review step before you publish to your own domain, plus rank tracking and AEO/GEO audits. A free 7-day trial (75 AI Actions, no card) and BYOK on a free Gemini key let you test the same constraints on your own pages before committing.

How to refresh hundreds of pages without getting wiped: the template-batch method

Baibhab Bose — Sat, 19 Sep 2026 04:59:48 +0000

You have 500 pages live. Traffic was fine in March. Last month you opened Google Search Console and half your impressions had quietly flatlined. Google didn't penalize you for spam — it looked at 500 pages that all say roughly the same thing and decided most of them weren't worth showing. That's the real wipe: not a penalty, just slow irrelevance.

You can't hand-write 500 refreshes. You also can't let them rot. The fix is a template-batch method built around one idea: most of your pages are the same page with different facts. So you fix the template once, then batch-verify each page instead of rewriting it.

Step 1: The 90-day GSC triage

Export the last 90 days from Google Search Console — queries, impressions, clicks, position — and classify every page into four buckets:

Keep: impressions are stable or rising, clicks are happening. Do nothing.
Stale: impressions dropped 30%+ versus 60–90 days ago but the page targets a still-valid query. Needs a refresh.
Dupes: two or more pages target the same intent. Merge, don't duplicate.
Dead: impressions near zero, query intent is gone (nobody searches "flip phone ringtones" anymore). These get merged into a relevant neighbor and 301'd.

Sort by impressions, not clicks. A page with zero clicks can still be your best page — it just ranks poorly. The goal of this pass is to find out which pages Google is testing and which it has given up on.

Step 2: The intent drift check

Before you rewrite a single Stale page, verify its intent is still correct. Look at the current top 5 results for your target keyword. Answer two questions:

Are the top results listings pages, reviews, or informational? If your target keyword now returns a video carousel and how-to articles, but your page is a comparison table, your intent has drifted even if the keyword hasn't changed.
Do the page titles in the SERP use a phrase you're missing? Those phrases come straight from user expectations.

Intent change is the #1 silent killer of refreshes. You can update the content, speed up the page, and add schema until you're blue — if the query now expects a different format, the refresh won't move the needle.

Step 3: Merge-with-301 instead of deleting

The D and Dupes buckets rarely deserve a fresh page. Deleting wastes whatever links and history they have; keeping them drains crawl budget. The answer is merge-with-301:

Pick the surviving page — the one with the strongest mix of authority, backlinks, and current traffic.
Move any useful content from the dead page into the survivor (a section, a table, a handful of strong FAQs).
301 the dead URL to the survivor and update internal links to point at the survivor.
Let the 301 pass link equity and let the survivor inherit the query.

Every time you delete instead of merging, you're burning equity you already paid for.

Step 4: Protect your money slugs

Slugs are part of the URL and therefore part of the ranking signal — and they're also what users read. Your business-critical pages (typically the money pages you convert on) should keep their forever-slug. When you merge into a different page entirely, you should own the conversion-relevant URL yourself on the same domain.

Step 5: Fix the shared template once

This is the memorable move. When you refresh a page that was built from a template, you treat the template as a codebase, not the page as an isolated doc. In the old model your 500 pages were a pile of unique creations; in the template model they're 5 distinct templates being filled by data. Fix the shared template once, and hundreds of pages fix together.

A concrete template-level fix: variable insertion. Web 2.0 marketing pages are identical except for the city or keyword — Google compares the ratio of unique to duplicated content across the page, and near-identical pages get filtered. So you add real data, not just keyword swaps: prices, local differences, unique FAQs, or a genuine answer to the question the template headline doesn't address. One fix in the template cascades to every page that uses it.

Step 6: Re-verify in batches of 25

After the template fix, don't eyeball 500 pages. Verify in batches of 25, because you only need a 25-page sample to catch most template-level problems (missing schema, duplicated title tags, broken variable substitution). The work is now checking whether the data filled in correctly, not writing marketing copy.

Working this way, a 500-page project looks like: 280 pages keep, 120 stale pages get a template-triggered refresh, and 100 get merged into the survivors.

Full disclosure: I work on pSEO Engine, which does exactly this kind of programmatic refresh at scale — turning a query space into a page plan and generating an AI landing page per row, then reviewing and publishing to your own domain. There's a case study (MUA Bishal, a bridal/event makeup artist in India) that published 500 pages live since 31 Aug 2026 with 432 keywords currently tracked. You can see it at https://pseo.quantumcx.net.

If you have hundreds of pages, you don't have a content problem. You have a systems problem — and systems are fixable once you stop treating every page as a separate emergency.

Why most freelance contracts don't actually protect you from scope creep or non-payment (and what to put in one that does)

Baibhab Bose — Sat, 08 Aug 2026 20:31:50 +0000

If you freelance or run a small agency, you've probably lived one of these two moments. A client asks for "just one small thing" that's technically outside what you quoted — you do it because saying no feels awkward, and then it happens again. Or you finish the work, send the invoice, and get silence, or excuses, or a client who's suddenly hard to reach.

These aren't rare. Ignition's 2025 Agency Pricing & Cash Flow Report (270 agencies surveyed) found 57% of agencies lose $1,000-$5,000 a month to unbilled scope creep, and 78% say they rarely or only sometimes charge for out-of-scope work at all. Separately, a Freelancers Union / Authors Guild / Graphic Artists Guild survey (May 2022, surveying New York freelancers) found 62% had experienced non-payment, and 53% of those lost $10,000 or more.

I went looking at why, across public freelancer complaints — Hacker News threads, G2 and Capterra reviews, interview series — and the pattern wasn't "I didn't have a contract." Most people had one. What they didn't have was the specific clause that would have prevented the problem they actually ran into.

The scope-lock gap. A generic contract usually has a vague line like "additional work may be billed separately." Clients learn to ignore that sentence — it doesn't define what's in scope in the first place, so there's nothing to point back to when a request falls outside it. A real scope-lock clause pairs a specific, itemized deliverables table with a defined change-order process: any request outside that table gets a written price before any work starts. The difference isn't the existence of a clause — it's whether the clause actually does anything when tested.

The non-payment gap. Most freelance contracts mention payment terms, but skip three things that make non-payment actually costly to the client instead of just annoying to you: a real late-fee clause with a specific percentage and grace period, a deposit requirement paired with a script for asking for it without the conversation feeling like a confrontation, and a defined escalation process for when an invoice goes quiet — so you're not improvising a demand letter for the first time under stress.

Why "just be firmer next time" doesn't fix it. That's the plan most freelancers already have, and it's also why the stats above exist. Good intentions don't survive a live conversation with a client you like, especially with no script ready and no contract clause to point back to. The fix isn't willpower — it's having the boundary already written down, agreed to, and signed before the moment arrives.

This is exactly the gap I built Scope Lock to close: 15 fill-in-the-blank contracts (5 core disciplines, 10 more industry-specific ones on the Premium tier) with scope-lock, change-order, late-fee, and deposit clauses already written in, plus 23 word-for-word scripts for the conversations themselves, a pricing calculator, and a 5-stage non-payment recovery kit for when an invoice does go quiet.

One honesty note, since this is exactly the kind of product where it matters: none of this is legal advice. Contract enforceability varies by state and country, and every template includes a disclaimer recommending a licensed attorney review it before you rely on it for a real engagement. What this gives you is a real starting point built around the two specific failure modes above — not a blank page, and not a generic template that never had this language to begin with.

Scope Lock launched this week at $67-$397 depending on tier, one-time payment, 30-day money-back guarantee, no subscription. If any of the above sounds familiar, I'd genuinely like to hear about it — https://baibhab3.gumroad.com/l/scope-lock?utm_source=article&utm_medium=blogpost&utm_campaign=launch

This post was originally published on Medium.