DEV Community: Sonny

Two weeks of Search Console data falsified my SEO playbook

Sonny — Sat, 25 Jul 2026 08:56:33 +0000

I run lans.cloud, a collection of 100 free single-purpose browser tools (classroom timers, name pickers, calculators, generators). The SEO playbook I launched with was the standard indie one: target specific long-tail phrases, build deep topic clusters, interlink everything, wait.

The site is young enough that I recently had exactly ~14 days of real Search Console data. I did a deep analysis run over all of it — every query, every page — expecting to confirm the playbook. Instead the data falsified almost every rule I was following. Here are the five lessons, with the actual numbers.

1. Your page-level averages are two populations wearing a coat

Search Console only attributes impressions to a query string when enough people search it — rare queries fall below a privacy floor and become invisible. On my site, only 52.6% of impressions had a named query. So I split every page's stats into a named slice and a hidden (anonymized) slice:

Slice	Impressions	Clicks	CTR	Avg position
Named queries	2,767	293	10.6%	29.3
Hidden queries	2,489	105	4.2%	13.3

The hidden slice ranks 16 positions better and converts 2.5× worse — and that inversion held across 24 separate pages.

Why this matters: one of my pages showed 555 impressions at position ~9 with zero clicks. Every SEO checklist says that's a title/snippet problem, so I rewrote the title. Nothing. A second rewrite was queued when the split showed what was actually happening: the page's named queries sat at position 34.8 (page 3–4, where zero clicks is the correct number), while 522 hidden impressions sat at position 7.7 — roughly 500 near-unique long questions hitting a big FAQ block, each answered directly in the snippet. Google was serving my content without the visit. No title rewrite can fix "the SERP already answered the question."

I could verify it because the site keeps a privacy-preserving aggregate referrer counter server-side: on pages Search Console says convert, the two instruments agree almost exactly (39 clicks vs 39 visits on one page). On the "position 9" page: 3 visits. The zero was real.

Takeaway: before you rewrite a title over "great position, no clicks," split named vs hidden queries (pull the query-dimension total and subtract it from the page-dimension total). And be suspicious of building pages whose entire payoff fits inside a featured snippet.

2. Content depth predicted nothing

The playbook says deep clusters rank. My deepest cluster — 29 classroom tools, its own hub page, dense internal linking — sat at median position 37. My shallowest real cluster — 4 Dragon Ball Z toys — sat at median position 7.

The obvious objections all failed:

"It's one breakout page." Remove the best page from the winning cluster entirely and its remaining 9 tools still return 6.6% CTR — still the best cluster.
"The deep cluster is older/newer." My oldest cohort (14–16 days indexed) had 2,645 impressions and 31 clicks at median position 32. The newest cohort (≤9 days) had 2,409 impressions and 364 clicks at median position 19. The newest pages outranked the oldest by 13 positions and out-clicked them 12:1. A 16-day-old page at position 68 with a 9-day-old sibling at position 9 has been evaluated and placed — it is not "warming up."
"The losing queries aren't long-tail enough." Average words per query was flat at 3.3–3.7 across every cluster, winners and losers alike. Phrase length discriminated nothing.

3. The variable that actually predicted rank: incumbents

What separated the winning clusters from the losing ones was visible on the SERP before I ever built the pages — I just never looked.

