lans.cloud is ~65 free single-purpose web tools — a Pokémon weakness calculator, a D&D encounter builder, a Roman numeral converter, a wall of classroom timers. It's young enough that Google Search Console only recently started producing real data: a few hundred impressions a day, a scatter of queries the pages surface for at positions 15, 30, 50.
That data is seductive. It reads like a to-do list. For every query you rank pos 28 on, there's a little voice saying if I just built the thing they're searching for, I'd climb. So I ran what I've come to call a query radar: pull every query the site surfaces for, cluster them by intent, and route each cluster to an action — tune the copy, build a feature, make a new page, or leave it alone.
The radar surfaced four clean-looking opportunities:
- Pokémon — people search "dual type chart" and "pokemon dual type weakness chart." Build a dual-type calculator.
- D&D — new queries "cr calculator 2024", "dnd 2024 cr calculator." Add support for the 2024 ruleset.
- JoJo — "stand stat wheel", "jojo stat circle." Add a stat-wheel visualization.
- Roman numerals — "3999 in roman numerals", "number to roman numerals." Add reference tables.
Four features, four demand signals, four winnable-looking long-tails. I could have opened four branches and started typing.
The habit that saved a day of work
Instead, before touching anything, I did the boring thing: I read the code. On any tool the radar flagged, the first move is grep, not git checkout -b.
- Dual-type Pokémon? The page's
<title>is literally "Pokémon Dual Type Weakness Calculator." You tap one or two types and it multiplies the matchups —effectiveness('ice', ['dragon', 'flying']) === 4. Built, unit-tested, and marketed in the meta description a month ago. - 2024 D&D rules? The encounter lib has a comment on line 1: "BOTH rule sets: the 2014 DMG… and the 2024 DMG." There's a UI toggle. There are two FAQ entries explaining the difference. Shipped.
- JoJo stat wheel? A six-axis SVG radar component called
StatWheel, plus a custom "stats maker" mode, plus the words "Stat Wheel & Stats Maker" in the page title.
Three of the four "gaps" were already sitting in production. The fourth — the Roman numeral tables — was half-done: two computed reference tables already existed; I added a third (1–100) and a few historic years.
None of these pages rank badly because they're missing a feature. They rank pos 28, or pos 55, because the domain is young. Google hasn't decided to trust it yet. That's a function of backlinks and time, not of anything I can type into a .tsx file.
Search Console shows you demand, not inventory
This is the trap, stated plainly: GSC tells you what people want. It says nothing about what you've already made. A query you rank pos 30 on looks identical whether the underlying feature is missing, half-built, or finished-and-polished. The position is about authority; the data can't see your codebase.
On an established site you feel this less, because your pages already rank where their content deserves. On a young site, everything is depressed by the same authority tax, so a finished feature and an empty gap produce the same sad little pos-30 row. If you treat every low-ranking query as a build ticket, you will spend your weeks re-implementing things you shipped last month — and never touch the one lever (authority) that actually moves them.
The honest actions that survived contact with the code were tiny:
- The word "stat circle" wasn't anywhere in the JoJo copy, though "stat wheel" was everywhere. Add the synonym.
- Users searched "dual type chart" but the only reference table was single-type. Add a computed dual-type table (derived from the same
effectiveness()function, so it can't drift). - Roman numerals 1–100 as one more computed table.
Real, worth doing, back-to-school-timed — but top-ups, not rebuilds. The difference between an afternoon and a week is entirely whether you read the code first.
Now add an AI agent, and watch it get worse
Here's the part that made me want to write this down. For the fandom side of the sweep, I handed the research to an AI subagent: find the highest-value next move in the Dragon Ball / gaming cluster. It read the backlog, checked live search results, and came back with a confident, well-argued top recommendation:
Build DBZ canon-character presets + a "List of Power Levels" reference table. GSC shows we rank pos 7–10 for "goku vs vegeta power level" with no canon data behind the tool yet…
It was a good pitch. It cited the queries. It reasoned about the SERP. And it was wrong — in exactly the way I'd just spent the morning catching myself. Two minutes of grep:
$ grep -rn "PRESET_MATCHUPS\|CANON_POWER_LEVELS" app/ lib/
The comparator already had a preset picker — "Goku vs Vegeta (Saiyan saga)" was right there in the list. Both DBZ pages already rendered a canon power-level table. The agent had read the docs and the web, pattern-matched "this looks like a gap," and hallucinated a feature that had shipped weeks earlier.
That's not a knock on the agent — it's the whole point. An AI agent amplifies the Search Console trap. It's extremely good at looking at demand signals and generating plausible work. It is not, unless you make it, looking at your actual implementation. The code is ground truth; the agent's confidence is not. "Verify-first" stops being a nice habit and becomes a hard gate: no recommendation gets built until someone has read the file it claims is empty.
(The genuinely new work left over was small and honest: one canon matchup preset for a query we didn't cover, and four sourced power-level readings — Yamcha 177, a few Namek-saga numbers — cross-checked against a databook, because the one rule I won't break is shipping data I can't cite.)
What actually moved the needle
After all that, the highest-value thing I shipped wasn't a feature at all. It was a single in-prose link.
Search Console showed "online traffic light for classroom" ranking pos 8 — landing on the noise meter, not the purpose-built traffic light page that targets exactly that query. The older page's authority was intercepting the newer page's own search. No feature fixes that. What helps is a contextual link from the noise meter to the traffic light, so Google can tell the two apart — plus the slow, unglamorous work of earning backlinks so the whole cluster climbs together.
That's the shape of SEO on a young site, and it's the opposite of what the query data whispers. The data says build. The truth is usually you already built it — now go earn the right to rank for it.
The checklist I wish I'd started with
- Read before you build. Every query the radar flags gets a
grep, not a branch. The position is about authority; the feature may already exist. - Separate demand from inventory. GSC measures one and is silent on the other. A pos-30 row on a finished feature and a pos-30 row on a missing one look identical.
- Write "already built" down. In your own notes, in your backlog. It's how you stop re-litigating the same "gap" next month.
- Trust an agent's research, verify its conclusions against the code. Agents are demand-matchers by default. Make the implementation the source of truth, explicitly, every time.
- On a young site, the lever is authority. Backlinks and time move pos-30 pages; on-page churn mostly doesn't. Spend accordingly.
The four features Google told me to build were three-quarters already done. The afternoon I saved by checking went into the one link that was actually worth adding.