DEV Community: Ujwal Jayendran

I built a 200-page programmatic SEO site. Bing out-ranked Google 2.6X .

Ujwal Jayendran — Fri, 19 Jun 2026 18:00:00 +0000

Ten weeks ago I launched a niche reference site on a fresh .in domain. No backlinks, no budget, no audience. Just a Next.js static export sitting on Cloudflare Pages.

I expected the usual story: Google ignores you for months while you claw your way out of the sandbox.

Instead I got a result I haven't seen written up anywhere — Bing started ranking me within days, and ten weeks in, it's sending me 2.6× more clicks than Google. Not 2.6% more. Two-point-six times.

Here's the data, the architecture, and the three lessons that surprised me.

What I built

The site analyzes Indian life-insurance policies — specifically, it answers a question millions of policyholders have and can't easily answer: should I keep this policy, surrender it, or stop paying premiums and let it sit?

The underlying data is public but published terribly. The insurer releases an annual actuarial valuation circular — a scanned PDF — declaring bonus rates per policy "group," not per plan. Mapping those rates to individual plans, structuring them, and building calculators on top is genuinely tedious work that nobody had done well.

That's the whole programmatic-SEO thesis in one sentence: find public regulatory data trapped in a bad format, structure it, and build the queryable tool that should already exist.

The build:

34 plan pages (one per insurance plan)
34 bonus-rate pages (the data tables people actually search for)
7 calculators (maturity value, surrender value, hold-vs-surrender analysis)
~100 explainer guides
200+ total URLs

Stack: Next.js with output: 'export' (fully static), Tailwind, deployed to Cloudflare Pages. Hosting cost: ₹0. Domain: about ₹1,000/year. That's the entire infrastructure bill.

The architecture lesson: "add a plan = add a JSON entry"

The trap with a site like this is writing per-plan logic. Plan A uses one bonus model, Plan B uses another, Plan C has survival payouts on a schedule that changes by term. If you hard-code each plan's math, you've signed up for 34 bespoke calculators and a maintenance nightmare.

So I didn't. Every plan is a JSON entry with classification tags:

{
  "plan_number": "165",
  "classification": {
    "bonus_model": "loyalty_addition",
    "premium_model": "regular",
    "benefit_structure": "endowment",
    "sa_derived_from_premium": true,
    "analyzer_mode": "loyalty_addition"
  }
}

One universal calculator engine reads the tags and routes to the right modules:

function calculateBonus(plan, term, sa, yearsPaid) {
  switch (plan.classification.bonus_model) {
    case "srb_fab":            return srbFabBonus(plan, term, sa, yearsPaid);
    case "loyalty_addition":   return loyaltyAddition(plan, term, sa, yearsPaid);
    case "guaranteed_addition":return guaranteedAddition(plan, sa, term);
    case "ga_plus_la":         return gaPlusLoyalty(plan, sa, term, yearsPaid);
    case "non_participating":  return { total: 0 };
    default: throw new Error(`Unknown bonus model: ${plan.classification.bonus_model}`);
  }
}

Adding a new plan means adding a JSON object. No new components, no new routes — getStaticPaths generates the page, and the engine already knows how to compute everything from the tags.

The hard part wasn't the code. It was discovering how many genuinely different calculation models exist behind a category that looks uniform from the outside. "Endowment plans" sounds like one thing. It's at least five, with different bonus structures, premium-payment models, and payout schedules. Modeling that taxonomy correctly was 80% of the work — and it's the part that's defensible, because nobody else bothered.

Lesson 1: Bing has no sandbox (and rewards structured data immediately)

Here's the week-over-week click data since launch:

Week	Bing clicks	Google clicks
3	22	21
4	72	90
5	60	90
6	165	77
7	217	118
8	288	144
9	348	154
10	325	123

Bing went from 22 → 325 clicks/week in seven weeks. It started ranking my pages within days of indexing — no probation period. Google made me wait roughly three weeks before showing meaningful impressions, then rationed growth carefully.

My read on why: Bing's ranking appears to weight exact content-to-query relevance and structured data more heavily, and domain age / authority less heavily, than Google does. My pages are basically structured data tables answering very specific queries. That's Bing's sweet spot. Google, meanwhile, is appropriately skeptical of a brand-new domain spinning up 200 templated pages — that pattern also describes low-quality content farms, so it slow-walks you until behavioral signals prove otherwise.