The winning family targets an intent no brand owns. No Wikipedia entry, no YouTube dominance, no decade-old exact-match domain — page one is a scatter of small sites, so a good page can actually place. The losing clusters compete with entrenched tools (and worse: a chunk of their impression volume turned out to be navigational — people typing a competitor's brand name. You will never be a better answer to <brand> name picker than the brand itself, and those impressions inflate your dashboard while converting nothing).

The cruelest illustration: my Roman numeral converter became the site's third-biggest page by impressions, surfacing for ~60 phrasing variants — at position 62, with 0 clicks. Meanwhile the winning family had ~40 phrasing variants of its intent at position ~7, converting at 16%. Same wide phrasing family, opposite outcomes. Variant explosion is an amplifier whose sign is set by your rank. A big impression count from many phrasings is not validation — check the position first.

My screening test now, before building anything: search the target phrase and look at who owns page one. Brand, Google widget, or ancient exact-match domain → don't build it (or accept that only backlinks/authority can move it, not content). Scatter of small sites → build.

4. Aggregate dashboards lie by mixture

My site-wide CTR "improved" from 5.5% to 8.6% in two weeks. Celebration? No — decomposition. The site is a two-population mixture: one viral-ish page at 20.6% CTR, everything else at 2.21%. Solving the mixture showed the entire "improvement" was the big page's impression share nearly doubling (17.9% → 34.7%). CTR at constant position improved nowhere.

The concentration behind that: one page held 77.9% of all clicks (click Gini coefficient: 0.978, computed for fun and regret), and 98 of 118 indexed pages had zero. If you only track the site-level line in Search Console, mix shift will masquerade as progress in both directions. Decompose before you celebrate — Simpson's paradox is alive and running an SEO dashboard near you.

5. Google picks one page per intent — and it may not pick the one you optimized

I worried about keyword cannibalization; the data says it barely exists (4 of 675 queries mapped to two of my pages). But the one real case was instructive: I have a straight coin flip page and a rigged coin flip page. For the generic query flip a coin, Google ranks the rigged page at position 11 and the generic page at position 83 — for identical query sets, a 60-position gap. The specific, personality-having page won the generic term. The generic page built "for SEO" got nothing.

What I'd tell past me

Split named vs hidden queries before diagnosing any page.
Don't build for a SERP you haven't looked at. The incumbent test takes 30 seconds and predicts more than any keyword metric.
Depth multiplies rank on open SERPs and multiplies zero on owned ones. Same energy, route it by SERP.
Never trust an aggregate trend you haven't decomposed.
Wide phrasing families are amplifiers, not validation.

All of this came from a site you can poke at — the tools live at lans.cloud, the classroom set (the humbled cluster of lesson 2) is at lans.cloud/classroom-tools. Earlier posts in this series: the architecture and putting marketing docs in CI. Happy to share the analysis scripts if anyone wants them.

My marketing docs kept lying, so I put them in CI

Sonny — Sat, 25 Jul 2026 08:50:29 +0000

My side project lans.cloud has 100 free browser tools. For three weeks, everything I posted about it — the launch article, the directory listings, the pitch emails — said 37. Then 50. Then 51. Then 50 again, because 51 had been wrong.

Code has tests. Docs drift. And marketing collateral drifts worst, because nothing executes it: a wrong number in a pitch email doesn't throw, it just quietly makes you look sloppy in front of the one blogger you wanted to impress.

So I started treating marketing bookkeeping the way I treat code: continuous integration (CI) for prose — a check that runs on every ship. It's about eighty lines, and it has already caught real mistakes I'd missed by hand.

The facts checker that blocks `git push`

The recurring bug: my tool count appears in a launch kit, a founder Q&A, standard directory blurbs, social post drafts. Every new tool silently invalidates all of them. Grepping and fixing by hand worked exactly as well as you'd expect — I missed a "forty-one free tools" claim hiding in a directory blurb for weeks.

The fix is a ~80-line script that derives the true count from the code and refuses to ship while any living marketing document disagrees:

// The registry is the single source of truth…
const allToolsSection = registry.slice(
  registry.indexOf('export const ALL_TOOLS')
);
const liveCount = (allToolsSection.match(/status: 'live'/g) ?? []).length;

// …and any "<N> … tools" phrase in living marketing docs must match it.
const COUNT_RE =
  /\b(\d{2,3})\s+(?:(?:live|free|single-purpose|browser(?:-based)?|web)\s+){0,4}tools?\b/gi;

It's wired into the ship script, before the push:

# ship.sh
node scripts/check-marketing-facts.mjs   # exits 1 on drift
git push

One design decision matters more than the code:

Historical documents are exempt. Sent emails, archived posts, old status logs — those keep their numbers. A pitch email I sent when there were thirty-seven tools should say thirty-seven forever. Only the living documents (the ones I'll copy from tomorrow) are checked.

The checker caught a stale "forty-one" on its very first run, and a batch of wrong counts across sixteen locations on its second day. It has paid for itself several times over.

(You may notice the historical counts in this post are spelled out as words. That is not a style choice: the checker scans my drafts too, and it flagged this very article for containing old numbers next to the word "tools". I could add an ignore-marker — or I could let the tooling win. The tooling won.)

Marketing collateral is code that executes in other people's heads. Test it like it matters.

The site is lans.cloud; the first article about its architecture is here. Happy to share any of the scripts in full.

Google said my fastest pages were slow: a PageSpeed mystery in three clues

Sonny — Fri, 10 Jul 2026 08:58:59 +0000

My site lans.cloud is 51 static, client-side tools served from one small container. Local Lighthouse scored every page 90+. So when I finally ran the same pages through Google's real PageSpeed Insights (PSI) application programming interface (API), I expected a victory lap.

Instead I got this:

Page	Local Lighthouse	PSI (Google's infra)	PSI Largest Contentful Paint
/classroom-scoreboard	90	100	1.4 s
/my-data	92	100	1.7 s
/spin-the-wheel	93	76	5.6 s
/classroom-timer	95	79	5.2 s
/ (homepage)	92	70	5.6 s

Five pages at 97–100. Five pages at 70–79. Nothing in between — and my local runs had shown no such split. Every failing page failed the same way: a Largest Contentful Paint (LCP) of ~5.5 seconds.

Statically prerendered pages. Same layout, same Cascading Style Sheets (CSS), same fonts. A 5.5-second LCP made no sense.

Clue 1: the "slow" element was innocent

PSI's JSON (JavaScript Object Notation) response tells you which element was the LCP. On every slow page it was… the header description. A server-rendered <p>. Plain text, present in the initial HTML, no image, no font trickery.

The LCP breakdown said: time to first byte, 14 ms. Element render delay, 2,291 ms.

Static text that the browser has from byte one, painting 2.3 seconds late. The element wasn't slow — something was delaying paint itself. Which led to the actually useful query: compare observedLargestContentfulPaint with observedFirstContentfulPaint — the First Contentful Paint (FCP) — in the raw response.

They were identical on every page. Fast pages: LCP = FCP = ~140 ms. Slow pages: LCP = FCP = ~2,300 ms.

So there was never an LCP problem. There was a first paint problem, and the LCP element was just standing nearby when it happened.

Clue 2: it only happened on slow hardware

From my own machine, real Chrome painted every one of those pages in 100–250 ms. Fast club, slow club, no difference.

That's the trap with performance work: my hardware is fast, Google's test runners are deliberately slow. Whatever was delaying paint scaled with processor speed — and disappeared entirely when processing power was cheap.

I diffed everything between a slow page and a fast page: <head> contents, stylesheet lists, script tags, HyperText Markup Language (HTML) byte offsets of the visible text, pending Suspense boundaries. Nearly identical. The slow pages had two extra route-specific JavaScript chunks. That was the whole difference.

Clue 3: the race

Here's the mechanism, and I think it's underdocumented:

Async scripts don't block parsing — but evaluating them blocks the main thread, and paint needs the main thread. On fast hardware, first paint happens long before any script arrives. On a slow machine with fast-arriving scripts, it's a race: if a chunk arrives and starts evaluating before the browser gets around to its first paint, paint waits.

My five slow pages had marginally more JavaScript. Not dramatically more — just enough to tip the race on Google's runners. Five pages painted at 140 ms; five painted after ~2 s of script evaluation.

Then the second mechanism kicks in: PSI uses simulated throttling. It records an unthrottled trace and then a model ("Lantern") estimates what the metrics would be on a slow device and network. The model saw "first paint waited for JavaScript" in the trace and, applying its throttling math to that dependency, projected LCP at 5.5 seconds. The 2.3 s race loss became a 5.5 s headline number.

One trace where paint loses a race by a hair → a model that treats the loss as a structural dependency → a 30-point score gap. That's how five identical-architecture pages split into two clean clubs.

The fix was one line

If paint must win a race, shorten paint's track. My CSS totals ~19 kilobytes, but it shipped as two render-blocking stylesheet requests — the largest fixed cost on the paint path. Next.js has a flag for exactly this:

// next.config.ts
const nextConfig: NextConfig = {
  output: 'standalone',
  experimental: {
    inlineCss: true, // CSS ships inside the HTML — zero blocking fetches
  },
};

With the CSS inlined into the HTML, the browser can paint the moment it has parsed the (single) response. No fetches to wait for, nothing for script evaluation to cut in front of.

Same day, same API:

Page	Before	After
/spin-the-wheel	76	100
/classroom-timer	79	92
/ (homepage)	70	95–99
/random-name-picker	74	96
/classroom-scoreboard (control)	100	99

One caveat from the trenches: the first run right after deploying read lower (68) — cold caches on Google's side. Re-run before you panic; judge trends, not single runs. And inlining CSS is a trade: it's the right call when your CSS is small (mine is ~19 kilobytes and identical across pages); with hundreds of KB of styles you'd be bloating every HTML response instead.

Epilogue: the ghost came back — and proved the point

A week later I probed again on an ordinary evening and nearly relapsed into panic: the homepage read 74. But this time I had a control page — one I hadn't deployed to or changed in any way. It read 95 in the afternoon, 78 an hour after that, 73 by night. Same page, same URL, zero deploys. Back-to-back runs of one page gave first paints of 1.2 s and 3.0 s. And the fingerprint from Clue 1 was back on every page: observed LCP exactly equal to observed FCP, with a two-second "element render delay" pinned on an innocent paragraph.

That's not a website changing three times in an evening — that's shared test runners changing under load. So two rules got added to my monitoring: probe at a fixed quiet hour (mine runs Monday mornings), and always probe a control page you didn't touch. If the control moves with your page, you're measuring Google's infrastructure, not your deploy.

What I actually learned

observedLargestContentfulPaint vs largestContentfulPaint in the PSI response is the single most diagnostic comparison available. Observed is what happened on their hardware; the other is the model's projection. When they diverge wildly, you're debugging the model's inputs, not your page.
LCP problems are sometimes paint problems, and paint problems are sometimes races. If observed LCP equals observed FCP, stop staring at the LCP element.
Local Lighthouse and PSI are different instruments. My datacenter runner was kinder to the slow pages and harsher on the fast ones — systematically. PSI is the number that correlates with how Google sees you; optimize against it.
Get the free API key. The keyless PSI endpoint shares one global quota with the entire internet and is permanently exhausted — I verified by firing at the exact moment of quota reset and still getting a 429. With a key it's 25,000 requests per day, which turned "check PSI sometimes" into a weekly probe in my monitoring.

This is the sequel to my earlier Cumulative Layout Shift (CLS) hunt — same site, same lesson wearing a different costume: the metric that's screaming is rarely the thing that's broken.

The site is lans.cloud — 51 free browser tools, all static, all measured. Happy to answer anything about the setup.

51 tools, one container: build-time reference tables and a CLS bug hunt

Sonny — Thu, 09 Jul 2026 08:49:43 +0000

I've spent the last weeks building lans.cloud: 51 free single-purpose web tools — classroom seating charts, crochet calculators, D&D stat rollers, Minecraft build math. This post is about the three technical decisions that shaped it, and a layout-shift bug hunt that ended somewhere I didn't expect.

The one hard rule: everything computes in the browser

Every tool is client-side. The only server code in the entire project is an anonymous page-view counter (one Postgres upsert) and a feedback endpoint. No accounts, no sessions, and the privacy page can make a claim most sites can't: class lists and student names never reach a server, because there is no code that could receive them.

The payoff is operational: the whole site is statically prerendered by Next.js and served by one 41 MB container behind Traefik on a small VPS. Deploys are docker compose up --build. Capacity planning is "the network port saturates before anything else does."

Reference tables that cannot drift

Every tool page carries reference content — a Minecraft circle block chart, grading tables, dice probabilities, pomodoro preset math. The rule: pages import the tool's own logic library and compute their tables at build time.

<ReferenceTable
  title="Classic tabata 20/10 — total time by number of rounds"
  rows={ROUND_COUNTS.map((rounds) => [
    String(rounds),
    formatTotal(
      totalDuration(buildSchedule({ prepare: 10, work: 20, rest: 10, rounds }))
    ),
  ])}
/>

The table on the page and the timer the visitor runs share one implementation, so they can't disagree. When I added canon Dragon Ball power-level matchups, the lookup throws at build time if a character name doesn't match the data — a typo fails the build instead of publishing a wrong number.

As a side effect, this is SEO content that's genuinely useful and impossible for a scraper to keep current: it regenerates from code on every build.

The CLS hunt: 0.71 → 0

Lighthouse flagged Cumulative Layout Shift 0.71 on the busiest page (threshold for "good": 0.10). Three fixes, each revealing the next problem:

Round 1 — the skeleton mismatch. The interactive tools hydrate behind a Suspense skeleton. The skeletons were ~500px; the hydrated apps were up to 1,186px on mobile. Everything below jumped on hydration. Fix: measure every tool's real hydrated height headlessly at mobile and desktop widths, and put those values as responsive min-height on the wrapper that survives the swap. Result: … CLS unchanged. Correct fix, wrong culprit.

Round 2 — the ad slot. A PerformanceObserver layout-shift trace on the live page showed the entire app area moving as one block: the ad slot above it reserved 90px, but the responsive AdSense unit rendered ~250px. Raised the reservation per breakpoint. Result: better, still failing on one page.

Round 3 — the real culprit. The trace rects made no sense until I measured the <ins> element directly: AdSense's script pre-sizes a full-width-responsive unit to roughly viewport-width height — 412px tall on a 412px phone — before any ad even fills. No reservation short of the viewport width survives that.

The documented escape hatch: give the <ins> an explicit CSS size and remove data-ad-format/data-full-width-responsive. AdSense then serves into exactly that box and never resizes it:

<ins
  className="adsbygoogle block h-[250px] w-full max-w-[336px] lg:h-[90px] lg:max-w-[728px]"
  data-ad-client={CLIENT_ID}
  data-ad-slot={SLOT}
/>

CLS after: 0 on every page I measured. The trade-off is a slightly narrower ad auction than "auto" — but 300×250 is the most-bid display size there is, and CLS is the Core Web Vital that feeds rankings, which feed everything else.

Assorted lessons

A min-height reservation is a guess; a CSS-sized ad unit is a contract.
Measure with PerformanceObserver('layout-shift') sources on the real page — Lighthouse tells you that something moved, the sources tell you what and from where.
If you pipe git commit through tail in a && chain, the pipeline's exit code is tail's. My pre-commit hook failed silently and I deployed a working tree that git didn't have. Check git log origin/master, not exit codes.
Entering browser fullscreen remounts your React tree if the fullscreen branch renders differently. Anything not persisted is gone. Users find this in minutes.

The site is lans.cloud — all free, feedback button on every page. Happy to answer anything about the setup.