DEV Community: RankLoop

Smash Story: my rank tracker spent weeks reporting ">100" for keywords sitting on page 2

RankLoop — Fri, 17 Jul 2026 12:41:04 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The bug that never crashed

I run a small Google rank tracker (RankLoop). Its one job: tell you your position for each keyword, daily, and email you when something moves.

For weeks it reported "not in top 100" for keywords that were actually sitting on page 2. Every request returned 200. Rows were written. Dashboards updated. The alert emails — the core feature — simply never fired, because nothing ever "moved". The product looked perfectly healthy while being wrong for every user it had.

The cause

Google quietly removed support for the 100-results-per-page parameter. My SERP provider kept accepting num: 100 without an error — and returned ~10 results. My code scanned the ten results it got, did not find the domain, and recorded ">100". Silently. For every keyword ranking 11-100.

The smash

Pagination, with two traps that will bite anyone doing this:

Positions restart on every page — page 2 returns 1-10 again, so the absolute position is (page - 1) * 10 + position.
Page 1 regularly returns 9 results (SERP features absorb slots). My first fix stopped paginating on a short page, which meant it stopped after page 1 almost every time. Only a fully empty page means you are done.

What caught the bug was not a log or a monitor: it was comparing my numbers against Search Console, which said position 17 while my tool said ">100". Two instruments, one truth.

Before / after

Before: zero alert emails, ever. The morning the fix shipped: the alerts fired for real for the first time — and one of my few real users got an email telling them their main keyword had climbed to #2. That email was the entire product finally working as promised, three weeks late.

Full technical write-up with the credit-economics fallout (a not-found keyword costs 10x a ranked one): https://dev.to/rankloop/google-quietly-killed-num100-and-my-rank-tracker-lied-for-weeks-2d38

What I keep

If your product measures something, run a second instrument beside it and make them argue. A crash pages you; a wrong number just sits there looking healthy.

Google quietly killed num=100 — and my rank tracker lied for weeks

RankLoop — Mon, 13 Jul 2026 16:19:26 +0000

This is part 2 of the RankLoop build log. Part 1 covered the stack. This one covers the week my product lied to every user it had — and how I found out.

The symptom

A user (fine: me, dogfooding, plus a few real ones) reported that keywords sat at ">100" for weeks and never moved. Meanwhile Google Search Console showed those exact queries at positions 17–48. Two sources, same keyword, wildly different answers. And because nothing ever "moved", the alert emails — the core feature — never fired once.

The checks ran daily. Every request returned 200. Rows were written. Dashboards updated. Everything looked healthy.

The cause

My SERP provider call asked for 100 results per page:

body: JSON.stringify({ q: term, gl: country, num: 100 })

And for a long time that worked. Then Google removed support for the 100-results-per-page parameter, and SERP APIs built on top of it started returning ~10 organic results per request — while still accepting num: 100 without an error.

So my code happily scanned the 9–10 results it got, didn't find the domain, and recorded "not in top 100". For every keyword ranking 11–100. Silently. For weeks.

The fix (with two gotchas)

Pagination. Obvious in hindsight, but two details will bite you:

1. Positions restart on every page. Page 2 returns positions 1–10 again, not 11–20. You have to compute the absolute position yourself:

const absolute = (page - 1) * RESULTS_PER_PAGE + item.position;

2. Page 1 regularly returns 9 results, not 10. Featured snippets and other SERP furniture absorb organic slots. My first version stopped paginating when a page came back short — which meant it stopped after page 1 almost every time. The only reliable stop signal is a fully empty page:

if (organic.length === 0) break; // short pages are normal, empty means done

With early exit when the domain is found, a keyword ranking #17 costs 2 requests instead of 10.

The part nobody warns you about: cost

Here's the brutal asymmetry: a keyword that ranks #5 costs 1 request to verify. A keyword that ranks nowhere costs the full 10 — you have to scan all 100 positions to honestly say "not in top 100". Not-found keywords are your most expensive ones, and new users add lots of them.

My fix: adaptive depth. If a keyword's previous check already said not-in-top-100, the next check only scans the top 30, and a full top-100 sweep runs once a month to catch late climbers. New keywords and ranking keywords always get full depth. That one change cut the weekly API bill roughly in half without touching the product promise.

And because this failure mode was silent, I added the alarm I should have had from day one: if an entire check run fails (quota exhausted, key revoked, provider down), the system emails me instead of quietly freezing every dashboard.

The lesson

Your pipeline can be green — 200s everywhere, rows written, charts moving — and still be wrong. The bug wasn't in my code's logic; it was in an assumption about an upstream API that changed under my feet without an error message.

The only thing that caught it was comparing against an independent source of truth (Search Console). If your product measures something, find a second instrument that measures the same thing a different way, and check them against each other regularly. Mine now disagree by a position or two (normal SERP variance); the day they disagree by 40 again, I'll know in hours, not weeks.

Funny epilogue: the morning the fix shipped, the alert emails fired for real for the first time — and one of my users learned their main keyword had climbed to #2. That email was the product doing, at last, exactly what the comparison pages promise it does.

If you track rankings and want to sanity-check whether your current tool has the same silent bug: check any keyword you know ranks on page 2, and see if your tracker says ">100". You might be surprised.