If you're launching programmatic content, submit to Bing Webmaster Tools on day one. Most developers treat Bing as an afterthought. For this category of site, it may be your primary channel for the first few months — and it's a cleaner signal of whether your content is actually good, because it's not muddied by a months-long trust delay.

Lesson 2: AI Overviews are quietly killing explainer content

This is the finding I least expected, and it changed my content strategy completely.

I split my pages into two buckets and looked at click-through rate by bucket:

Data pages (bonus-rate tables, calculators — specific numbers):

Page type	Position	CTR
Top bonus-rate table	~7	4.6%
"Bonus rates 2026" data page	~8	8.8%
Plan calculator	~10	3.0%

Explainer pages (how-to and conceptual guides):

Page type	Position	CTR
"Should I surrender my policy"	~7	0.0%
"X vs Y, which is better"	~8	0.1%
"How to revive a lapsed policy"	~9	0.0%

Same domain. Similar positions on page one. The explainer pages get effectively zero clicks.

The reason is the AI Overview (and featured snippets before it). For a conceptual question — "should I surrender" — the search engine now synthesizes an answer at the top of the page. The user reads it and never scrolls to your result, even at position 6. Your ranking is worthless because the click never happens.

But for "what is the exact bonus rate for plan 165 in 2026," the user needs a specific figure for their specific situation. An AI summary saying "bonus rates vary by plan and term" doesn't satisfy that. They click through to get the actual number.

The strategic takeaway: in the AI-answer era, content that summarizes or explains is depreciating. Content that contains specific structured data people need to extract and act on is AI-resistant. I stopped writing explainer guides and doubled down on data pages and calculators. If you're planning a content site in 2026, weight your roadmap heavily toward "specific data the user needs for their case" and away from "here's how X works."

Lesson 3: the authority flywheel starts with one organic citation

Around week ten, I noticed a referral from another reference site I'd never heard of. They'd independently built their own dataset page and cited mine as the source for a subset of figures the official circular doesn't publish — with a dofollow link and an explicit note that their calculators consume my numbers.

I didn't ask for it. Their team evaluated the available sources for that data and concluded mine was the one worth citing.

That's the flywheel: good structured data → organic citations → domain authority → better rankings → more traffic → more citations. The first quality backlink is the hardest to earn, and you can't really shortcut it with outreach for this kind of site — you earn it by having data nobody else compiled correctly.

It also created a responsibility I hadn't considered: my numbers are now load-bearing for someone else's site too. If I have an error, it propagates. That pushed me to build an automated verification layer — feeding each page's content to an LLM acting as a domain expert to flag any figure that contradicts the source circular. Worth doing anyway; doubly worth it once other people depend on your data.

The honest part: monetization has been a slog

I'd be lying if I painted this as a clean win. The traffic curve is great. Turning it into money has been frustrating.

I applied to the obvious ad network three times. Rejected three times — each time with the same generic "doesn't meet program policies" message. The most likely cause: a young .in domain plus 200+ templated pages matches the heuristic for "scaled content," regardless of whether the content is actually good. New domains in this shape routinely need 3–6 months before approval.

The mid-tier networks I'd have pivoted to have mostly raised their minimums recently — one popular option moved its floor to 250k monthly users this year. So the realistic path is: wait out the domain-age gate, keep the traffic compounding, and qualify for a premium network once I cross ~10k monthly sessions (which, at the current growth rate, lands right around the seasonal traffic spike).

The lesson if you're building one of these: the monetization clock starts months after the traffic clock. Plan for that gap. The flip side is that the cost structure is so low (₹1,000/year all-in) that you can let the asset compound for a long time without pressure. Most niche sites die because the builder quits during the monetization gap, not because the traffic fails.

Takeaways for anyone building programmatic SEO in 2026

Find public data trapped in a bad format. Regulatory filings, government registers, actuarial circulars. The worse the official format, the bigger your opportunity.
Model the taxonomy before you write code. The defensible work is discovering the real structure behind a category that looks uniform. "Add an entry = add a row" architecture follows from that.
Submit to Bing on day one. It may carry you for the first few months while Google decides whether to trust you.
Build data pages, not explainer pages. AI Overviews eat the latter. They can't replace the former.
Expect a monetization gap. Traffic comes first by months. Keep costs near zero so you can wait it out.

