DEV Community: INOXXAI

How I fixed Googlebot indexing for a React + Leaflet SPA (without Next.js or Puppeteer)

INOXXAI — Tue, 14 Apr 2026 13:38:01 +0000

I built PlaceLabels — a crowd-sourced map
where locals drop honest reviews about their neighborhoods. Safety
ratings, cost of living, vibe. Real people, not algorithms.

About a week after launch I checked Google.

site:placelabels.com — 1 result. Just the homepage.

I had 35 city pages live. London, Mumbai, Tokyo, New York.
All rendering beautifully in the browser. All completely invisible
to Google.

Classic SPA problem. Here's exactly how I fixed it.

The setup

React 18 + TypeScript
Vite (not Next.js)
Leaflet + OpenStreetMap for the map
Deployed as static files + Express backend

Every page body was just:

Googlebot visits /mumbai. Waits for JavaScript. Gets impatient.
Leaves. No content indexed.

Why I didn't migrate to Next.js

Honestly? Time and complexity.

React-Leaflet has real SSR complications. The map is the core of
the product. I didn't want to spend two weeks migrating and
debugging hydration issues.

I needed something faster.

The fix: a dead simple Node.js prerender script

No Puppeteer. No headless browser. No 300MB Chromium download.

Just a Node.js script that runs after every Vite build and
manipulates the HTML output directly.

For each city it does five things:

Sets a unique <title>
Sets a unique <meta description>
Injects a real visible <h1> into the page body
Sets the correct canonical URL
Adds BreadcrumbList schema markup

Then writes the result to /dist/{city}/index.html.

// scripts/prerender.mjs
const cities = ['mumbai', 'london', 'new-york' /* 35 total */];

for (const city of cities) {
  const cityName = city.replace(/-/g, ' ')
    .replace(/\b\w/g, l => l.toUpperCase());

  const html = baseHTML
    .replace('PlaceLabels',
      `${cityName} Neighborhoods — Real Local Reviews | 
PlaceLabels`)
    .replace('',
      `${cityName} Neighborhoods
       Honest neighborhood reviews for ${cityName} from 
       locals who actually live there.
       `);

  fs.mkdirSync(`dist/${city}`, { recursive: true });
  fs.writeFileSync(`dist/${city}/index.html`, html);
}

Build script:

vite build && node scripts/prerender.mjs

Each city page is now a real 16KB HTML file. Googlebot reads it
instantly, no JavaScript required.

The 404 problem I almost missed

While digging into Google Search Console crawl stats I found
something alarming — 18% of all crawl requests were returning 404.

Nearly 1 in 5 URLs Googlebot tried to visit didn't exist.

Traced it down to three gaps in the Express server:

Gap 1 — Label pages were 404ing

When users drop a pin on the map, it creates a URL like:
/bangalore/cubbon-park-morning-jogs-peaceful

Express had no handler for these. Every one returned 404. Fixed by
adding an SSR handler that looks up the label slug in Postgres and
generates a full page with schema markup on the fly.

Gap 2 — No catch-all route

Express 5 doesn't accept bare * wildcards — it crashes on
startup. Added /{*wildcard} to serve the React SPA for any
unmatched route.

Gap 3 — express.static() was in the wrong place

This one was subtle. The catch-all was catching /sitemap.xml
and serving index.html instead of the actual XML file.

Google Search Console showed "Couldn't fetch" on the sitemap.

Fix was simple — move express.static() to before any route
handlers:

// CORRECT order
app.use(express.static(path.join(__dirname, 'dist'))); // FIRST
app.get('/city/:slug', cityHandler);
app.get('/{*wildcard}', spaHandler); // LAST

The unexpected bonus: user-generated SEO pages

Here's something I didn't plan for.

Every label a user drops on the map now has its own URL, its own
page, its own schema markup. Real content. Real data. Unique title
and description.
/bangalore/cubbon-park-morning-jogs-peaceful
/mumbai/bandra-safe-family-friendly
/london/shoreditch-expensive-vibrant-nightlife

Each one targets a long-tail keyword nobody else is competing for.
And every new user who drops a label creates another one
automatically.

445 label pages live right now. Growing daily.

Results

Before: 1 page indexed by Google

After one day of fixes:

974 pages discovered. Sitemap status: Success.

PageSpeed SEO score: 100/100 on both mobile and desktop.

The three things worth remembering

1. You don't need Next.js to fix SPA indexing.
A Node.js script that writes static HTML files is faster to
implement and just as effective for most use cases.

2. Express middleware order matters more than you think.
express.static() before route handlers. Always.

3. User actions can be SEO assets.
Every label drop is a new indexed page. Design your UGC with
this in mind from the start.