Questions about the pagination details or the credit math — ask away. Part 3 will probably be about what happened when real traffic hit the free plan.

I'm building a $19 rank tracker in public — the stack, and why "daily" is harder than it sounds

RankLoop — Mon, 06 Jul 2026 09:05:02 +0000

I do SEO for my own side projects, and for years I bounced between rank trackers. The expensive ones (Ahrefs, Semrush) are overkill when all I want is "did my 200 keywords move today?". The cheap ones had two recurring problems that drove me up the wall:

"Daily" that wasn't daily. A lot of budget trackers quietly refresh every 2–5 days and still call it daily. When you're reacting to a Google update, that lag is the whole game.
Billing friction. Cancel-by-email-only, surprise charges after you thought you'd stopped, keyword counts that double-count mobile vs desktop so your "500" is really 250.

So I started building the thing I actually wanted. It's called RankLoop, and this is the build log — the stack, the decisions, and the unglamorous parts that turned out to matter most.

I'm writing this at the start, not after some victory lap. No revenue screenshots here. It's live, the free plan is open, and I'm looking for people to poke holes in it.

The one design decision everything else hangs off

Most trackers store your position for a keyword: "you're #7." I decided to store the entire top 10 of every search, on every check.

That sounds like a lot more data (it is), but it's the feature I always wished I had: when you drop from #4 to #7, you can look back and see exactly which page moved in above you and when. Ranking is relative — knowing "I dropped" is useless without "because these three competitors climbed."

Concretely, each check writes a row with the keyword, your position, and a JSON snapshot of the top 10 (URL + title + position). History becomes a time series you can diff. It costs storage, but storage is cheap and the insight isn't.

The stack (and why, as a solo dev)

Nothing exotic. The bias was: fewer moving parts, fewer things that can page me at 2am.

Next.js 16 on Vercel. App Router, route handlers for the API, one deploy target. As a team of one, "git push and it's live" is worth a lot.
Supabase for Postgres + Auth + Row Level Security. More on RLS below — it's doing more work than any other single piece.
Lemon Squeezy as the billing layer. This one deserves a paragraph.
Resend for transactional email (alerts, welcome, support). This one deserves a cautionary paragraph.

Why a Merchant of Record instead of Stripe directly

If you sell software to people in the EU as a solo founder, you inherit VAT/tax obligations that are genuinely miserable to handle correctly. A Merchant of Record (Lemon Squeezy, Paddle) becomes the seller of record and handles that global tax mess for you. You trade a bit of margin for not having to become a part-time tax compliance department. For a one-person shop that trade is a no-brainer.

It also let me make cancellation self-serve from the dashboard in one click — which, given that billing traps were half my motivation, felt non-negotiable.

RLS is the whole security model, not a nice-to-have

Every table that holds user data (domains, keywords, checks, reports) has Row Level Security policies so a user can only ever read/write their own rows — enforced in the database, not in my application code. The app could have a bug; the database still won't hand user A's keywords to user B.

The subtle bit: the columns that decide a user's plan and billing status live on the profile row, and those are only writable by the service role (the billing webhook), never by the user's own session. Otherwise anyone could PATCH their own row to "plan: pro" and give themselves the paid tier for free. If you're building multi-tenant on Supabase, audit that specific thing — the gap between "RLS is on" and "RLS is actually scoped correctly" is where the bugs live.

The email deliverability rabbit hole

Here's the one that ate a full day and taught me the most.

Transactional email "works" in dev instantly, so you assume it's fine. Then you realize your first emails went out from a shared sandbox sender and landed straight in spam — because they weren't authenticated for your domain. Fixing it meant actually understanding the three records everyone waves at:

SPF — which servers are allowed to send for your domain.
DKIM — a cryptographic signature proving the mail wasn't forged in transit.
DMARC — what receivers should do when SPF/DKIM fail, plus reporting.

Get those set up on your sending subdomain before you send a single real email, or you'll poison your domain reputation with your own test messages. Domain reputation is slow to build and slower to repair. I learned this the annoying way so you don't have to.

Where it actually is right now

Honest status:

Free plan: 10 keywords, checked daily for your first week, then every Monday. No card.
Paid: $19/mo for 200 keywords across 5 domains, all checked daily; $49/mo for 500 keywords across 20 domains with 300 checked daily; $99/mo for 1,000 keywords across unlimited domains with 600 checked daily. On the plans above Starter, the rest are checked every Monday.
Full top-10 history, one-email alerts (only when a keyword enters/leaves the top 10 or crosses your threshold — not daily noise), shareable read-only report links for clients, CSV export.

What it is not: a keyword research tool, a backlink index, or an all-in-one suite. It tracks Google positions reliably and gets out of your way. That's the whole pitch.

If you're weighing it against a specific tool, I keep honest comparison pages with the real pricing math — the Wincher comparison is the most complete one, including where Wincher is genuinely the better pick.

What I'd love feedback on

If you track rankings for your own projects or clients, I'd genuinely like to know:

Is stored top-10 history something you'd use, or do you only care about your own number?
What's the smallest feature that would make you switch from whatever you use now?

You can try the free plan (no card) at getrankloop.com and tell me where it falls short. I'm building this in the open, so critical feedback is the useful kind.

More build-log posts to come — next one is probably the scheduling layer that makes the daily checks actually fire on time, which was less trivial than I expected.