The site is licpolicyadvisor.in if you want to see the structure — it's part of a small portfolio of data-utility sites I build under NicheLabs. Happy to answer questions about the static-export setup, the classification engine, or the Bing-vs-Google divergence in the comments.

If you've seen the same Bing-beats-Google pattern on a new domain, I'd love to know — I can't tell yet whether it's specific to structured-data sites or a more general new-site phenomenon.

How I Built a Programmatic SEO Site with 16,750 Pages Using FastAPI and PostgreSQL

Ujwal Jayendran — Tue, 26 May 2026 17:31:40 +0000

A deep dive into building BSBFinder.com — a free Australian BSB number lookup tool — from data pipeline to deployment.

Every Australian bank transfer requires a BSB number — a 6-digit code identifying the bank and branch. There are over 16,750 active BSB codes, and the existing lookup tools were either clunky, ad-riddled, or buried inside bank websites.

So I built BSBFinder.com — a fast, free tool that lets you search any BSB code and get the bank name, branch address, SWIFT code, and payment capabilities instantly.

Here's how I built it.

The Stack

Backend: FastAPI (Python)
Database: PostgreSQL
Templating: Jinja2 (server-side rendered)
Reverse Proxy: Caddy
Infrastructure: Docker on AWS Lightsail
Data Source: AusPayNet (official BSB registry)

I chose server-side rendering over a SPA framework deliberately. For a programmatic SEO site with 16,750+ individual pages, SSR gives you crawlable HTML that search engines can index immediately — no JavaScript rendering required.

The Data Pipeline

The foundation of the entire project is the BSB dataset from AusPayNet, the official body that manages BSB allocations in Australia.

The pipeline works like this:

Extract — Parse the official BSB data file (CSV format with bank codes, branch names, addresses, states, postcodes, and payment method flags)
Enrich — Add SWIFT/BIC codes by mapping BSB prefixes to their parent bank's international codes
Snapshot — Store timestamped snapshots to track historical changes (branch closures, mergers, relocations)
Load — Upsert into PostgreSQL with proper indexing

The snapshot system is one of the features I'm most proud of. Banks merge, branches close, and BSB codes get reassigned. By storing periodic snapshots, BSBFinder can show users when a BSB was last changed and what changed — useful for anyone dealing with an old BSB that no longer works.

# Simplified snapshot comparison logic
def detect_changes(current_snapshot, previous_snapshot):
    changes = []
    for bsb, data in current_snapshot.items():
        if bsb not in previous_snapshot:
            changes.append({"bsb": bsb, "type": "added"})
        elif data != previous_snapshot[bsb]:
            changes.append({"bsb": bsb, "type": "modified", 
                          "old": previous_snapshot[bsb], "new": data})

    for bsb in previous_snapshot:
        if bsb not in current_snapshot:
            changes.append({"bsb": bsb, "type": "discontinued"})

    return changes

Programmatic SEO: 16,750 Pages from Templates

The core SEO strategy is programmatic — each BSB code gets its own page generated from a template. But "programmatic" doesn't mean "thin." Each BSB page includes:

The BSB number, bank name, and full branch address
SWIFT/BIC code for the parent bank
Payment method support (BECS, NPP, Direct Entry)
Nearby branches from the same bank
A FAQ section with the most common questions for that specific BSB
Schema.org structured data for rich search results

The key lesson I learned: Google treats 16,750 near-identical pages very differently from 16,750 pages that each have unique, useful content. The nearby branches section, the dynamic FAQ, and the payment capability details make each page genuinely different.

URL Structure

I went with a flat, readable structure:

/bsb/062-000    → Individual BSB page
/bank/cba       → All BSBs for Commonwealth Bank
/state/nsw      → All BSBs in New South Wales
/suburb/vic/melbourne → BSBs in Melbourne, VIC
/postcode/2000  → BSBs in postcode 2000

This creates natural internal linking — each BSB page links to its bank page, state page, suburb page, and postcode page, creating a deep web of interconnections that search engines love.

