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

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

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.