The full project is open source:
👉 github.com/InoxxAIsource/neighborhoodtruth-map

Live map: placelabels.com

Happy to answer questions about any part of the implementation.

How I Built a Real-Time Cricket Arbitrage Scanner (Bloomberg Terminal Style)

INOXXAI — Mon, 13 Apr 2026 13:23:28 +0000

The Idea

During IPL season, I noticed something interesting — different bookmakers often disagree on match probabilities. Bet365 might price CSK at 1.85 while Betfair has MI at 2.25. When you do the math, the combined implied probability drops below 100%, meaning you can back both sides across platforms and guarantee a profit.

This is called arbitrage — and it happens more often than you'd think in cricket. The catch? These windows last seconds, not minutes. You need a scanner watching odds across multiple platforms simultaneously.

So I built one. A Bloomberg Terminal-style dashboard that scans cricket odds in real-time and flags arbitrage opportunities the moment they appear.

Live site: cricketarb.com
GitHub: InoxxAIsource/cricedge-arb-scanner

The Tech Stack

I built this on Replit using their AI-assisted development tools, which let me move incredibly fast from concept to deployment.

Frontend: React + TypeScript + Tailwind CSS — dark Bloomberg Terminal aesthetic
Backend: Express.js handling odds API ingestion and serving static landing pages
ML Model: XGBoost trained on Cricsheet ball-by-ball data for independent match probability
Data: The Odds API for bookmaker odds + Polymarket for prediction market prices
Alerts: Telegram Bot API for instant signal delivery
Database: PostgreSQL via Drizzle ORM

The Arbitrage Math

The core logic is simple. For a two-outcome cricket match:

Arb% = (1/Odds_A) + (1/Odds_B)

If Arb% < 1.0 (100%), an arbitrage window exists. The profit margin is 1 - Arb%.

Example: CSK at 1.85 (Bet365) and MI at 2.25 (Betfair):

Arb% = (1/1.85) + (1/2.25)
     = 0.5405 + 0.4444
     = 0.9849 → 98.49%

That's a 1.51% guaranteed profit regardless of who wins.

What Made It Interesting: Prediction Markets

The real edge came from adding Polymarket to the scanning mix. Polymarket is a prediction market where people trade shares on match outcomes priced in cents (e.g., CSK at 52¢ = 52% implied probability).

Here's why it creates opportunities: Polymarket's trader base is crypto-native, not cricket-native. They update slower during live play compared to traditional bookmakers who have dedicated cricket trading desks. When a wicket falls in the powerplay, Bet365 adjusts in seconds — Polymarket might take 30-60 seconds. That lag is where arbitrage windows open.

The XGBoost Probability Engine

I didn't want to just compare bookmaker prices against each other. I wanted an independent probability estimate to know when ALL bookmakers were mispriced.

The XGBoost model is trained on Cricsheet ball-by-ball data and considers:

Current score and wickets
Overs completed
Run rate vs required rate
Batting team's historical performance in similar situations
Venue stats

When the model's probability diverges significantly from bookmaker consensus, it flags a value signal on top of the pure arbitrage detection.

The SEO Angle

This was also an exercise in building a content-driven product. The landing page at cricketarb.com is pure static HTML — no React shell, no client-side rendering. Google sees full content on first crawl.

I built a topic cluster architecture:

1 pillar page (3000+ word cricket arbitrage guide)
5 supporting blog posts targeting long-tail keywords
Internal links connecting everything into a tight topical web
Schema markup (SoftwareApplication, FAQPage, Article) on every page

The niche "cricket arbitrage" has near-zero competition in search. First-mover advantage is massive.

Key Learnings

Dev AI Agent is absurdly fast for going from idea to deployed product. The landing page, blog posts, and all SEO infrastructure were generated in a single session.
Static HTML > SPA for SEO. My React app returned empty HTML to crawlers until I switched the landing page to a static file served by Express.
Prediction markets are an underexplored arbitrage source. The speed gap between Polymarket and traditional bookmakers during live cricket is real and persistent.
Cricket is uniquely suited for arbitrage — high match volume (IPL has 74 matches), fast-changing in-play odds, and cross-platform opportunities that don't exist in most other sports.

Try It

Live scanner: cricketarb.com/terminal
Free Telegram signals: t.me/cricedge
GitHub: InoxxAIsource/cricedge-arb-scanner
Complete arbitrage guide: cricketarb.com/blog/cricket-arbitrage-guide

If you're into sports analytics, quantitative trading, or just love cricket — give it a star on GitHub. ⭐

What tools are you building with real-time data? Drop a comment below.