Sitemaps at Scale

With 16,750 BSB pages plus bank pages, state pages, suburb pages, postcode pages, and guide articles, the total URL count exceeds 20,000. Google's sitemap limit is 50,000 URLs per file, but I split them into batches of 5,000 for better crawl management.

/sitemap-index.xml
  ├── /sitemap-bsb-1.xml     (5,000 BSB pages)
  ├── /sitemap-bsb-2.xml     (5,000 BSB pages)
  ├── /sitemap-bsb-3.xml     (5,000 BSB pages)
  ├── /sitemap-bsb-4.xml     (remaining BSB pages)
  ├── /sitemap-banks.xml      (bank pages)
  ├── /sitemap-locations.xml  (state, suburb, postcode pages)
  └── /sitemap-guides.xml     (editorial content)

I submitted these in batches over several days rather than all at once — it helps avoid overwhelming the crawler and triggering spam flags.

The Tools

Beyond the core lookup, I built several tools that add genuine utility:

BSB Validator — Verify a BSB number is valid before making a transfer (checks format, prefix validity, and whether the BSB is still active)
Bulk Lookup — Upload a CSV of BSB numbers and get all details back in one go (useful for payroll and accounting)
BSB Decoder — Break down what each digit means (first 2 = bank, next 1 = state, last 3 = branch)
Branch Compare — Side-by-side comparison of two branches
SWIFT Lookup — Find the SWIFT/BIC code for any Australian bank

Each tool has its own page with its own SEO value. The validator alone generates meaningful search traffic for queries like "check BSB number" and "BSB validator."

Performance Considerations

For a site that serves 16,750+ unique pages, performance matters. Here's what I optimized:

Database queries: Every BSB lookup is a simple primary key query — O(1) with PostgreSQL's B-tree index. Response times are under 5ms for any BSB lookup.

Caddy as reverse proxy: Caddy handles TLS termination, HTTP/2, and automatic HTTPS. It also serves static assets directly without hitting the FastAPI backend.

Docker deployment: The entire stack runs in Docker containers on a single AWS Lightsail instance ($5/month). For the traffic levels of a niche utility site, this is more than sufficient.

# docker-compose.yml (simplified)
services:
  web:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db
  db:
    image: postgres:15
    volumes:
      - pgdata:/var/lib/postgresql/data
  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile

Free REST API

I also built a free REST API for developers who need BSB data programmatically. It supports single lookups, search, and bank/branch listing — all without authentication for reasonable usage.

# Look up a BSB
curl https://bsbfinder.com/api/bsb/062-000

# Search by bank name
curl https://bsbfinder.com/api/search?q=commonwealth+sydney

This serves a dual purpose: it's genuinely useful for developers building Australian fintech products, and it creates an incentive for technical blogs and documentation to link to BSBFinder as a data source.

Lessons Learned

1. Server-side rendering wins for programmatic SEO. SPA frameworks add unnecessary complexity when your primary goal is search engine indexing. Jinja2 templates are simple, fast, and produce crawlable HTML.

2. Content depth matters more than content volume. 16,750 thin pages will get flagged. 16,750 pages that each answer a specific question with unique data will get indexed and ranked.

3. Sitemaps are a conversation with search engines. Don't dump 20,000 URLs at once. Submit in batches, monitor indexing rates, and expand as trust builds.

4. Internal linking is your most powerful on-page SEO tool. Every BSB page links to its bank, state, suburb, and postcode pages. Every bank page links to all its branches. This creates a dense link graph that distributes authority across the entire site.

5. Build tools, not just pages. The validator, bulk lookup, and decoder tools generate their own search traffic and give users a reason to bookmark the site.

What's Next

I'm tracking historical BSB changes to build a "discontinued BSBs" section — useful for anyone trying to figure out where an old BSB number was redirected. I'm also exploring a premium API tier for high-volume users.

If you're building a programmatic SEO site, the key takeaway is this: every page should answer a question that someone is actually searching for. If it doesn't, it's filler — and search engines can tell.

Check out BSBFinder.com if you're curious, or hit the API docs if you want to build something with it.

Questions? Drop a comment below — happy to dive deeper into any part of the stack.